DDR local_wdata to mem_dq incorrect outpu

[Altera_Forum]

Hello, 

 I need help about the proper write timing of DDR Controller, because the written data in local_bus is not properly outputed in the mem_dq. I'm not sure if the timing is correct because I used Avalon-MM for local bus and not certain of the "local_burstbegin" timing. I have attached the simulation waveform for reference(ddr_controller.pdf).   Thank you. Zeahr

[Altera_Forum]

Below is a conversation i had with altera about the ddr2_hp core: 

 -----------------  From Customer I am having a slight problem with the interface to the DDR2 controller. When using it in full rate mode, if I perform a write with a burst length of 2, it seems to fail if I put a large gap between the individual writes. So, if i were to issue burst_begin and write_req on one clock, take burst_begin and write_req low, wait 20 clocks, then issue another write, it seems to not pick up the second write. Then if I do a read with a burst length of 2, the first data returned appears to be the second write i performed and the second data seems to be the first data I wrote. I created a state machine that tracks every signal associated with the ddr interface and check at every clock for errors, such as read or write or burst_begin strobes coming at the wrong time, comparing everything with the ready signal, making sure address and size signals do not change mid burst, etc, and nothing is ever flagged as incorrect. I created a small buffer that will stall issuing a write command until both items of a burst length 2 are present, then issue them on successive writes, and it will work correctly. Is there something I am missing here? Can i not stall the command by not issuing another write command? Thanks for your time.   -------------------  To Customer   You are right that you cannot stall the command.  You need to give the “burst length 2” two cycle data successively. The two cycle data will be sent out with the same wr command. If you stall the data, the write command will be affected by losing the data .  -----------------  From Customer  Is this documented anywhere? Instead of giving more details in the ddr2_hp_ug, they reference the avalone burst spec, which allows you to stall. Thanks.  ------------  To Customer   This limitation is not from the avalone interface ,it is from the DDR2 Sdram operate requirement . Giving out the Dram devices write command , the write data must be given out in time , this write data cannot be stalled like avalone interface. You can refer the ddr2_hp_ug , Figure 4–5. Full Rate Write, Avalon-MM Interface In this waveform at PHY - Memory Interface , you can see each wr command for 4 successive DQ data . If you stall the input data ,the write command will have issue in PHY side .   --------------  Don't know if this applies to your situation, but you are interfacing with it the same way I was when it didn't work. Try inserting a small buffer between the command you want to issue and the ddr controller to make sure it has the whole burst before it issues the burst_begin. Let me know if that works or if this was your problem.  Kevin

[Altera_Forum]

Kevin, 

 You are right about delaying the second write causes the data lost. Although I'm using the DDR controller the case were the same, I tried to simulate and I found out that if the write burst size is 2 and if the 2nd write will be on the 6th or more clock cycle after the 1st write the data will be lost. But, the reply from altera support said that in Avalon-MM interface the write should be done consecutively.   Here is the reply from altera support.   ------------------------------------ Generally, if you want to use Avalon-MM interface for DDR controller, you need to write local logics which meet Avalon-MM protocol.    Since the local_size is 2, the local logics need to generate two continuous local_write_request with one local_burstbegin. I modify ddr_controller_test.v and get the simulation result which is similar to the figure in the User Guide. -------------------------------------   Anyway, thank you for your reply I was able to resolved the problem from your post before the altera support replied because they ask me create and send the archived project that emulate the problem for there investigation.   Zeahr

[Altera_Forum]

Glad you got the problem fixed. I have no clue why altera likes to believe that these cores follow the avalone spec. It says very clearly in section 3.10.2.1 and figure 3.12 of the avalone spec(mnl_avalon_spec.pdf) that you can pause a burst write transfer by deasserting the write command. Evidently altera likes to ignore this fact and not talk about it. Oh well.