DDR3 with HPC/Uniphy cores: what is the reason of the delays?

[Altera_Forum]

Hello. 

 I am trying to work with DDR3 on Stratix V. I've made a variation of DDR3 controller (HPC/Uniphy) and try to write there an information.  When I choose the "Half rate" for the logic/DDR3 frequency, it works with relative little delays between the DDR3 memory bursts (avl_ready is inactive only for 1 afi_clk between the burst transfers). Tccd = 8 ns for 500 Mhz DDR3 clock.  http://f2.s.qip.ru/14jj1hcn2.png  When I choose the "Quarter rate" for the logic/DDR3 frequency, it works with relative large delays between the DDR3 memory bursts (avl_ready is inactive for many afi_clk cycles). Tccd = 16 ns for 500 Mhz DDR3.  http://f4.s.qip.ru/14jj1hcn3.png  What can be the reason of such behaviour? Is it possible to reduce delays between the bursts for the "Quarter rate"? Now it is possible to get only 1/2 of the memory bandwidth for such case. Is it possible to achieve more?  Thank you very much for answers.

[Altera_Forum]

Great thinking. I am agree with you. I am trying to work with ddr3 on Stratix V. I've made a variation of ddr3 controller (hpc/uniphy) and try to write there an information.

[Altera_Forum]

What's the width of the memory chip(s) connected and the memory bus? If You're trying to write 16 bits data to 32bits chip running at half rate, then it's 64bits inside the controller, so You need to collect 4 packets to do such burst.

[Altera_Forum]

Thank you for answers. 

 I am working with the Stratix V Development Kit. So, this is 64 bits of the memory + 8 bits for ECC.    --- Quote Start ---  If You're trying to write 16 bits data to 32bits chip running at half rate, then it's 64bits inside the controller, so You need to collect 4 packets to do such burst  --- Quote End ---   This could be a truth if avl_ready signal is active, but there is no data in my logic to send. I have data, but can't send it to the DDR3 controller because avl_ready is inactive for a long time.

[Altera_Forum]

Is this controller is also shared with other data sources? E.g. Nios?

[Altera_Forum]

It can be connected to the NIOS... 

But during the write operations being discussed, it is constantly connected to the logic.

[Altera_Forum]

New question about the DDR3 controller (Half rate now). 

 Please see the picture.  http://f2.s.qip.ru/adnbvi8h.png  Refresh time interval is shown on it. This is DDR3, Half rate, 667 Mhz. The controller have inserted the refresh inside the bursts writing process. Length of the bursts (on Avalon-MM) = 64, they are continuously filling the memory from avl_addr = 0 up to the end of the memory. No reads are performed (avl_readreq = 0 constantly). The refresh is started by the PREA command (ddr3_addr = 0x0400, so A10 = 1). After it is completed, the REFRESH command is issued. This all is ok. But after the refresh command and Trfc time, the unexpected Read command to Bank 3 suddenly appears with PREA command after it. I don’t understand, why it occurred and who requested this data (no external requests for it were performed). But this Read command and PREA after it dramatically increases the time for refreshes (they became 3 times longer), so the bandwidth falls lower than the required value.  Is it possible to understand, what is this Read command origin and purpose? Is it possible to remove it?  There is no described behavior with refreshes if the working frequency is 533 Mhz. But if to work at 667, unpredicted Read operation appears.  This is RTL simulation.  Thank you in advance for answers.

[Altera_Forum]

Altera example design works with the same behaviour. 

 If the frequency of the DDR3 memory is 533MHz or below, refreshes are working as expected. If the frequency is more than 533, unpredicted Read operation appears during the Refresh.