I usually change the blink rate to make it more obvious that the new bitstream is loaded (having wasted a day once).

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Yeah, been there. I've spent hours working on a project that didn't work only to find out I was loading the same file over and over again. Of course, after realizing that, and switching to new file, it didn't work either.

Exactly. I do it every now and then, thinking that for some magic reason I can run at higher and higher speeds, only to find out that I am sending the wrong bitstream.

The SRAM is not synchronous, which to me means 'get signals to it as fast as possible'. So I don't think flopping the output data is necessary or helpful. Any slop on inputs simply delays the correct output - am I right?

The decoupling on the power supply to the lower part of the FPGA, connected to the SRAM, is inadequate and is fixed in the next rev of the board. I also added a ground pour behind the SRAM and the lower half of the FPGA. Perhaps that will help.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

The risk with not registering the outputs is that you may get glitches on WE for instance, and corrupt random memory.

Also, if you want to write, but WE is asserted early, and the address is late, you could be writing in the wrong location.

enso:

I've not been following your SRAM interface issue closely, and the following suggestions may not be applicable. Further, I've not simulated the suggested code change.

Your SRAM interface module code is reproduced below. I am going to assume that [7:0] xin is what you consider the output of the input buffer in the IOB, which should be defined as inout [7:0] xdb. Similarly, I am going to assume that you have defined [7:0] di as an input to the module, and that you expect it to drive an output buffer in the IOB which can be tri-stated.

I've come to determine that Xilinx's synthesizer assumes a logic 1 for any tri-state signals within the FPGA. There isn't a tri-state output available for the input buffer of the IOB on the Spartan 3/3E/3A families; it is simply connected to the FPGA fabric and/or the IOB FF. Thus, whenever we is asserted and xin is supposed to be tri-stated, a logic value of 1 is assumed by the synthesizer. This is most likely the reason that you are observing a 8'hFF for the SRAM module's do signal as you appear to note in the comment you appear to have embedded in the your code.

I would suggest the following change to your code:

I expect that this code snippet will output a value of 0 from the di port of your SRAM interface module for at least one cycle after we is asserted or the SRAM is not selected. It will reflect the value on the external bidirectional pin xdb whenever the SRAM en is asserted on the rising edge of your system clock, sclk.

_________________
Michael A.

enso:

The following is food for thought.

I've experimented with using an ODDR2 output register and quadrature clocks to generate an SRAM strobe within a single clock cycle. The following ZIP archive contains an example which uses a Clk90 and a Clk0 to generate a strobe of 3/4 length of a clock cycle. In your case, with a 50 MHz clock frequency, the strobe width would be approximately 16 ns. At lower operating frequencies, the strobe width would increase.

I've also attached a magnified view of the circuit's functional simulation.

_________________
Michael A.

Michael, are you suggesting sequencing the SRAM with an offset clock? I've thought about it on numerous occasions, but got put off by the complexity of the synchronization logic across the clock domains. I know there is a good way to do this, but I just haven't had the brainpower to tackle it yet.

Or perhaps you mean just shaping the write strobe to allow back-to-back writes? And delayed to assure proper setup?

That may allow for faster operation (and dispensing with BRAM stack page)

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Michael, I plugged in your code snippet synchronizing to 'clr_do' but it broke the system, at least at 45MHz. Looking at it, I am a little confused about its effectiveness - wouldn't it bring the timing uncertainty into the flopping of 'do'?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

enso:

Don't be put off by the number of clocks shown on the diagram; there's several experiments of mine in the files that I sent you.

I was suggesting that you can use a single clock domain to generate a strobe whose pulse width is controlled by the appropriate selection of the two clocks that feed into the ODDR2 component/macro. At issue is bus recovery of the SRAM and your bidirectional data bus into the FPGA. Unless you are using some kind of ZBT/NBL (Zero Bus Turnaround/No Bus Latency) device, there's usually some requirement for the output drivers to be turned off for some small amount of time before enabling the drivers in the other direction. In other words, it's important to turn off the FPGA's write buffers (during SRAM writes) before turning on the SRAM's write buffers (during SRAM reads).

If one is able to do this successfully, then the issue of bus contention on the SRAM/FPGA bidirectional bus is eliminated or at least substantially reduced to a minimal fraction of a bus period. The circuit I sent you is intended to be used with a single clock/single cycle memory access of an SRAM. I chose to put the bus turn around delay at the beginning of the cycle, but you can move it to the end of the cycle. It is at the beginning of the cycle because I delay the assertion of the write strobe by one quarter of the bus period by using the Clk90 signal. The circuit terminates/deasserts the strobe with Clk0, which should coincide with a read cycle for the next instruction.

In the scheme that I'm currently implementing, the read strobe to the SRAM will also be asserted using the same strobe generator. Therefore, there should be a quarter cycle where the SRAM output is not enabled. The quarter cycle delay should be sufficient to avoid bus contentions with most asynchronous SRAMs that are capable of operating at the speeds you are attempting on your FPGA board.

If you are using a 40-50MHz oscillator, which I remember you describing it as at one time, then a simple DCM in your FPGA will be able to give you the Clk0 and Clk90 signals needed for generating the strobe as shown in the timing diagrams previously attached. Otherwise, you can use a 4x clock and divider as I included in the test bench that accompanied the source. A 2x clock can also be used with the Clk0 phase generated as a toggle on the rising edge of Clk2x, and the Clk90 phase generated using delay FF clocked on the falling edge of Clk2x.

_________________
Michael A.

I see that you tried something. Just to avoid sending you down a rabbit hole, would you confirm that di is the input to the SRAM interface, and do is the output of the SRAM interface. In other words, your core's data output connects to di and your core's data input connects to do.

_________________
Michael A.

Build Environment for Linux

This file has everything required to build CHOCHI's 004 bitstream (I think) using make. Of course, you have to install Xilinx tools and be able to invoke them from the command line (run the Xilinx environment script)

Michael, SRAM's di is connected to CPU_DO.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Will take a look at the mSRAM128K module and try to construct a test bench with which to work. Will let you know something later tonight or tomorrow.

_________________
Michael A.

Thanks, Michael.

BTW, it's pretty easy to construct a GUI project from the files. The only weirdness is that it would build a bitstream with no code; to compile and insert the 6502 bootloader my makefile does:

Windows users can make a batch file that does that... The empty .bit file is called top.nocode.bit and the output file is top.bit in my case.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Just to put things into a proper perspective, the circuit as it stands runs comfortably at 45MHz on my test machine. Putting my finger over the chips does not affect its operation. The SRAM is asynchronous, so until the address lines settle, it is expected to observe noise on the data lines - as long as there is enough time for the bus to settle down at the time it counts - the clock transition.

There are now over a dozen boards running solidly, as far as I can tell.

The only flakiness I've experienced is an occasional mis-start on power-up (LED blinks, but the terminal shows nothing). Some of it is attributable to the dreaded USB-serial port (I have to occasionally unplug the cable and re-start the terminal), so I am not even convinced there is an issue there.

Of course I welcome all suggestions and alternate circuits, but just want to make sure we don't chase shadows for no good reason. Introducing a pulsed strobe, if it doesn't complicate the circuit, may be a wise decision as long as it accomplishes something - increased FMax perhaps (I am still hopeful that somewhere around 70MHz is attainable with better SRAM timing).

Another direction to pursue is to attempt to use one of the other read modes - I think there are 3 documented in the datasheet. I implemented the most expedient and simple mode, but perhaps the other ones are better somehow. I will take another look later.

BTW, thank you all for doing this. My ancient oscilloscope is entirely useless, and I am happy that we can put our heads together and share information.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

Looking at the SRAM128K.v module I noticed the 'OE = 0' line... That is probably not a good thing - it should really not be enabled during writing. I can't remember if the datasheet implied that it doesn't matter as the output goes hi-z.

Arlet, regarding your final scope screendump - what is the horizontal unit? How often are the transients occuring?

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut