Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

Two questions about ddr2 memory controller and DMA

1)

I have an qsys project consisting nios2, custom module and ddr2 controller all connected through avalon bus, transmitting data between custom module and ddr2 is done through c-program in nios2, although it is easy to use but it costs unnecessary resource and creates extra latency. Now I want to remove nios2 and instrantiate ddr2 controller directly in the custom module.

Although I can see the timing schedule of I/O signals of the ddr2 controller by running the example design that is generated automatically, but I'm not sure I can figure out the correct timing schedule for various operations like writing, burst writing, reading etc. It will be nice to have a datasheet that includes the timing schedule for the operations. Could anyone suggest where I can find information about that?

2)

It seems one ddr2 memory only has one data port and one address port, so it is not possible to do writing and reading at the same time like what we can do on fpga embedded 2-ports RAM block, right?

1 Reply

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    --- Quote Start ---

    Could anyone suggest where I can find information about that?

    --- Quote End ---

    The two options that will yield useful information are;

    1. Use Modelsim to simulate the design

    2. Use SignalTap II to trace the design in hardware

    You would create a Qsys design with DDR + DMA + on-chip RAM + NIOS II.

    For control, depending on your preferences, you can use the NIOS II (simulation+synthesis) or the Avalon-MM BFM master (simulation) or the JTAG-to-Avalon bridge (synthesis).

    You would then decide which sequences you want to trace, eg., NIOS II read/writes, DMA read/write single/burst. You'd initially use simulation to see whether those transactions operated as you expect, and then you'd trace them in SignalTap II to confirm the transactions match simulation (they should).

    At that point, you might find the simulation takes too long (due to the presence of a NIOS II processor and DDR controller), and simply stick to using SignalTap II for tracing the DDR activity.

    Why use simulation and not just go straight to hardware? Well, in hardware you won't be able to probe the DDR bus activity (since SignalTap II probing of the DDR interfaces is not possible), but you would be able to see these signals in Modelsim (since the simulation would include a memory model). In both simulation and hardware you can see the Avalon-MM slave activity. However, since the DDR controller uses FIFOs, you'll need to send enough data to fill those FIFOs before you start seeing wait-states generated on the Avalon-MM bus. You can use the simulation to figure out what traffic is needed to swamp the DDR controller FIFOs.

    DDR is fast for bursts and slow for random accesses. Make sure your tests include both styles of access. If your application requires random access, and DDR is too slow, then you should look at using QDRII+ SRAM.

    Cheers,

    Dave