- Modules supporting the Aurora Simplex protocol are now available. Enables one-way, high-speed connections using a single pair of high-speed traces and fewer fabric resources. - Improved support for Virtex-II Pro X: Full support for multi-lane channels with separate clocks driving each endpoint. - New Streaming interface: Enables simple data streams over Aurora, requiring fewer control signals and decreased resource costs. - Improved design delivery: Files are now delivered with clear directory structure. Scripts allow module to be used as a blackbox, or directly imported into Project Navigator as a separate project.
- Customizer GUI now allows BREFCLK and REFCLK to be used simultaneously in a design. - Virtex-II Pro X Step 0 modules now use the recommended clocking model for TXUSRCLK, TXUSRCLK2 and RXUSRCLK. - Clock correction now works for Virtex-II Pro X Step 0 multi-lane modules. - Aurora sample UCF file settings that were causing clock combinations that would produce errors in MAP have been corrected. - The cc_status signals from the in-fabric clock correction modules are now connected to the lane logic in multi-lane Virtex-II Pro X Step 0 designs. - All standard_cc_module typos have been corrected. Furthermore, requirements for extra INIT constraints to use the modules have been removed to make the modules easier to use. - Work-arounds for the XST bug affecting single 4-byte lane modules have been built into the design. Now single 4-byte lane modules synthesize correctly in both XST and Synplify. - The specification for DCM_NOT_LOCKED has been corrected. - VHDL Pro X modules have been recoded to avoid concatenated port mappings. Pro X VHDL modules now initialize correctly. - Logic was added to Virtex-II Pro X Step 0 modules to work around the GT10 PMA_LOCK errata. - Issues with 4-byte lane word alignment and channel bonding were corrected, leading to fewer timeouts during initialization for channel bonding. - Syntax errors were corrected in the RX_LL logic for modules with 32-byte LocalLink interfaces. - The GUI now preserves lane settings when a saved ".xco" file is recustomized. - Errors in the GUI block diagram display were corrected.
- The last word of data from frames followed immediately by back-to-back empty frames is lost. This condition has an extremely small probability of occurring. - Extra top-level ports must be added to Virtex-II Pro X modules using REFCLK as their reference clock; the BREFCLKNIN and BREFCLKPIN inputs for each MGT must be connected to a pair of top-level inputs, or implementation will fail due to a bug in NGDBuild/MAP. - The PMA logic in Virtex-II Pro X can be live-locked after configuration. To correct this, the PMA_INIT signal from the MGT has been brought out to the user interface. It must be driven for several milliseconds before operating the MGTs. If the signal is clocked, the clock cannot originate from the MGTs. - The Information panel on the second page of the Customizer GUI is still inaccurate for certain types of modules; specifically, the 4-byte lanes (where the throughput does not scale accurately), and the Pro X channels (where the Pro limits are used). - There is a typo in the "readme" file that comes with each design. The instruction in section (3), part (3a) line (iii) says to go to the source directory to run the scripts for the Aurora module. It should say "Go to your rtx_402_withtest/scripts directory and run the following command:" instead. - There is a typo in the top-level file for ProX Step 0 modules (except for simplex TX modules) that usually results in back-to-back BUFGs being used in the design. This error can cause a warning in the tools and sub-optimal use of clocking resources. To correct the problem, go to the instantiation of mgt_lock_control_0_i in your top-level module, and change the signal connected to the TX_OUT_CLK port from "tx_out_clk_i" to "USER_CLK." - If you are using a module with a streaming interface and 4 bytes per lane for an asynchronous connection (different clocks on each side of the channel), you will need to modify the UCF file for your design to prevent cc events from misaligning RX data.
Open your UCF file and find the lines where you have the following parameters defined for the MGT:
This will prevent the MGTs in the design from performing clock corrections that only add or remove 2 bytes of data from the incoming stream. Without these events, the data will always remain word aligned. - ProX Step 0 designs that use MGTs on multiple die edges will fail. This is because the registers used to extend the reach of the chbondo signal interfere with the correct operation of the MGT channel bonding circuit. To correct this problem, you can remove the registers and change the channel bonding mode of the slave MGTs. However, this might cause timing difficulties in tight designs. If you have trouble with timing, try selecting a different pair of MGTs to be the MASTER and SLAVE_1_HOP MGTs. Following are the changes to be made: 1. Open the top level of the Aurora module and find the extension registers. These are in a section of the main body of code called "Create extend master chbondo signal." 2. In the set of MGTs whose CHBONDI signals are driven by one of the extend_master_chbondo_#_r signals, find the one that is closest to being directly across from the Master MGT. Change the CHAN_BOND_MODE of this MGT from SLAVE_2_HOPS to SLAVE_1_HOP. Make this change in the top level file, and in your UCF file. Replace the extend_master_chbondo_#_r signal connected to its CHBONDI port with master_chbondo_i. 3. Add a wire [0:4] *slave_chbondo_i* to the list of wires in the wire declaration section. Connect this wire to the CHBONDO output of the MGT whose CHBONDI port you just connected to master_chbondo_i 4. For the remaining MGTs on the opposite edge from the master (i.e., driven by extend_master_chbondo_#_r). Replace their CHBONDI connections with connections to slave_chbondo_i 5. Remove all FD instances for the extend_master_chbondo_#_r signals - When simplex modules are instantiated, "aurora_sample.ucf" contains invalid constraints for the standard_cc_module. Users should remove all constraints for the standard_cc_module from the UCF file. - Standard_cc_module produces WARN_CC periods that are too short for maximum length UFC messages. To work around this issue, refer to (Xilinx Answer 20182).