In Quartus® II version 6.0 SP1 and earlier, the beginbursttransfer
Avalon® signal is asserted only when a master gains arbitration. According to the Avalon Memory Mapped interface specification, the beginbursttransfer signal should be asserted during the first cycle of every burst transfer.
The DDR/DDR2 memory controller’s local_burstbegin
signal uses the Avalon beginbursttransfer
signal to manage burst transfers. If you do a burst transfer to DDR/DDR2 SDRAM memory that is in the same clock domain as your bursting master, the DDR/DDR2 memory controller may transfer an incorrect amount of data. The burst transfer may be incorrectly truncated or extended. Below are two cases that exhibit the incorrect behavior.
Case 1
When a master does a burst transfer larger than the slave’s maximum burstcount, the Avalon burst management logic segments the transfer into smaller sequential burst transfers to the slave. The beginbursttransfer
signal is asserted during the first transfer only. The beginbursttransfer
signal should be asserted during the first cycle of every burst transfer. Therefore, the DDR/DDR2 controller is not aware that the successive burst transfers are starting.
Case 2
While the slave's waitrequest
signal is asserted, the Avalon switch fabric holds the beginbursttransfer
signal until waitrequest
is deasserted. The beginbursttransfer
signal should only be active for one clock cycle. The DDR/DDR2 memory controller interperts each clock cycle beginbursttransfer
is asserted as an additional burst transfer.
To correct this problem upgrade to Quartus II version 6.1 or later.
There is also a patch available for Quartus II version 6.0 SP1. Contact Altera® Applications by filing a service request at mySupport and request patch 1.14 for Quartus II version 6.0 SP1 to correct this problem.