Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
FPGA community forums and blogs have moved to the Altera Community. Existing Intel Community members can sign in with their current credentials.

Slow DDR access.

Altera_Forum
Honored Contributor II
2,310 Views

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, 

ShmuelD
0 Kudos
11 Replies
Altera_Forum
Honored Contributor II
1,222 Views

1 - How are you measuring the latency? 

2 - Are you passing through any bridges? 

 

Jake
0 Kudos
Altera_Forum
Honored Contributor II
1,222 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
1,222 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
1,222 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
1,222 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
1,222 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
1,222 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
1,222 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
1,222 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
1,222 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
1,222 Views

Thanks Kest, you are a great help.

0 Kudos
Reply