This Answer Record contains the Release Notes for the LogiCORE IP Ten Gigabit Ethernet PCS/PMA (10GBASE-R) v1.1 Core, released in ISE Design Suite 11.4, and includes the following:
For installation instructions, general CORE Generator known issues, and design tools requirements, see the IP Release Notes Guide:
The following are generated out of the CORE Generator software:
(Xilinx Answer 33802) Virtex-6 FPGA GTH Transceiver - GTHINIT must be reissued following completion of an initial reset sequence
(Xilinx Answer 33782) LogiCORE IP Ten Gigabit Ethernet PCS/PMA (10GBASE-R) v1.1 - Incorrect logic resources reported in data sheet
(Xilinx Answer 33799) LogiCORE IP Ten Gigabit Ethernet PCS/PMA (10GBASE-R) v1.1 - Failures occur when running NCSIM Verilog simulation due to a compilation error with v6gth_wrapper_gth_init.v wrapper file from the GTH wizard.
- CR543656 - Accumulate error counts in fabric logic when no MDIO
- CR543825 - configuration_vector bits 7 and 8 were not connectedinside core
- CR537423 - Added pcf file to BitGen command line
- CR539388 - Removed hard work-arounds to now-solved silicon issues
- CR538151 - Moved GTH Wrapper examples to separate directory and added xco file
- CR538150 - Changed name of testbench to match filename - demo_tb
- CR538088 - Some files will no longer be generated unless a licenseis requested
- CR538124 - Added xcf file to aid synthesis of example design
- CR537819 - Added explanation as to why tx_fault and signal_detect inputs are not connected inside core. See User Guide.
- CR553464 - Added local accumulator in core for Test Pattern ErrorCounter when using configuration vector (ref CR543656)
- CR553465 - Allow PCS Reset bit in configuration vector bit 5 to reset BER and Error Block counters and Test Pattern select bits.
1) CR 553464- For cores generated without the MDIO interface, LogiCORE IP Ten Gigabit Ethernet PCS/PMA User Guide(UG692):
Table 5-27, configuration_vector bit 9 should be used to clear the Test Pattern Error Count in status vector bits [37:22].
2) CR 539060- During simulation, it is possible that reading from PCS Status 2 register (3.33) might return a value of XXXXXX in bits [13:8] for the BER counter if the 64b66b decoder has not been stimulated. This can happen for example if the GTH is placed into PMA Loopback and Transmit Disable is set.
3) CR 553899- During simulation, with the core set to PRBS31 test pattern generation and checking and PMA Loopback set, it is possible that the first read from the Test Pattern Error Count register (PCS register 3.43) will return all Xs. This register should return a real value when next read.
4) CR 547348- The PCS Reset register bit (register 3.0 bit 15) does not clear the PCS Loopback Enable register bit (register 3.0 bit 14)and doesnot clear the Test Pattern Error Count register (3.43). This is a divergence from the IEEE 802.3-2008 specification.
5) CR 555273- For cores generated without the MDIO interface, Configuration_vector bits 9, 138 and 139 might need to be toggled twice to clear the respective counter values in the status_vector. Once the error conditions have been removed, there will be some latency before the status_vector accumulators can be completely cleared. Toggling the configuration_vector bit(s) after removing the error condition but before the final error counts have been accumulated will result in non-zero values in the associated status_vector bits until a second toggle is performed.
6) CR 556253- Timing Simulation errors It is possible that the implementation step will have placed the xgmii_rx output pins in such a way that there is a significant skew on those outputs w.r.t. the xgmii_rx_clk output. The testbench samples the xgmii_rx outputs on the rising edges of xgmii_rx_clk, so this misalignment should present itself as simulation RX data mismatches and/or a testbench timeout. While this is an artificial situation created by adding pins to what will not normally be a pinned-out interface, adding the following two lines to the UCF file provided with the core should limit the skew on the XGMII_RX outputs and thus avoid the problem:
NET "*xgmii_rxc*" MAXDELAY = 4000ps;
NET "*xgmii_rxd*" MAXDELAY = 4000ps;
An alternative would be to add a bank of output registers to the xgmii_rx outputs and decorate those with IOB=TRUE attributes. You might then also need to change the polarity of the xgmii_rx_clk edge on which the xgmii_rx outputs are sampled by the testbench.
7) CR553078- (Verilog designs only)
Line 196 of the file <corename>/example_design/gth/v6gth_wrapper_quad.v is incorrect. This should read:
// synthesis attribute shreg_extract of rx_sync_reset0_r is no;
This prevents a warning from XST which cannot parse the original code and will explicitly avoid using an SRL for a reset synchronizer.