Memory Controller timing constants for LX9 SDRAM

[Michael Simmonds]

Chris,

In your VHDL file mem_ctrl.vhdl you list specific values for INIT_COUNT, REFRESH_DELAY, and REFRESH_LENGTH.

These look like reasonable values for the MT48LC16M SDRAM and I assume that they work successfully with the chip.

But in a FIFO example (readback_rtl.vhdl) you have a comment next to these same values:  "Much longer in real hardware!"

Can you clarify this?

Also, would you consider the memory-control example a good basis for developing a project that uses this type of SDRAM for logging ADC data and retrieving it through FPGALink.  Or is it overly simplified and primarily of tutorial value?

Regards,

Mike

[Chris McClelland]

The comment you're referring to is actually in the testbench[1], where these values are overidden because it would be pretty boring to have to wait for 4800 cycles of simulation time before the memory controller comes out of its initialisation phase. The default values in the RTL[2] are correct for the MT48LC8M16A2 SDRAM.

Whether this memory-controller is appropriate for you depends largely on your needs. I actually wrote this memory-controller originally as part of the UMDKv2 project[3], for which the main constraint was latency, not throughput. So for this reason it exposes signals allowing manual control over the scheduling of refresh cycles, but it does only one 16-bit read or write at a time, taking four 48MHz cycles for each, giving a raw throughput of a little less than 24MB/s (one read/write takes four clocks, but transfers two bytes, so the throughput is half the 48MHz clock speed).

If that throughput is acceptable to you, then this controller should work fine for you. If you need more throughput, you could easily modify my controller to do longer (but still fixed-length) bursts. I'd be happy to do that kind of work for you under contract, if you'd rather not to do it yourself.

Chris

[1]https://github.com/makestuff/mem-ctrl/blob/20151220/vhdl/tb_unit/mem_ctrl_tb.vhdl#L54-L58

[2]https://github.com/makestuff/mem-ctrl/blob/20151220/vhdl/mem_ctrl.vhdl#L24-L28

[3]https://hackaday.io/project/1507-usb-megadrive-devkit

--
You received this message because you are subscribed to the "FPGALink Users" mailgroup (see https://github.com/makestuff/libfpgalink/wiki/FPGALink).
 
To post to this group, send email to fpgalin...@googlegroups.com
To unsubscribe from this group, send email to
fpgalink-user...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/fpgalink-users?hl=en
---
You received this message because you are subscribed to the Google Groups "FPGALink Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fpgalink-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Simmonds]

Thanks for the explanation about timings.

The throughput you obtained will be plenty fast since I will digitizing at 1 MSP or less. Having a low latency will be convenient.

I may use two SDRAM's so that I can record one "frame" while uploading the other and not have to worry about R/W collisions or other timing issues.

 

[Chris McClelland]

Honestly you don't need two SDRAMs. You can just interleave accesses to the two frames, with small FIFOs to smooth out the bursts. That means your sampling bandwidth will be reduced to 12MB/s (because the other 12MB/s will be soaked up by the other frame being uploaded). If that's not good enough, just select two-word bursts instead of single-word bursts, resulting in five cycles per access, and ~19MB/s sampling bandwidth.

Chris

[Michael Simmonds]

Yes, that is certainly the more elegant approach. And probably not that much more HDL to create.  I would need to upgrade to a 128Mb RAM in order to handle my maximum 2Kx2K frame size, but that is just one extra pin to wire up (rather than 56 pins for an extra RAM).  Speed is no problem

Thanks for encouraging me to eschew American-style excessive consumption and do it the minimalist way.