Looking at the 3010 Verilog for the RAM test application I see that ep40trigA and ep40trigC endpoints are connected to the same address and that bit 0 of ep40trigA is used for both sdram_fiforeset and sdram_reset. ep40trigC on the other hand isn’t used at all. This doesn’t seem correct. I am guessing that ep40trigC should actually be connected at a different address and should be used for the sdram_reset, sdram_setrdaddr and sddram_setwraddr based on the clock domains that ep40trigA and ep40trigC are sourced from and to where the fan out. If this is correct you will also want to change the C source code as the 40 endpoint address is used for both of the above functions.
Christopher
Hi Christopher-
First, it is acceptable to have two okTriggerIn modules at the same endpoint address. This allows you to use the same ActivateTriggerIn to trigger logic on multiple clock domains (as you have noted).
You’re correct that epTrigC is not used.
Now, things get a little funny with FIFO resets. Xilinx insists on calling the reset to their FIFOs a “synchronous reset” but it mentions in the documentation that the reset must be asserted for at least 3 cycles of the CLK. Personally, I would prefer to call this an ASYNCronous reset with Tmin=3*Tclk.
Therefore, to be entirely correct (the RAMTester, admittedly, needs some updating), the triggered reset should produce a 3-cycle reset that is fed to the BufferedPipes.
We have not updated this sample because our FrontPanel-3 release has deprecated the okBufferedPipes in favor of using just a FIFO core with a standard okPipe.
[QUOTE=Opal Kelly Support;1264]
Therefore, to be entirely correct (the RAMTester, admittedly, needs some updating), the triggered reset should produce a 3-cycle reset that is fed to the BufferedPipes.
We have not updated this sample because our FrontPanel-3 release has deprecated the okBufferedPipes in favor of using just a FIFO core with a standard okPipe.[/QUOTE]
Will the RAMTester example be updated & ready for release at the same time as the FP-3 release?
Thanks!
- Michael A.
We’ll try. Our primary goal with the samples is to provide a launching point for using our API. Properly using the hardware on our modules (including the FPGA and peripherals) is a much larger issue because things start to get application-specific very fast.
Nevertheless, we think the RAMTester sample serves a valuable place in our samples. It just isn’t as high a priority. There is a lot of literature available online and otherwise for writing SDRAM controllers. Realistically, these should be the primary reference.
So, I have been looking into writing SDRAM controllers and I would love to see any links (besides the xilinx site).
Christopher-
As you noted, Xilinx has at least a couple papers on the matter. Doing a Google search for “SDRAM controller”, there are also several pointers to papers at IEEE and SOC central as well as Xess (who also makes FPGA boards).
I’d like to mention a few notes about SDRAM controllers, though. First, they should generally be tailor made for a particular application. Most applications do not require use of all the features that an SDRAM controller can handle. And depending on the access profile (which addresses are accessed and how often), you can reduce the number of refreshes or transactions on the bus and reduce power consumption.
For example, our simple controller only supports page burst mode. This is great when coupling with a FIFO as a cache memory, but is not so great if you want to access smaller pieces of memory (like 2-8 words) at a time. Additionally, many SDRAMs don’t even support the page burst mode.
All that said, I think our SDRAM controller serves a valuable purpose. It’s designed to be pretty clean and easy-to-read. Many controllers are unnecessarily complex and end up requiring another controller just to handle the controller!
In our design, the interface is a very basic and strict state machine. Almost every signal is directly controlled by these states making this pretty easy to read. It’s not the most efficient controller, but it works well in FPGAs where you are generally not logic-limited.
We’ll still make it available and update it. But the API is the highest priority. And we don’t want to hold up a release because of the controller.