The read and write efficiency of the 7 Series andVirtex-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 EfficiencyUtilizing 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 SeriesVirtex-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 may 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. Users may 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, users 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 andVirtex-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 andVirtex-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. When users may have concerns is during a long stream of writes as a dummy read would then consume bus cycles. Users may 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 user requests 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), users may wish to interface directly to the Native Interface rather than the User Interface. The MIG core includes a native interface with a built on 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 and so when reordering is not performed, users may be interested in the Native Interface to reduce latency.
For information of how the Virtex-6 FPGA memory controller uses Auto-Precharge commands, see (Xilinx Answer 36752)