External Memory Interfaces Arria® 10 FPGA IP User Guide

ID 683106
Date 4/01/2024
Public
Document Table of Contents

14.8. Using the Traffic Generator with the Generated Design Example

This topic provides tips for using the generated design example with the traffic generator to assist in design evaluation and debugging.

For general information about the generated EMIF design example, refer to the External Memory Interfaces Arria® 10 FPGA IP Design Example User Guide .

  1. Create an Quartus® Prime project and open your EMIF IP in the parameter editor.
  2. In the parameter editor, set the correct parameter values for your memory interface, including correct board timing values for your PCB.
  3. On the Diagnostics tab, set Calibration Debug options > Quartus Prime EMIF Debug Toolkit/On-chip Debug Port to Add EMIF Debug Interface. This step creates connectivity to the EMIF Toolkit for debugging.
  4. On the Example Designs tab:
    • Select Synthesis.
    • Select the HDL format that you want.
    • Set Target Development Kit > Select Board to None. This setting ensures that the design example is generated for your specific device part number.
  5. At the top right corner of the parameter editor, click Generate Example Design. The system generates the design example and populates the top-level project directory with the IP file directories:
    • ed_synth.qsys is the design example Platform Designer file and includes the EMIF IP, the traffic generator, RZQ, and reset splitter components.
    • ed_synth.qpf is the design example project.
  6. Open the generated design example project, ed_synth.qpf, and verify that the device part number is correct.
  7. By default, the traffic generator is configured to run through one iteration of its tests. For general debugging, you may find it preferable to let the tests run continuously. To configure the tests to run continuously:
    1. Locate the ed_synth.v file in the /synth directory, and open the file in a text editor.
    2. Search for .TEST_DURATION ("SHORT"), and change it to .TEST_DURATION ("INFINITE"),.
    3. Save your change.
    Note: Running the traffic generator in infinite mode is not applicable for use with RLDRAM 3 EMIF IPs.
  8. At this point it is advisable, though not mandatory, to run analysis and elaboration. Doing so helps show project structure and verify assignments.
  9. For each of the following top-level signals, either add virtual pins or route them out to external pins connected to test points for monitoring with an oscilloscope or LEDs:
    • local_cal_success
    • local_cal_fail
    • traffic_gen_pass
    • traffic_gen_fail
    • traffic_gen_timeout
  10. Add pin location assignments for your PCB.
  11. Add Signal Tap to the project. The following are recommended signals to tap:
    Pins: All global_reset_n
    local_cal_success
    local_cal_fail
    traffic_gen_pass
    traffic_gen_fail
    traffic_gen_timeout
    Signal Tap II Pre-synthesis and search for signal names with wildcards as appropriate
    Pass-not-fail signals pnf_per_bit
    pnf_per_bit_persist
    Avalon bus signals amm_read_0
    amm_readdatavalid_0
    amm_ready_0
    amm_write_0
    amm_address_0
    amm_burstcount_0
    amm_byteenable_0
    amm_readdata_0
    amm_writedata_0
    For the Signa Tap clock, Signal Tap II: Pre-synthesis emif_user_clk
  12. In the Quartus® Prime Device Settings, set Device & Pin Options > Unused Pins to As input tri-stated with weak pullup. Set the default I/O standard as appropriate.
  13. Compile your project.
  14. Check the Timing Analyzer Report DDR report and verify that the project meets timing requirements and that pinouts are as expected.

Information on Traffic Generator status signals

  • The pnf_per_bit signals are one bit for each bit on the Avalon interface. For a 32-bit-wide memory interface, this equals 256 bits for a quarter-rate interface.
    • pnf_per_bit[x] is high when the test is working correctly and is a transitory signal going low if incorrect data is seen.
    • pnf_per_bit_persist[x] is the same as pnf_per_bit but once set low , it stays low.
  • The mapping of the pnf bits is dependent on the memory bus width and the Avalon interface bus width. The standard DDR3 memory access cycle is a burst length of 8. An example mapping for a 32-bit-wide memory interface is shown below. A similar mapping approach applies to any other supported interface memory bus width.
    • pnf[0] maps to dq[0] for the 1st beat of the memory bus burst
    • pnf[1] maps to dq[1] for the 1st beat of the memory bus burst
    • ...
    • pnf[31] maps to dq[31] for the 1st beat of the memory bus burst
    • pnf[32] maps to dq[0] for the 2nd beat of the memory bus burst
    • pnf[64] maps to dq[0] for the 3rd beat of the memory bus burst
    • pnf[96] maps to dq[0] for the 4th beat of the memory bus burst
    • pnf[128] maps to dq[0] for the 5th beat of the memory bus burst
    • pnf[160] maps to dq[0] for the 6th beat of the memory bus burst
    • pnf[192] maps to dq[0] for the 7th beat of the memory bus burst
    • pnf[224] maps to dq[0] for the 8th beat of the memory bus burst
    • And so forth.
  • The traffic_gen_pass signals goes high if there are no bit errors and the test loops for a specific number of cycles. If you have configured the traffic generator to operate with infinite test duration, traffic_gen_pass never goes high.
  • traffic_gen_fail goes high whenever a pnf signal goes low, regardless of how many loops the test runs.
  • traffic_gen_timeout goes high when there is a timeout due to a problem with the traffic generator; such occurrences are extremely rare.