Forum Discussion
Altera_Forum
Honored Contributor
10 years ago --- Quote Start --- Mine appears to be a -6 (see image attachment). That seems to imply that the sdram_controller clock needs to be 166MHz if the CAS latency cycles setting is set to 3. Do you agree? --- Quote End --- No. The SDRAM clock can be slower than this. Once you get the SDRAM working at 100MHz, you can try to make it faster. Its quite possible that the FPGA speed grade is not fast enough to support 166MHz. Basically you'll have to try and see. --- Quote Start --- I still don't know which clock, the sdram_controller clock or the SDRAM_CLK out to the chip is supposed to be delayed. (Fine tuning how much it is delayed comes later). --- Quote End --- Its the clock to the external SDRAM devices that you adjust. You would see this if you looked at the DE0-nano SDRAM design. The PLL is instantiated outside the Qsys system at the top-level of the design. I did mention editing it with the MegaWizard ... --- Quote Start --- To try to answer that question, as you suggested, I attempted to look at the QSYS project you mentioned again since I edited the original compilation: synth.tcl compiles but in qsys_system you don't use a pll so that doesn't answer the question about the two different sdram clocks. qsys_system.tcl doesn't compile: "Error:can't find package qsys exactly 14.0" synth_qsys.tcl compiles but doesn't seem to do anything relevant. The qsys project file is the same as before. still no PLL. The other tcl files don't seem relevant to answering the question. --- Quote End --- Which version of Quartus are you using? The notes in the DE-nano SDRAM thread indicate I tested it under I tested it under Quartus 12.1, 13.0, 13.1, and 14.0. Perhaps you are using 14.? --- Quote Start --- So, that's done. Now would you be able to tell me which of the two clocks (the sdram_controller clock and/or the SDRAM_CLK out to the chip) is supposed to get the -3ns delay? I know it needs to be tuned with TimeQuest but a starting point would be nice. --- Quote End --- The clock to the SDRAM gets the delay. --- Quote Start --- A second, more important issue, is whether or not the SDRAM chip is even fast enough to process 640 x 480 x 30fps x 2 (read + write) = 18,432,000 random read/write operations every second. Even at 100,000,000Hz you would think there would be plenty of time but maybe not with all of those other delays, pre-charges, etc going on.. Are 18.5 million random operations a second too much in your opinion? --- Quote End --- No idea. That is why you need to simulate the design. The Altera SDRAM controller could be totally useless, but you will not know until to simulate a design with traffic that is representative of your design. Cheers, Dave