DJohn Posted July 28, 2019 Report Share Posted July 28, 2019 I have a 2MB Papilio Duo (Kickstarter edition), with the Classic Computing shield, that I'm using for my first serious FPGA project. I'm using it as a simple FPGA board, so not using the Arduino side, and doing everything myself in VHDL. I've run into a problem writing data to the SRAM. My design uses 4 cycles of a global clock for each memory access. Writes go like this: /OE <= 0, /WE <= 1, set address, tristate data /OE <= 0, /WE <= 0, assert data to write wait /WE <= 1 My test configuration follows this with a read: /OE <= 1, set address, tristate data wait read data wait Unless I've made a mistake (spoiler: I have almost certainly made a mistake), with a 160MHz global clock this should fit comfortably in the SRAM's timing requirements. At 80MHz it works fine. At 128MHz it's OK most of the time, with occasional errors. At 160MHz it's failing very frequently. I'm fairly sure that it's the writes that are failing: when it's connected to a larger design that copies a ROM into RAM and then displays the contents of RAM on VGA, I get a stable image with missing pixels here and there. But I can't see what I'm doing wrong. Can anyone help? I'll attach my stripped-down SRAM testbed. I'm very new to VHDL, so comments on style are welcome too. I'm probably doing everything wrong. LED1 blinks briefly when the data read back from SRAM doesn't match the data that was written. sram_test.ucf sram_test.vhd Quote Link to comment Share on other sites More sharing options...
DJohn Posted July 29, 2019 Author Report Share Posted July 29, 2019 Answering my own question. Don't put stuff outside the process unless you want it to be horrible and glitchy. The simulation shows nice in-spec signals, but in reality it was getting occasional glitches that my logic analyser was having trouble seeing. It's still not working, in ways that I don't really understand, but at least I've got something to go on now. Quote Link to comment Share on other sites More sharing options...
mkarlsson Posted August 1, 2019 Report Share Posted August 1, 2019 Looks like you have the polarity of /OE wrong - it should be high when writing and low when reading. Magnus Quote Link to comment Share on other sites More sharing options...
DJohn Posted September 6, 2019 Author Report Share Posted September 6, 2019 I found out what my problem was. The fact that it worked when I lowered the clock frequency was a big clue that it was something to do with timing. I since discovered the trce timing report (I said I was new to all this), and that told me what I was doing wrong. After the falling edge of mclk, clockPhase must make its way to the output of its latches, go through some logic, then make its way to the clock enable of addressPins and dataPins before the next rising edge of mclk. It has 3.125ns to do all this, and that's not quite enough. I had clockPhase being latched on the falling edge because I wanted it to be stable before and after the rising edge where all the action happens. It seems this wasn't such a good idea. What I should be doing instead I'm not sure, but I will certainly be asking trce for its opinion in the future. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.