FPGA using external 10ns static RAM max write rate

I'm using a 10ns sram IS61LV51216 (https://www.eng.auburn.edu/~nelson/courses/elec5260_6260/61LV51216 SRAM.pdf) with a Cyclone II EP2C5 device to make a DSO/logic analyzer and I'm trying to figure out the max write rate I can use.
I'm using a configuration where LB,UB are low and OE is high so I'm just using low pulses on WE to control the operation, according to the datasheet the min width of a low WR pulse must be 8ns but I'm using 10ns.

I have used the PLL of the FPGA to generate two 90MHz clocks , the second one is shifted by 324 degree , this has allowed me to use a write cycle of about 11ns , for 10ns WR is low and for 1ns high

This is the post fit simulation result


My question is do you think it is possible for this to actually work in hardware (I don't have the FPGA in hand), the 1ns pulse seems too small and I'm not sure that the FPGA would be able to produce it in the the output or if it wouldn't reach the RAM (PCB and RAM limitations?) or maybe the RAM would need more than that.
According to the RAM datasheet the min duration of the WR low pulse can be 8ns so maybe I can make the pulse 8ns low and 3ns high or if that wouldn't work either what pulse durations would you suggest?

Alex

Is the RAM_WE_n output combinational, or is it registered? I would guess combinational because otherwise you'd have a fun time clocking the FFs with a combination of those 2 clocks.

For the 1 ns pulse to arrive in the world outside of the fpga you'd need pretty high rise/fall times. So for a cyclone II that would seem a bit optimistic to me, but I am not sure.

Personally if I wanted to do something like that I'd make 2 outputs on the fpga that are just toggling at the boring slow 90 MHz clock rate. And then stuff them through a fast GHz logic gate from onsemi or some such. Hell, you can generate even shorter pulses that way with for example this one: https://www.onsemi.com/PowerSolutions/product.do?id=MC100EP08

I'm not sure if the "generate short pulses" method is the way to go for your general problem though. Just mostly responding to the short pulse generation part of your post.

The simplified code of what I have used is



clk is the 0degree 90MHz clock and clk2 is the 324degree shifted 90MHz clock, I start write at the falling edge of clk and end it at the falling edge of clk2
This has compiled fine in quartusII for CyconeII and the result I have posted is the post simulation result, but I agree that the 1ns pulse doesn't seem realistic.

Alex

Thanks for the clarification. That looks more or less like what I'd expect. And I see that ram_we_low is indeed combinational. This ram_we_low then goes directly to an IO pad, yes?

Anyways, what I'd remove this:



Then make two outputs for set_ram_we_low and reset_ram_we_low. And then do the XOR with an external fast logic gate. That should get you your fast rise/fall times.

I would rather try to generate the WE waveform by a PLL directly than or-ing phase shifted clocks. Phase shift of WE against address/data may be still necessary to compensate for timing variations. Minimum pulse width has specification to be considered, 2 ns should work with Cyclone II.

At worst case, an in-system calibration of WE phase with test write and read can be performed, similar to DDR DQS timing calibration on startup.

Yes, ram_we_low goes directly to an I/O pad

Your solution is smart but needs an additional external device so assuming that I want to use the FPGA only how high could I go with such a RAM, is it for example only good for a 50MHz operation.
I'm basically asking if anyone has experience with these rams in a high speed operations, I've seen them in a few dev board where no XOR device can be added so I wonder is anyone has used them in a high frequency operation.

Thank you for your help
Alex

I won't expect the RAM to have better logic performance respectively minimum pulse width acceptance than the FPGA logic cells. In so far I don't see a purpose of external logic in the present case.

I have implemented similar asynchronous RAM logic, but with larger timing margins because the design had been designated to professional test systems.

FvM said:

I would rather try to generate the WE waveform by a PLL directly than or-ing phase shifted clocks. Phase shift of WE against address/data may be still necessary to compensate for timing variations. Minimum pulse width has specification to be considered, 2 ns should work with Cyclone II.

Click to expand...

I have tried a similar way by using a 90MHz clock with a duty of 8% and I have used that clock for the memory module and compared to that I got better results using the compilation of two clocks to control WE and keep the clocks for the rest at 50%.

Your suggestion of using a PLL clock for the WE only and another 50% for the module is an interesting one, thank for the idea.

If the 2ns is doable in Cyclone II then I guess it's just a matter of the RAM input and if it will recognize it or if it needs a wider pulse.
I guess I can figure that only by trial and error on the actual hardware but a 70MHz (10ns+4ns) should be doable as a worse case scenario.

Also I have the benefit of using a 16bit RAM so I can sample two 8bits data in double the data rate that the RAM operates do I can gain additional sampling performance from that.

Alex

alexan_e said:

Yes, ram_we_low goes directly to an I/O pad

Your solution is smart but needs an additional external device so assuming that I want to use the FPGA only how high could I go with such a RAM, is it for example only good for a 50MHz operation.

Click to expand...

Oh I am not saying you should use the XOR approach (internal or external) for your sram. This was more of a quick fix for those times when you want a usable 500 ps pulse out of your annoyingly slow fpga.

mrflibble said:

Oh I am not saying you should use the XOR approach (internal or external) for your sram. This was more of a quick fix for those times when you want a usable 500 ps pulse out of your annoyingly slow fpga.

Click to expand...

It was a very useful solution that I haven't thought about and I'm sure it can be useful in a future situation so I'm happy you have suggested it, I just want to apply a single device solution in this case.