This Release Note is for the 2.1 CORE Generator Aurora and contains the following:
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 the core.
5) TX input before TX_DST_RDY_N ready assertion during channel initialization can corrupt the 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 UFCcan generate errors because the INVALIDATE and UFC_MESSAGE ports are only partially removed from the code.
9) Channels with LocalLink input greater than 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 should include a clause for ufc_message2_r to prevent UFC messages PDU data from being treated as part of the UFC PDU.
21) For 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.
1) 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.
2) The GUI does not allow BREFCLK and REFCLK to be used simultaneously in a design.
3) The Virtex-II Pro X step 0 modules do not use the recommended clocking model for TXUSRCLK, TXUSRCLK2 and RXUSRCLK. The clock signals to these ports should be inverted.
4) Clock correction does not work for the Virtex-II Pro X step 0 multi-lane modules. These modules should be used only when TX and RX are sharing the same reference clock. Note that there is no problem with the single lane designs.
5) Some clock combinations produce errors in MAP when using the aurora_sample designs for Virtex-II Pro X. These errors can be side-stepped by removing the LOC constraints for the BREFCLKs in the UCF file.
6) The cc_status signals from the in-fabric clock correction modules are not yet connected to the lane logic in multi-lane Virtex-II Pro X step 0 designs. This is related to item 4 above because the CC does not work correctly; the status from the CC was left unconnected.
7) Standard_cc_module.v(hd) has a bad connection that prevents clock correction from working correctly. If your module works in loop-back and single-board mode, but not board to board, the reason might be that the module does not count because a 1 is not injected in the last stage shift register counter.
To work around this issue, go to the instantiation of count_24d_a_i and connect the D port (which is currently connected to ground) to cc_idle_count_done_c.
8) Single 4-byte lane modules do not synthesize with XST. XST quits with an internal error: "ERROR: cmain.c 3082:126.96.36.199." Multi-lane modules are not affected. This module synthesizes in Synplify.
To work around this issue, refer to (Xilinx Answer 19763).
9) DCM_NOT_LOCKED is incorrectly specified in the User Guide as active Low, although it is active High. Furthermore, the Guide states that the signal must be pulsed when it is not used; instead, it should be tied Low when it is not used.
10) VHDL Pro-X modules do not initialize.
To work around this issue, refer to (Xilinx Answer 20182).