Traffic Generator 2.0 acts as a test vehicle for users to emulate traffic to the external memory, and helps to test, debug and understand the performance of the EMIF Memory interface on their hardware platform in a standalone fashion without having to incorporate their entire design. The Traffic generator2.0 IP (also referred as TG 2.0), offers the ability to customize the testing of the external memory interface as per the user requirements. This offers the user the ability to customize data patterns being written to the memory (PRBS or any user defined pattern), address locations accessed in the memory and the order of write and read transaction patterns. The traffic generator code can be used with any FPGA architecture and memory protocol.
The traffic generator design needs to be incorporated into the EMIF IP design, during the IP generation stage. The traffic generator is intended to replace the user logic that generates the traffic to the external memory. Select the “Generate Example Design” option to generate the Traffic Generator module along with the EMIF IP from the IP Parameter Editor. In the normal operation mode, where the EMIF IP needs to be connected to user logic, use the “Generate HDL” option. If you have an example design with the Traffic Generator 2.0 enabled, you can configure the traffic pattern using the EMIF Debug Toolkit.
Fig1: Traffic Generator 2.0 generated along with EMIF IP in Example Design Mode c/cc/TG20.JPG
To include the Traffic Generator 2.0 design, the user needs to select the following in addition to the Memory and FPGA parameter options in the Diagnostics tab of Qsys:
Once the desired parameter options have been selected, click the “Generate Example Design” button at the top of the Parameter Editor. The “Generate Example Design” option enables the generated EMIF IP to include the Traffic Generator 2.0 design with the traffic pattern based on the option selected. It is important to note that selecting the “Generate HDL” option will result in the Traffic Generator 2.0 design not being included.
Fig2: Enabling Traffic Generator 2.0 from IP Parameter Editor 5/59/TG20_fig2.JPG
The EMIF Debug Toolkit offers the user interface to take advantage of the underlying Traffic Generator 2.0 infrastructure and to customize traffic patterns to the memory. The EMIF Debug Toolkit can be launched after the FPGA has been programmed.
Once the FPGA has been programmed, launch the EMIF Debug Toolkit from within the Quartus GUI by selecting Tools -> System Debugging Tools -> External Memory Interface Toolkit. After the Toolkit has been launched, the following connections need to be established, prior to running the Custom Traffic Generator.
* Create Memory Interface Connection
* Create Traffic Generator Connection
Fig3: Running TG 2.0 from within the EMIF Debug Toolkit 1/11/TG20_fig3.JPG
There are three sections available that help the user determine the traffic pattern configuration:
These tabs help to select the data patterns and the bytes that will be enabled, addressing mode and the order in which the traffic to the memory is organized. The following sections explain each tab in detail.
The Data pins section helps with customizing the patterns selected for the data pins.
Fig4: Data and Byte enables selection through EMIF Debug Toolkit GUI 0/01/TG20_fig4.jpg
This section allows the user to disable any of the data bytes if desired. All data bytes are enabled by default.
Test data mask - To individually disable the data bytes, select the Test data mask option.
Data Mask Mode
When the user selects the Fixed Pattern mode in the GUI to enter a specific data pattern, the actual data pattern that gets written to the memory could be different from the value entered through the GUI. For example, when the user enters a write data of all ONEs, the data written to the memory may not be all ONEs. There is an optional workaround for this problem by writing to the internal registers in rtl directly. The instructions to doing this are provided in the section:RTL workaround to reliably write data and enable data bytes
The TG 2.0 design does not enable the correct expected data bytes both in the default mode (all bytes enabled) and when the Test Data mask mode is selected. In the default mode, all data bytes are expected to be enabled. However, the user may not see data written to all bytes as there is a possibility of bytes getting masked. Also, when the Test Data mask option mode is selected, and when select data bytes are disabled, this can also result in the correct bytes not getting disabled. There is an optional workaround for this issue by writing the byte enable values to the internal registers in rtl directly. Refer to the section: RTL workaround to reliably write data and enable data bytes to use this workaround.
The “Address” tab of the Traffic Generator GUI provides several options to address the memory. The addressing scheme can be sequential, random or random sequential where the initial start address is random but sequential thereafter. The order of operations, including the number of write followed by read transactions, and the number of repeated write or read transactions can be set through the “Loops” tab in the GUI.
Following are the options available through the Address tab:
This specifies the pattern of addresses generated to access the memory:
Fig5: Address selection through EMIF Debug Toolkit GUI b/bb/TG20_fig5.png
The default setting on the Address Masking tabs is “Disabled”. However, the Address Masking option changes from a default setting of “Disabled” to “Fixed” while the EMIF Toolkit is opened using the “Start Again” option. This needs to be changed back to “Disabled” again. Setting bank group masking to values other than “Disabled” will lead to design errors in the default setting.
When bank group is set to a value other than “Disabled” and sequential or random sequential mode is selected, the Sequential address increment needs to be set to an even number value of 2 or higher. Else the design will error if more than 1 write/read transactions are issued to the memory.
The restrictions on the address ranges are not monitored in the Toolkit GUI. The underlying design will wrap the internal address to 0 when the address value exceeds the maximum supported value, however, this is not transparent to the user. It is recommended that the user ensures the address ranges specified in the GUI are within operable ranges.
The “Loops” section helps the user to order the transactions to the memory as desired. A unit size of transactions to the memory is defined as a “block”. This includes a set of write transaction(s) immediately followed by a set of read transaction(s).
Fig6: Traffic pattern selection through the EMIF Debug Toolkit GUI 6/6d/TG20_fig6.jpg
The traffic generator tool is very useful in running stress tests, debugging the HW platform for Signal Integrity issues in addition to emulating actual memory transactions. Here are some commonly used applications for which the Traffic Generator can come handy.
Using PRBS data on the data pins helps to emulate an actual traffic pattern to the memory interface. The Traffic Generator uses PRBS7 data pattern as the default traffic pattern on the data pins, it can support PRBS-15 and PRBS-31.
A single write followed by multiple reads to a specific address can help to debug and monitor a specific address for reliable data capture. This can be set by using the following settings:
Fig7: Configuring Loops section to support single write followed by multiple reads f/fc/TG20_fig7.jpg
If the “Loops” value is more than 1, every block of WR/multiple RD transactions will follow the same pattern. If there is a specific address to which this transaction needs to be issued, the address can be mentioned in the “Start Address” field in the Address section with Sequential Address Mode selected.
The maximum number of unique addresses that can be written to in one block is limited to 4094. Utilizing the Loops value to the maximum supported value of 4095, the address range that can be supported in one go is (Number of loops * Number of writes per block). Further address expansion can be done by changing the Start Address value appropriately and re-issuing the tests. To continue addressing sections of the memory beyond the address range that can be specified in one set of Toolkit configuration, the Start Address value tab can be used to incrementally access the next set of addresses in the memory. For example, in a memory where row address width is 15, bank address width is 3 and column address width is 10, the total number of address locations to be accessed = 2(row address width) * (bank address width * 2(column address width)). The maximum number of address locations that can be accessed is limited by the width of the internal address bus, that is 25 bits wide.
The following values are required to be set in the Address section for the above case:
Fig8: Address configuration to access the first set of addresses 4/4e/TG20_fig8.jpg
The following values are required to be set in the Loops section:
Fig9: Loop configuration to access the first set of addresses /e/e7/TG20_fig9.jpg
Each iteration can access a maximum of 4095*4094 locations (16,764,930 address locations i.e. Address ranging from 000_0000’h to FF_D001’h). To access the next 4095*4094 locations the same settings as above need to be repeated, except for Start Address which needs to be set to hex value of 16,764,931 i.e. FF_D002 (see below). The same process can be repeated to further access memory locations inside the memory. The maximum value supported is 25’h 1FF_FFFF which is the equivalent of 33,554,432 locations inside the memory.
Fig10: Address configuration to access the second set of addresses a/a0/TG20_fig10.jpg
The EMIF Toolkit is designed to provide the user the ability to change write data and to change byte enables from the Toolkit GUI. However, there is an issue, where one or more bytes can end up having incorrect data or byte enable values loaded that can result in unexpected data being written or unexpected bytes being enabled or masked. The workaround here is to manually write the desired data values and byte enable values to the corresponding internal buses in the RTL design itself, prior to compiling the design.
There is also an issue in the Status checker module when the Test data mask option is selected. The design expects masked data bytes to return a value of 1, however, this is not always the case and can result in design errors. The workaround here is to disable the check on the masked bytes.
The workaround is to bypass the GUI interface in the following cases:
Two files require modifications, they are traffic_gen and status_checker. The attached files need to replace the existing files in the following directory: project_name/qii/ed_synth/altera_emif_tg_avl_2_160/synth
The RTL files with the workaround are available in the following page: http://www.alterawiki.com/wiki/Traffic_Generator_2.0:_RTL_workaround_to_support_fixed_pattern_of_Dat...