i'm using the sdram on the altera de2 boardi've connected a master component to the avalon-MM, that's supposed to perform reads from a slave (sdram controller) connected as well to the avalon bus the sdram and the avalon bus are synchronous with a clock of 100 Mhz the master data bus is on 32 bits, and the sdram controller's is on 16 bits when the master request a read, the signal waitrequest is asserted for about 14 clock cycles before presenting valid data, i wander if it's normal ?? i notice that when i perform a write transfer between a 32-bit master and a 16-bit slave, it's done in 1 clock cycle ! why it's not the case for reading transfers ? i've checked if the write operation has been done effectively and it's okey, indeed the 32-bit data have been stocked in 2 successive addresses in the 16-bit sdram in just 1 clock cycle ... i've a doubt that the cause could be the cas_latency parameter in the sdram controller, it's set by default to 3 clock cycles and could be changed to 1 all other parameters that i've used have default values
I don't have specific experience with the regular SDRAM controller. One of the big disadvantages to SDRAM (SDR,DDR,DDR2,DDR3) is the long read latency. SDRAM memory is horribly inefficient for single transactions. That is why processors all have instruction and data caches. The hope is that the cache will access large chunks of memory from the SDRAM and mask as much of the memory inefficiency as possible.Have a look at page 57 of this SDRAM datasheet: http://download.micron.com/pdf/datasheets/dram/sdram/512mbsdram.pdf You see how many clock cycles it actually takes to execute a single READ command. Add on top of this any latencies added by the controller. A WRITE is easy, you just give the data to the controller and forget about it. 14 cycles is probably a worst case. I expect it gets more efficient under most normal circumstances. Jake
thanks for your replies ... after reading the sdram datasheet it seems that it's normal due to so many latency parameters, so it' about 5 clock cyles to read 16 bits and then so as to read 32 bits we will need to a double time : 10 clock cycles, the avalon bus should perform 2 successive reads making the full read operation more late ...
When using SDRAM make sure to post many back-to-back sequential accesses to increase the efficiency. If you were to post 8 back to back reads (like the Nios II cache for example) then there will be a long latency of 14 cycles and then best case eight back to back cycles of valid read data. Like Jacob said, caches exist for this reason because they are designed to post many sequential accesses any time a flush/line miss occurs.This document should have diagrams showing what I just said: http://www.altera.com/literature/hb/nios2/edh_ed51007.pdf