DDR vs. SDR RAM...

Hi,

Is it a solution to use another type of SDRAM controller that runs on a higher clock speed than the Nios. I think SDRAM can handle more than 100Mc as input clock.

Then probably you can reduce 12 clocks on 50 Mc to 12 clocks on 100Mc.

Can you try to run your Nios on a higher clock frequency? Eventually using another speed grade for the FPGA? I think 80 to 100Mc must be possible, depending on the number of peripherals you connect to the avalon bus.

Stefaan

You're never going to overcome 12 clocks with MHz. You'd need close to 500-1200 MHz to get the performance you should be getting at 100MHz. That's not going to happen.

The only thing we can do right now is use memory that has fixed timing like SRAM or onchip SRAM.

My question was whether DDR is any better/closer in this respect than SDR.

Ken

The SDRAM controller included in the Nios II kit only keeps one bank open at a time.

The DDR controller from Altera keeps multiple banks open.

This should help improve performance but is a function of your access pattern.

The main problem with the Nios II/f data cache and DRAM performance (SDRAM or DDR) is that it only has a 4-byte line so it doesn't perform burst transfers to/from the DRAM.

Hi James,

Can you elaborate on NiosII/f SDRAM access? Jesse indicated the largest part of the problem was that the NiosII/f data master was not "Latency Aware".

So anything not dma'd or read out of the cache incurs a large timing hit as demonstrated in the other thread on this topic -even if the reads are back to back in the same bank.

A work around or a glimpse of the roadmap would sure be welcome.

Thanks,

Ken

Hi Ken,

(I still owe you guys a write-up, it will come soon I swear!)

My eariler comments about latency awareness were a bit mis-guided. A subsequent poster in that thread hit the nail on the head -- in a CPU you can't just queue reads (that is what utilizing latency awareness implies: you 'post' reads and get them back in successsion). The reason makes my earlier statement look a bit dumb: its a processor. There isn't a way to know whether the data you're reading in one instruction has relevance in the next instruction and so forth. For this reason its crutial, for performance, to have things cached.. or utilize some other HW (dma) that can take advantage of latency to shovel things around.

James could probably elaborate more on the above, discussing things such as scroreboarded loads, but I will leave that to him if he wishes as I&#39;m not the processor expert (aside from sitting next to James http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif ).

That said I think I know what James was getting at in the last post: the data cache line size. When a data cache "line" needs to be updated, it is done a line-at-a-time. So if you want faster SDRAM access from the CPU, it can therefore be achieved if your cache lines are big enough to permit latency-awareness (pipelining) of the reads to fill that line; increasing our cache line size would do that. Now, that said, there are probably reasons and ramifications for the reason its only a 32-bit line size... I&#39;ll leave that to James.

One thing I&#39;d like to include in my long-overdue write-up is to discuss ways to simplify DMA transfers (make them take fewer instructions to setup) to help alleviate this.

As for your original SDRAM question: I&#39;m afraid I&#39;m not the DDR expert. I&#39;ll be learning more about it in the coming months though as our next dev boards will include DDR SDRAM.

Hi Jesse,

I&#39;m still confused as to why the timing diagrams in the SDRAM datasheet show that we can get data in a fraction of of the time it actually takes.

Once the chipselect and address are on the address bus its only a clock or three before the sdram chip has the data ready on the data bus. So where are the other 9-11 clocks consumed? Is there a 6+ clock delay for addresses eminating from the Nios onto the Avalon bus? Or are there long delays delivering the data back into the Nios?

It wasn&#39;t that long ago I was writing code on PC&#39;s running around 100 MHz with same PC100 memory and random memory reads were 50-60ns if I remember correctly. What gives?

Thanks,

Ken

Hi Ken,

I don&#39;t know if you read my previous posts, or they were a bit confusing, but looking at the HDL code generated by SOPC Builder for the Avalon SDRAM controller and at the SDRAM datasheet I see that it takes 7 clocks from the moment the controller gets the read request until it puts the readdata back onto the bus (for CAS latency = 2), assuming that the row is already active and we don&#39;t need the RAS phase.

Hi Clancy,

So is the controller pipelined then? Is that the reason Altera can claim one cycle access? Does it pump out successive words every clock after the 7?

Have you learned enough to account for all 12 cycles on the back to back reads from the same row?

Do you think its inevitable or can something be done?

I need fast 15bit table lookups so what I did was respin my Cyclone/SDRAM board with Stratix and SRAM. I should have protos next week. I would like to be able to go back to Cyclone/SDRAM if the core+controller can be made workable.

Thanks,

Ken

Hi Ken,

Yes, the controller is pipelined, so is the SDRAM chip. You can achieve 1 word per clock reads only if you queue up the read requests - in advance - in order to fill up the pipeline (DMA like). The CPU data master cannot request data in advance because usually it cannot predict where the next read will be, so it has to wait until the current read goes all the way through the pipeline before the CPU finishes the current instruction, advances to the next and issue the next read. 7 clocks are spent in the controller/chip, but I am still not sure where the rest of 5 clocks come from and the source code for NiosII is not available.

The NiosII data cache doesn&#39;t help in this case, but if YOU know where your reads will be, you can try and write a custom cache controller to optimize the read pipeline (things could get complicated though, and if you need the product fast maybe SRAM is a better option).

Good luck,

clancy