AR# 36719


MIG 7 Series and Virtex-6 DDR2/DDR3 Solution Center - Design Assistant - Memory controller efficiency and possible improvements


To calculate the overall SDRAM performance, peak bandwidth and efficiency must be taken into account.

Near peak bandwidth will only occur during bursts of reads or writes. Overhead will always exist on the DRAM data bus that will lower the effective data rate.

Examples of overhead on the DRAM data bus are:

  • Activate time for new banks/rows
  • Precharge time for changing rows within the same bank
  • Write recovery time to change to read accesses
  • Bus turn-around time to change from read to write
  • Refresh time
  • ZQ Calibration time (DDR3 only)
  • Periodic Reads required for the Virtex-6 DDR3/DDR2 design

To properly include any overhead into the overall SDRAM performance, the following should be used to calculate the efficiency and effective bandwidth:

  • Efficiency (%) = Number of Clock Cycles Transferring Data / Total Number of Clock Cycles
  • Effective Bandwidth = Peak Bandwidth * Efficiency

Note: Some users have separate efficiency targets for writes versus reads. Efficiency rates can be calculated separately for reads and writes.

Note: This Answer Record is a part of the Xilinx MIG Solution Center (Xilinx Answer 34243)

The Xilinx MIG Solution Center is available to address all questions related to MIG. Whether you are starting a new design with MIG or troubleshooting a problem, use the MIG Solution Center to guide you to the right information.


The read and write efficiency of the 7 Series and Virtex-6 FPGA DDR2/DDR3 design has been seen near 100%. However, while the efficiency is dependent on the memory controller design and how it is configured, the traffic pattern will have the highest impact on the efficiency. In order to calculate accurate efficiencies, it is critical that the target traffic pattern be simulated.

Customizing the Memory Controller to Increase Efficiency

Utilizing the Reordering Controller Logic

The 7 Series and Virtex-6 DDR3/DDR2 Memory Controller provides a reordering option that reorders received requests to optimize data throughput and latency. This is enabled/disabled through the ORDERING parameter. The reordering logic is very useful in systems where the memory operations are not sequential and require frequent open and closure of banks or rows. The logic is also beneficial in grouping reads to minimize bus turnaround times. In the case of sequential memory accesses, the reordering logic may not improve the overall efficiency.

When simulating traffic patterns for efficiency calculations, the ORDERING parameter can be enabled (NORMAL) or disabled (STRICT) to analyze the benefits of this logic for the target traffic pattern. This parameter can be set either through the MIG tool or in the top-level rtl module (i.e. - example_top.v or core_name.v).

For more information on the Reordering Controller, please see (Xilinx Answer 34392)

Customizing the Number of Bank Machines

The 7 Series Virtex-6 FPGA DDR3/DDR2 design stores requests from the user/native interface in Bank Machines. The number of requests that the design can store is based on the number of Bank Machines in the design. For more information on the design's usage of Bank Machines and how to change the number or Bank Machines, please see (Xilinx Answer 36505) 

Increasing the number of Bank Machines can improve the efficiency of the design. For example, if a traffic pattern sends writes across a single row in all banks before moving to the next row (writes to B0R0, B1R0, B2R0, B3R0 followed by writes to B0R1, B1R1, B2R1, B3R1), five bank machines will provide higher efficiency than 2, 3 or 4. Requests for each bank in Row0 can be assigned to the first four Bank Machines. When the request comes in for Row1, requiring a Precharge/Activate, the 5th Bank Machine can be assigned this request while the other Bank Machines complete any pending requests. Again, simulating the traffic pattern in question with different numbers of Bank Machines can show where efficiency improvements are made and when the additional logic is not beneficial.

Manually Sending Refresh and ZQ Calibration Commands

Refresh commands and ZQ Calibration commands that interrupt a stream of writes or reads will impact the efficiency. You might wish to disable these commands during known long streams and then complete the JEDEC required commands during an idle period. If this method is chosen, you MUST ensure that the JEDEC timing requirements for these commands are met. Please refer to the applicable JEDEC standard for full details.

To disable Refresh commands, set the TREFI parameter to zero. This parameter is set in the top-level rtl module (ie - example_top.v/core_name.v). To manually send the Refresh, assert the app_ref_req signal. This signal is not pulled to the top-level in the MIG design but can be found in the mem_intfc.v module.

To disable ZQ Calibration commands, set the tZQI parameter to zero. This parameter is set in the top-level rtl module (i.e. - example_top.v/core_name.v). To manually send the ZQ Calibration, assert the app_zq_req signal. This signal is not pulled to the top-level in the MIG design but can be found in the mem_intfc.v module.

For more information on Refresh and how the commands are sent in the 7 Series and Virtex-6 FPGA design, please see (Xilinx Answer 34371)

For more information on ZQ Calibration and how the commands are sent in the 7 Series and Virtex-6 FPGA design, please see (Xilinx Answer 34355)

Disabling Periodic Reads During Writes

The 7 Series and Virtex-6 FPGA DDR3/DDR2 design sends periodic reads (every 1 us) to perform phase detection and alignment to properly capture data over VT changes.

For periodic reads, users should not be concerned during reads or idle time as there will be no efficiency hit. During reads sent by the user, the design piggybacks on the read to avoid an additional read on the bus. The design will simply monitor DQS during the users read. 

You might have concerns during a long stream of writes as a dummy read would then consume bus cycles. You might want to investigate adding additional logic to the user design to manually disable dummy reads during writes. The logic would then include a counter that increments every 1 us during the stream of writes. Once the stream of writes completes, the added logic would send the number of dummy reads missed (i.e. - 4 dummy reads for 4 us of writes).

Dummy reads can be manually requested using the app_periodic_rd_req signal (available in the mem_intfc.v module). Sending the missed dummy reads MUST be completed before the you request an actual read to ensure the phase detector has performed the required shifts.

For more information on Periodic Reads and how they are used in the Phase Detector Circuit, please see (Xilinx Answer 34480)

Native Interface versus User Interface

If the target traffic pattern is found to have no efficiency gains from the reordering logic (ie - sequential addressing), you might wish to interface directly with the Native Interface rather than the User Interface. 

The MIG core includes a native interface with a built in user interface. The user interface buffers data and provides data back in the order requested by the user. The user interface does add additional latency, so when reordering is not performed, you might be interested in the Native Interface to reduce latency.

Additional Information

For information of how the Virtex-6 FPGA memory controller uses Auto-Precharge commands, see (Xilinx Answer 36752)

Note: This does not apply to UltraScale or UltraScale+ devices.

Linked Answer Records

Master Answer Records

Answer Number Answer Title Version Found Version Resolved
34243 Xilinx Memory Interface Solution Center N/A N/A

Associated Answer Records

AR# 36719
Date 06/26/2017
Status Active
Type Solution Center
Devices More Less
People Also Viewed