We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 19632

v2.0 COREGen Aurora - Release Notes and Known Issues


General Description: 

This Release Note is for 2.0 COREGen Aurora and contains the Known Issues.


Known Issues  

Some of these issues have been fixed in Version 2.1. See (Xilinx Answer 15463) for more information. 


1. Custom_cc_module.vhd is not generated.  

2. Standard_cc_module.vhd is not generated. 

3. Aurora_sample.ucf is not generated for VHDL modules. 

4. Code produced when using 4-byte lane option has errors. 4-byte lanes were intended for a future release of COREGen Aurora. 

5. TX input before TX_DST_RDY_N ready assertion during channel initialization can corrupt initialization sequence in single lane modules. The gating logic for the TX input is incorrect in the single lane case. 

6. UCF files generated for modules using MGTs on the bottom edge have incorrect MGT index values. The index value from the GUI is not processed correctly before being written to the UCF files for the bottom edge MGTs. 

7. GUI allows the generation of modules before lane locations or clocks are specified. This leads to the generation of incomplete VHDL files that cause syntax errors during simulation and synthesis. 

8. VHDL modules without NFC or UFC generate errors because the INVALIDATE and UFC_MESSAGE ports are only partially removed from the code. 

9. Channels with LocalLink input > 24 bytes have corrupted data. An extra stage of logic is needed to move data on the extreme right side of the channel. 

10. Single lane modules generated without UFC cause frame errors and odd behavior on the LocalLink RX interface of their channel partners. The equation for next_eof_2_c is corrupted by the pruning algorithm; as a result, once this state is active, it never deactivates, disrupting the state machine. 

11. The picture of the Aurora module in the GUI is inaccurate. Some of the RX LocalLink signals do not include _N; some of the Clock Signals use names from the legacy Aurora modules; some legacy CC interface signals are also used. 

12. The Aurora receiver does not ignore the LSB of the UFC code nibble. While this does not cause problems when receiving data from the reference design TX module, the Aurora Specification requires the module to ignore this bit. 

13. In a single lane module, if a UFC message is inserted between back to back PDUs and is followed immediately by an NFC message or a CC event, the PDU that follows is dropped.  

14. In a single lane module, if an NFC message is started during the first dead cycle after an EOF, the PDU state machine loses synchronization with the TX_DST_RDY_N signal, leading to frame errors or lost data. 

15. Ufc_message_count_r in tx_ll_control.v needs a non-blocking assignment with an assignment delay to be consistent with other sequential signals. 

16. The NFC logic in the TX_LL_CONTROL module currently counts TX_DST_RDY_N deassertions for CCs as NFC deassertions. This could allow an NFC initiator to receive fewer idles than it requested in certain cases.  

17. Ufc_tx_ack_i was declared twice in aurora_sample.v, causing errors during synthesis.  

18. In aurora_sample.v, ufc_tx_ack_i should have been named ufc_tx_ack_n_i. 

19. In multi-lane designs, if an NFC message is started during the first dead cycle after an EOF, the PDU state machine loses synchronization with the TX_DST_RDY_N logic leading to frame errors and data loss. 

20. In a six lane design, MESSAGE[2] should include a clause for ufc_message2_r to prevent UFC messages PDU data from being treated as part of the UFC PDU. 

21. In designs with greater than 16 lanes, UFC REM is calculated incorrectly. 

22. When a module responds to an NFC message while sending a PDU interrupted by an UFC message, the UFC message is corrupted because the HALT signal freezes the data path while the UFC data is passing through it. 

23. The standard_cc_module does not work correctly when synthesized with Synplify. The shift register counter is interpreted correctly by XST, but Synplify synthesizes it as default flops and SRL16s, which all initialize to 0. As a result, the counter never changes value and CCs are never sent. 

24. Pressing the data sheet button does not produce an Aurora data sheet. 

25. 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. 

26. The GUI does not allow BREFCLK and REFCLK to be used simultaneously in a design.

AR# 19632
Date Created 09/03/2007
Last Updated 05/16/2014
Status Archive
Type General Article