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# 25461

LogiCORE SPI-3 Link v5.1 - Release Notes and Known Issues for the SPI-3 Link Layer Core for 9.2i IP Update 1 (9.2i IP1)


This Release Note is for the SPI-3 (POS-PHY L3) Link Layer v5.1 Core released in 9.2i IP Update 1; it contains the following information: 


- New Features 

- Bug Fixes 

- Known Issues 


For installation instructions and design tools requirements, see (Xilinx Answer 25222).


New Features in v5.1  

- Support added for Virtex-5, Spartan-3A, Spartan-3AN and Spartan-3A DSP device families  

- ISE 9.2i support  


Bug Fixes in v5.1  



<General Infomration 

- The Tx and Rx cores are provided with default timing constraints in the UCF file generated with the core. Depending on the core configuration, target architecture, and speed grade, the core might run significantly faster. The user can modify the constraints to meet their performance requirements. As long as all timing constraints are met, the SPI-3 Link Core will operate at the user specified rate. Note that the best way to verify timing closure is with user logic, rather than the sample design. Implementing only the example design might artificially limit the performance of the SPI-3 Link Core (if the User Interface is routed to I/O pins). 

- A DCM with a PHASE_SHIFT on its clock is required to meet the OIF specification's 2 ns input timing requirement for Spartan3/3E parts. This solution is only necessary if the system's timing budget cannot permit the Link Core to exceed the 2 ns input requirement.  


Known Issues in 5.1 

- If the following cores do not meet timing with high effort for map and par, users can try running par with the "-xe n " option. 

- In the example design, there are some configurations with many channels where the Link Core might fail in MAP or PAR due to either a lack of pins in the example design part or due to an inability to route to speed because of poor pin placement. This problem is due to the fact that the example design runs the backend transfer control pins to I/O, which would not necessarily be done in an actual design.  

- In the example design simulation, the demo testbench may send packets to addresses beyond what the user indicated as the maximum number of channels (selected in GUI); this is not a problem because the Link Core will pass any 8-bit address through regardless of the number of channels selected (the number of channels indicates how many channels of flow control information is reported).

AR# 25461
Date Created 09/04/2007
Last Updated 05/22/2014
Status Archive
Type General Article