- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Guys,
We are using Nios II with a DDR HP Controller in full-rate, both at 100MHz on Cyclone III. The design is an SOPC builder with Avalon-MM interface. Our DDR Memory is a single device 16bit Micron MT46V32M16-6. The DDR accesses work fine but slower than expected. According to the DDR Controller Table 4-2 the typical latency should be 10 clocks (=100nsec) for Write and 20 clocks (=200nsec) for Read, while we get 240nsec for Writes and 500nsec for Reads. Our parameters definitions are attached in files "DDR Memory Parameters1/2.pdf". Somebody has improvement suggestions?? We are already thankful. Thanks and Bye, ShmuelDLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1 - How are you measuring the latency?
2 - Are you passing through any bridges? Jake- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just a quick reply:
Your DDR_Controller has SysCLK as a master clock and a DDR_Controller_sysclk as a generated clock. Both are 100 MHz _but_ you have to use DDR_Controller_sysclk as you master clock (instead of SysCLK) for DMA Controller/NIOS or something else. Otherwise you have waitstates, just like you describe it above! Kest- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nice catch Kest.
He's right. You should be using the "DDR_Controller_sysclk" as the clock for everything else. Otherwise SoPC builder will automatically insert clock crossing logic which will most certainly increase latency. Jake- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It is rather a PITA that the SoPC builder just adds clock crossing logic (and bus width logic) without telling you - or requiring a box ticked.
It is very easy to gets these things added when you don't really need/want them. Does the SDRAM interface work the same way? Or is that run from the normal sysclk itself? Some of my experiments seem to imply that the sdram interface will 'post' two write cycles.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I agree. I recently gave a presentation to Altera in which I mentioned they should at least make the user aware of the fact that they are inserting clock crossing adapters and such. I think SoPC builder could benefit from "Design Advisors" that help the user understand what SoPC builder is doing and make recommendations on how to say reduce logic or increase fmax.
Now in reality if you know what you're looking for you will notice the adapters being inserted as they are called out during generation and of course they show up in your Quartus project. The input clock to the SDRAM should be your regular sysclk. However, everything that interfaces to the SDRAM should use the PLL output from the SDRAM (your DDR_Controller_sysclk). Jake- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Another issue that can't help fmax is the way the Avalon MM bus seems to do address decoding.
AFAICT it never aliases targets - so will be doing comparisons on more bits that strictly necessary. The nios selecting between tightly coupled data and other data ought to generate warnings for some cases it just allows. We have a system with a 16MB sdram (base address 16M), some 16kB (or smaller) M9K blocks (below 128kB) and some io (just above 128kb). The address decode need only use A24 (to select SDRAM) A17 (for io) and A14-16 to select between the M9K blocks. However I don't see any address aliasing - even if we put down a 12kB block of M9K. All these extra comparisons must be affecting fmax. (and there doesn't even seem to be a 'normal' option to enable an interrupt if the nios accessed an unmapped slave address.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Kest, jakobjones and dsl
I'm trying to implement your suggestion, selecting the DDR_Controller_sysclk for all SOPC devices but we need the clock also outside the SOPC block for synchronous logic. How can we transfer the DDR_Controller_sysclk instead of the regular sysCLK?? Maybe you have an idea?? Thanks and bye.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've done this before but I think it is a bad style:
Just write a AVLON-Slave component with nothing else but: external_sys_clk <= DDR_Controller_sysclk; Maybe the is a better way to do this? Kest- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- I've done this before but I think it is a bad style: Just write a AVLON-Slave component with nothing else but: external_sys_clk <= DDR_Controller_sysclk; Maybe the is a better way to do this? Kest --- Quote End --- Help please, after creating the above avalon-slave component and SOPC generation, the output clock pin doesn't appear on the sopc system symbol, what are we doing wrong??. We use Quartus8.1 and hoping for help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Don't panic! :-)
In component editor you should declare external_sys_clk as "conduit_end"-Interface with "export"-Signal Type. In .tcl file you then see somethink like that: add_interface_port conduit_end external_sys_clk export Output 1 That's all! Regards, Kest- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Kest, you are a great help.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page