PCI-EXP-T42G5-N1

ispLever CORE TM PCI Express User’s Guide October 2005 ipug25_03.0 Lattice Semiconductor PCI Express User’s Guide Introduction PCI Express is a high performance, general purpose Serial I/O Interconnect defined for a wide variety of future computing and communication platforms. The basic premise of PCI Express is that the host PCI software remains compatible with an endpoint device without new drivers or operating-system software. Salient PCI attributes, such as its usage model, load-store architecture, and software interfaces, are maintained, whereas its bandwidth-limiting and parallel bus implementation is replaced by a highly scalable, fully serial interface. PCI Express takes advantage of recent advances in point-to-point interconnects, switch-based technology, and packetized protocol to deliver new levels of performance and features. Lattice’s PCI Express IP Core is an endpoint device supporting a x1 link. It consists of three layers of the endpoint device namely the Physical, Data Link and Transaction layers. This IP core targets the programmable array of the ORCA Series 4 ORT42G5 FPSC. The complete solution supports up to 2.5Gbps data rate as specified in PCI Express Specification 1.0a. For more information on this and other Lattice products, refer to the Lattice web site at www.latticesemi.com. This user’s guide explains the functionality of the Lattice PCI Express core and how it can be implemented to provide endpoint interface to an application running in the Transaction layer. The PCI Express core comes with the following documentation and files: • Data Sheet • User’s Guide • Lattice gate level netlist • Model for simulation • Core instantiation template • Testbench and testbench coding template Features • Lane width of x1 configuration. • Effective raw data rate of 2.5Gbps/lane/direction (with target device support). • 8b/10b encoding / decoding for symbols and special symbols (with target device support). • Data scrambling / de-scrambling • Link initialization and training. • Flow control initialization. • Data integrity checking for both Data Link Layer Packets and Transaction Layer Packets. • Data Link Layer retry mechanism for transmitted Transaction Layer Packets. • Acknowledgement and Timeout replay mechanisms. • All error statuses are reported in the backend User Interface • Credit availability calculation and reporting General Description PCI Express ties together various components within a system and provides connection points for future highspeed devices. The following diagram gives an overview of how PCI Express is used in a typical system. 2 Lattice Semiconductor PCI Express User’s Guide Figure 1. Typical PCI Express Topology CPU PCI Express PCI Express Endpoint Root Complex Memory PCI Express PCI Bridge PCI Express PCI Express Switch PCI Express Legacy Endpoint PCI Express PCI Express Legacy Endpoint Legacy Endpoint Legacy Endpoint In the above environment a Root Complex denotes the root of an I/O hierarchy that connects the CPU/memory subsystem to the I/O. A Switch device is defined as a logical assembly of multiple virtual PCI-to-PCI Bridge devices An Endpoint device refers to a type of device that is either the Requester or Completer of a PCI Express transaction either on its own behalf or on behalf of a distinct non-PCI Express device (other than a PCI device or Host CPU), e.g., a PCI Express attached graphics controller or a PCI Express-USB host controller. Endpoints are either classified as legacy or PCI Express Endpoints. It is basically a device with a type 00h Configuration Space header. PCI Express uses a packetized and layered protocol structure. The three main protocol layers implemented within the core are the Physical Layer, Data Link Layer and Transaction Layer. Packets are formed in the Transaction and Data Link Layers to carry the information from the transmitting component to the receiving component. As the transmitted packets flow through the other layer, they are extended with additional information necessary to handle packets at those layers. At the receiving side the reverse process occurs and packets get transformed from their Physical Layer representation to the Data Link Layer representation and finally to the form that can be processed by the Transaction Layer of the receiving device. The following figure shows the conceptual flow of packet information through the layers. 3 Lattice Semiconductor PCI Express User’s Guide Figure 2. PCI Express Layers Software Software Transaction Transaction Data Link Data Link Physical Physical Logical Sub-block Logical Sub-block Electrical Sub-block Electrical Sub-block Rx Rx Tx Mechanical Tx Mechanical Functional Description The Lattice PCI Express core is an implementation of the logical sub-block of Physical layer, Data Link Layer and part of the Transaction layer as specified in the PCI Express Base specification revision 1.0a. • All configuration registers are left out of the core and all required status signals are made available at the User Interface side in order to facilitate an integrated easy implementation of configuration registers in the User Logic. • The Lattice PCI Express core does not currently support L0s, L1, L2 and External Loop back states The following figure gives a graphical indication of the layers implemented (shaded blocks) in this PCI Express solution (Lattice IP on ORT42G5 FPSC device). Figure 3. PCI Express Layers Implemented PCI Express PHY Layer Electrical sub block PHY Layer Logical sub block DATA LINK Layer Transaction Layer and Application Specific Logic A typical implementation of these layers is better illustrated in the following block diagram. 4 Lattice Semiconductor PCI Express User’s Guide Figure 4. Block Diagram PHYSICAL LAYER Electrical Block PHYSICAL LAYER Logical Block DATA LINK LAYER TLP and DLLP Transmission Block Scrambler and Framer PCI Express Link SERDES, 8b/10b System Bus of ORT42G5 42G5 Interface Link Training and Configuration TRANSACTION LAYER Transmit User Interface Block TX USR Interface Credit Calculation Block Credit Available Control Status Interface TLP and DLLP Receive Block Descrambler and Deframer Receive User Interface Block RX USR Interface Physical Layer Implementation Electrical Sub Block The Electrical sub block of the Physical Layer is implemented in the Embedded logic of the FPSC. It includes one channel of SERDES and also 8b/10b logic. The SERDES circuitry consists of a receiver, transmitter, and auxiliary functional blocks. It supports serial data up to 3.7 Gbits/s. 8b/10b Decoder/Encoder logic follows 8b/10b transmission code as defined in the ANSI X3.2301994 and IEEE 802.3z specifications. Refer to the ORT42G5 and ORT82G5 data sheet for more details on SERDES and 8b/10b operation. Logical Sub Block The Logical sub block of the Physical Layer is implemented in the programmable logic portion of the FPSC. This includes the Scrambler/De-scrambler, Framer / De-Framer, LTSSM block and LWLSN block. These blocks are described below: Scrambler/De-Scrambler The Scrambler/De-scrambler function is implemented using Linear Feedback Shift Registers. This is performed by serially XORing the 8-bit character with the 16-bit output of the LFSR. The final output stage of the LFSR is XORed with the lower bit of the data character and then both the LFSR and data register are serially advanced. The LFSR implements the polynomial: G(S) = X16 + X5 + X4 = X3 + 1 Framer/De-Framer The Framer/De-Framer implements the mechanism which uses special symbols like K28.2 (SDP) to start a DLLP, K27.7 (STP) to start a TLP, and K29.7 (END) to mark the end of either a TLP or a DLLP. When no packet information or special ordered-sets are being transmitted, the transmitter will be sending idle data. The idle data consists of the data byte 0 (00h). During transmission of idle data the skip ordered set will continue to be transmitted. 5 Lattice Semiconductor PCI Express User’s Guide TLPs are framed by placing a STP Symbol at the start of the TLP and an END Symbol or EDB Symbol at the end of the TLP. DLLPs are framed by placing an SDP Symbol at the start of the DLLP and an END Symbol at the end of the DLLP. Link Training and Status State Machine (LTSSM) The LTSSM is a set of interacting state machines implemented as per PCI Express base specification 1.0a section 4.2.5, which includes the following category of state functions: Detect: To detect whether the far end receiver is powered on or not. Polling: Transmission and reception of training ordered-sets to establish bit lock and symbol lock. Configuration: Transmission and reception with negotiated data rate with configured link width. Recovery: Transmission and reception of training ordered-sets to re-establish bit lock and symbol lock. L0: Normal operation where data and control packets are transmitted and received. L0s: Power saving state. L1: Additional power saving state. L2: State to conserve power aggressively. External Loop Back: Loop back between receiver and transmitter for testing and validation purposes. Disabled: Link is disabled. Link Control Reset: Link is reset. Note: The Lattice PCI Express IP core currently does not support L0s, L1, L2 and External Loopback states. Link Width and Lane Sequence Negotiation (LWLSN) The link width and lane sequence negotiation logic helps the LTSSM block to negotiate and finalize the link and lane number of the core as part of the training process. The core follows the steps as specified in the PCI Express spec 1.0a for an end point device. Data Link Layer Implementation The Data Link Layer tracks the state of the link. It communicates link status with the Transaction and Physical Layers, and performs Link Management through the Physical Layer. Before starting normal operation following power-up or interconnect reset it is necessary to initialize flow control for the virtual channel. The TLP traffic starts only after this flow control initialization. This flow control initialization is implemented in the Data Link layer according to PCI Express Specification 1.0a. Transmit Path Transmit TLP Block The Transmit TLP processing block implements the Data Link Layer requirements for TLPs; sequence number generation mechanism and LCRC calculation. It appends the information to the TLP that is getting transmitted. Also it implements the mechanism to resend the same TLP if a retry is requested from the receiver component. To support this mechanism it has to store the whole TLP that is being transmitted until this component receives an ACK for that particular TLP or until time-out indication occurs. 6 Lattice Semiconductor PCI Express User’s Guide Transmit DLLP Block The Transmit DLLP processing block, generates ACK or NAK DLLPS based on the instructions from the Receive TLP processing block. This block also generates InitFC DLLPs corresponding to FCI requirements. Appropriate power management DLLPs are generated as instructed by external power management logic. This block consists of a 16-bit CRC generation logic that adds the calculated CRC to the tail of all transmit DLLPs to meet data integrity requirements. Receive Path Receive TLP Block Receive TLP processing block implements sequence number checking, data integrity checking, and through LCRC checking for received TLPs. It includes an appropriate retry mechanism to respond to any errors detected in received TLPs. This block is provided with a buffering mechanism to hold the whole TLP until its data integrity is checked and an appropriate instruction is generated to the Transmit DLLP block to send ACK and NAK DLLPs. Associated retry logic implements the time-out mechanism as specified in the PCI Express specification. After all these Data Link Layer requirements for a TLP are met the TLPs are sent out over Receive TLP interface to the transaction layer. Receive DLLP Block The main function implemented in this block is related to the processing of all incoming DLLPs as listed below: • Data integrity checking of all DLLPs through CRC checking. • Detection of different types of DLLPs through DLLP type decode. • Extraction of different fields of DLLPs based on the type of the DLLP decoded. • ACK and NAK processing. In case of CRC error the DLLP is discarded and the error is transmitted to the user logic. If the DLLP passes data integrity checking it is processed as described below: • ACK DLLP: TLP Sequence number received in this DLLP indicates successful receipt of TLPs up to this Sequence number. This information is passed to the transmit TLP processing block to manage its transmit retry mechanism. • NAK DLLP: This TLP sequence number negative acknowledgement initiates a Data Link Layer retry by the transmit TLP processing block using its transmit retry mechanism. • InitFC1, InitFC2 and UpdateFC DLLPs: Used for Flow Control Initialization and Credit Calculation. • Power Management DLLP: PM request type is extracted from this DLLP and is made available in the User Interface side. Receive User Interface All Receive transactions to the user interface are synchronized with the rising edge of the div2_pclk. Signal transactions between the core and the user interface are carried out in the form of received TLPs. Apart from the received data the core also provides status of the received TLPs and DLLPs. In case of error during reception of a TLP or DLLP a corresponding error signal is asserted to notify the user interface. Rx TLPs are output by the core through a 32-bit data bus, rxtlpu_data. The following handshake signals are provided to ensure a smooth and controlled interface between the core and the user interface. rxtlpu_st – The core loads the first DWORD of the TLP and asserts this output signal to indicate the start of Rx TLP. All remaining parts of the TLP are loaded out of the core in subsequent clocks. The core at the positive edge of the div2_pclk clock, sends out each DWORD of the TLP. 7 Lattice Semiconductor PCI Express User’s Guide rxtlpu_sd – The core asserts this signal when the first DWORD of the “data” within the TLP is sent out by the core. rxtlpu_end – The core indicates the last DWORD of the TLP at the end of the transaction by asserting this output signal. un_sup_req – This error signal for Unsupported request is driven high from start to end of the received TLP. pois_tlp – This error signal for Poisoned TLP is driven high from start to end of the received TLP. malf_tlp – This error signal for Malformed TLP is driven high at any time from start of the TLP and will be asserted till the end of the TLP. Figure 6 shows the signal status for Receive Path User Interface. PM DLLP Transmission Apart from generating requests for transmitting TLPs the user interface logic can also initiate a request to transmit Power Management (PM) DLLPs. Input signals txpm_dllp_type and tx_pm are used for transmitting PM DLLPs. The user interface logic places a valid PM DLLP type for transmission in txpm_dllp_type and asserts tx_pm as a strobing signal. Output signals rxpm_dllp_type and rx_dllp_val are provided to notify the user interface logic about the received PM DLLP. Figure 7 shows the signal status for PM DLLP Transmission. Transaction Layer Implementation Transmit Path The Transmit Path acts as a bridge between the Data Link Layer and User Interface in the transmit path. This module provides handshake between the core and user logic request to transmit TLPs and PM DLLPs. In addition, this module performs “Credit Available” calculation by monitoring the types of TLPs transmitted and the credit values received from the other node through Update FC DLLPs. It accumulates these credit values separately for PH, NPH, PD and NPD types and makes them available to the User Interface side based on the selected packet type as indicated in the input signal pkt_type. Refer to the Credit Available Calculation section for more details. Receive Path This module consists of all logic to provide handshake between the core and user interface for received TLPs. It checks for errors in the received TLPs and notifies the user interface side in case of errors like Poisoned TLP, Unsupported TLP type and Malformed TLP In addition, credit consumed in received TLP is calculated in this module and Calculated Credit is sent as update information to Data Link Layer to send Update FC DLLP. Credit Available Calculation The core maintains the value of Available Credit for each packet type. User logic can fetch this Credit Available value from the core by appropriately selecting the packet type in the input signal pkt_type. The core outputs the Available Credit in the output signal crdt_avail for the selected packet type. Please refer to the Transmit User Interface section under Timing Diagrams for more detail. The core stores the Credit Limit (CL) for each packet type that is extracted from the latest UpdateFC DLLPs received from the other side of the link. The core also calculates the Credit Consumed (CC) value for each packet type whenever a TLP is transmitted from the core into the PCI Express Link. The Credit Available (CA) value for 8 Lattice Semiconductor PCI Express User’s Guide each packet is derived by subtracting the Credit Consumed from the Credit Limit (CA = CL - CC). The Credit Available value is calculated and stored separately for packet types P, NP and CPL and is made available to the user logic for the selected packet type. It is expected that the user logic take into account the Available Credit before sending a request to the core for transmitting a TLP. The core will not verify the credit availability while transmitting a TLP. Error Conditions Receive logic of the core checks the received DLLP and TLPs for various error conditions. In case of error, associated signals are asserted to the user logic and the DLLP or TLP is processed as per the specification requirement. Details of the error conditions are described below: Unsupported Request The following types of TLPs are not supported by the core: • Configuration Read Type 1 • Configuration Write Type 1 • I/O Read Request • I/O Write Request • Memory Read Request-Locked • Completion for Locked Memory Read without Data - Used only in error case. • Completion for Locked Memory Read - otherwise like CplD. If the core receives any one of these types of TLPs, an error is transmitted by the user interface signal un_sup_req. Poisoned TLP There is no support to generate Data Poisoned TLP for transmission. But the core supports Data poisoning checks in the received TLP. If the EP bit in a received Write Request (Posted or Non-Posted) or a Read Completion TLP (bit14 of header1) is set the core transmits the error in the user interface signal pois_tlp. Malformed TLP Malformed TLP detection is notified for the following cases: • Size of TLP is more than max_payload_size (256 DWORD) • Size of TLP exceeds length field • Size of TLP doesn’t match length field • Undefined type of TLPs • Default Traffic Class designator violation for Power Management message and Error Signaling messages The core transmits the error in the user interface signal malf_tlp. Bad TLP This error signal is generated to indicate that the received TLP is erroneous when there is no rx_err signal from the Electrical Sub Block of the Physical Layer. The condition that leads to asserting this signal are listed below: • CRC mismatch for Nullified TLP 9 Lattice Semiconductor PCI Express User’s Guide • CRC error for Normal TLP • If CRC is ok and received Sequence of the TLP violates the condition (NEXT_RCV_SEQ - Sequence Number) mod 4096 ≤ 2048 The core will discard this Bad TLP and reply with a NAK DLLP. Error signal bad_tlp will be asserted to notify the user logic. Bad DLLP This error signal is generated to indicate that the received DLLP is erroneous when there is no rx_err signal from the Electrical Sub Block of the Physical Layer. The condition that leads to asserting this signal is listed below: • CRC error in the received DLLP The core will discard this Bad DLLP and error signal bad_dllp will be asserted to notify the user logic. Data Link Layer Protocol Error The Data Link Layer Protocol Error is generated for the following conditions in a received DLLP: • If ((NEXT_TRANSMIT_SEQ - 1) - AckNak_Seq_Num) mod 4096 > 2048, or • If the above error condition is not noticed, but (ACKNak_Seq_Num - ACKD_SEQ) mod 4096 => 2048 Refer to Figures 3-17 in the PCI Express Specification 1.0a for more details. The core will discard this DLLP and error signal dll_perr will be asserted to notify the user logic Replay Number Rollover The Replay Number Rollover status signal is a pulse of one clock duration and is generated when the internal replay number changes from 3 to 4. The core asserts the user interface signal rnum_rlor to indicate this rollover. Replay Timeout The Replay time is the time between transmission of the last DWORD of a TLP and reception of the first DWORD of an ACK/NACK DLLP for that TLP. The timer is restarted for any of the following conditions: • When a DLLP is received and the retry buffer has some of the un-acknowledged TLPs • At the beginning of a TLP transmission if the timer is not running • At the expiration of the timer value. The core asserts the user interface signal rply_tout to indicate this timeout. More details on all these error signals are available in the Timing Diagram section. User Logic Interface Transmit User Interface All transactions initiated from the User Interface side are synchronized with the rising edge of div2_pclk. Transactions between the core and the user interface logic are carried out in the form of TLPs. Tx TLPs are loaded into the core through a 32-bit data bus, txtlpu_data. The following handshake signals are provided to ensure a smooth and controlled interface between the core and the user Interface logic: txtplu_req – User interface logic asserts this input signal to request a transmission of TLP. 10 Lattice Semiconductor PCI Express User’s Guide txtlpu_rdy – If the core is ready to service the request it asserts this output signal so that the user interface logic can start the transaction. txtlpu_st – User ia nterface logic asserts this input signal to indicate the start of TLP and simultaneously loads the first DWORD of the TLP into the txtlpu_data bus. This signal should be active for only one clock period. All remaining parts of the TLP are loaded into the core in subsequent clocks, 32 bits per clock. Each DWORD of data is strobed in by the core at every positive edge of the div2_pclk clock. txtlpu_end – User interface logic asserts this signal along with the last DWORD of the TLP in the txtlpu_data bus. This is to indicate the end of Tx transaction. This signal should be active for only one clock period. txtlpu_nlfy – If the current Tx TLP is to be a nullified TLP the user interface logic asserts this to indicate the end of the nullified TLP. This signal should be active for only one clock period. The user interface logic can hold the txtlpu_req asserted to continue to transmit TLPs as long as txtlpu_rdy is asserted the txtlpu_st, txtlpu_end and txtlpu_nlfy signals are required to be asserted at the appropriate time for each TLP as explained above. The core expects that the request from the user logic is always to transmit a full TLP. So the core will respond with txtlpu_rdy only if it has enough memory in the retry buffer to cater a TLP even with maximum payload. The data transfer from the user logic and the core should be continuous without any break between the start of a TLP (as indicated by txtlpu_st) and the end of a TLP (as indicated by txtlpu_end) hence txtlpu_req should be held asserted till the end of a TLP. If the txtplu_req is deasserted by the user logic before the end of a TLP the core behavior will be unknown and the user logic should start a TLP afresh. Based on the packet type selected by the user logic in the input signal pkt_type the core loads the corresponding Credit Available information in the output signal crdt_avail. In the above figure p_c, NP_c and cpl_c are the corresponding Credit Available values for the packet types p, NP and cpl. For more information about Credit Available Calculation please refer to the appropriate section under Functional Description. Figure 5 shows the signal status for Transmit User Interface. Register Description PCI Express configuration space is not implemented in this core. But the core checks all TLPs related to the configuration access and appropriate action, as specified, is carried out in case of errors. It is left to the user logic to implement the necessary PCI Express registers as part of the design. All status and error signals are provided at the user interface to connect them to proper registers in the user logic. User Configurable Parameters The PCI Express core has all the three layers of the Endpoint device that is implemented in one configuration. Therefore there are no other configurations of this core. 11 Lattice Semiconductor PCI Express User’s Guide Timing Diagrams Figure 5. Transmit Path User Interface div2_pclk txtlpu_data txtlpu_req txtlpu_rdy txtlpu_st txtlpu_end / txtlpu_nlfy pkt_type p NP p_c crdt_avail cpl NP_c cpl_c Figure 6. Receive Path User Interface div2_pclk rxtlpu_data rxtlpu_st rxtlpu_sd rxtlpu_end un_sup_req / pois_tlp malf_tlp Figure 7. PM DLLP Transmit User Interface div2_pclk rxpm_dllp_type/ txpm_dllp_type rx_dllp_val / tx_pm 12 Lattice Semiconductor PCI Express User’s Guide User Interface Signals AC Characteristics This section gives the I/O timings on all the signals on the user interface assuming these signals are coming out of the FPGA I/O pins. Table 1. User Interface Signals for AC Characteristics Type Typical (ns) All Input Signals Signal Name tSU 7.0 All Output Signals tCO 7.0 Signal Descriptions Table 2. PCI Express Core Signal Descriptions Port Name Active State rst_n div2_pclk I/O Signal Description Low I Asynchronous System Reset — I 62.5MHz System Clock PCI Express Line Interface (Inputs) REFCLKN_A — I 125MHz Differential Reference Clock for SERDES Block A REFCLKP_A — I 125MHz Differential Reference Clock for SERDES Block A REFCLKN_B — I 125MHz Differential Reference Clock for SERDES Block B REFCLKP_B — I 125MHz Differential Reference Clock for SERDES Block B USR_CLK — I 50 MHz clock for system bus HDINN_AC — I Rx Data input – SERDES Quad A, Channel C HDINP_AC — I Rx Data input – SERDES Quad A, Channel C HDINN_BC — I Rx Data input – SERDES Quad B, Channel C HDINP_BC — I Rx Data input – SERDES Quad B, Channel C PASB_PDN — I Active Low Power Down Input PASB_RESETN — I Active Low Reset for the Embedded Core PASB_TESTCLK — I Clock Input for BIST and Loopback Test PASB_TRISTN — I Active low 3-state for Embedded Core Output Buffers PBIST_TEST_ENN — I Selection of PASB_TESTCLK Input for BIST Test PLOOP_TEST_ENN — I Selection of PASB_TESTCLK Input for Loopback Test PMP_TESTCLK — I Clock Input for Microprocessor in Test Mode PMP_TESTCLK_ENN — I Selection of PMP_TESTCLK in Test Mode PSYS_DOBISTN — I Input to Start BIST Test PCI Express Line Interface (Outputs) HDOUTN_AC — O Tx Data input - SERDES Quad A, Channel C HDOUTP_AC — O Tx Data input - SERDES Quad A, Channel C HDOUTN_BC — O Tx Data input - SERDES Quad B, Channel C HDOUTP_BC — O Tx Data input - SERDES Quad B, Channel C REXT_A — O Reference Resistor – SERDES Quad A REXT_B — O Reference Resistor – SERDES Quad B PSYS_RSSIG_ALL — O Output result of BIST Test — O Poll rx_detect. Equivalent to TxDetectRx/Loopback in PIPE Spec I Indicates PCI_Express Link presence is Detected. Equivalent to RxStatus=011b in PIPE Spec External Circuit Interface start_rx_detect rx_detect High 13 Lattice Semiconductor Port Name PCI Express User’s Guide Active State I/O Signal Description — O Received TLP Data to Transaction Layer rxtlpu_st High O Start of Received TLP on the “rxtlpu_data” rxtlpu_sd High O Start of Data in the Received TLP rxtlpu_end RX_USR Interface rxtlpu_data[31:0] High O End of TLP on the “rxtlpu_data” rxpm_dllp_type — O Type of Received PM DLLP rxpm_dllp_val High O Valid Signal to Sample “rxpm_dllp_type” pois_tlp High O Poisoned TLP received indication un_sup_req High O Unsupported Request Received Indication malf_tlp High O Malformed TLP Received Indication bad_tlp High O Bad TLP Received Indication bad_dllp High O Bad DLLP Received Indication dll_perr High O Data Link Layer Protocol Error Indication rnum_rlor High O REPLY_NUM Rollover Indication rply_tout High O Replay Timer Timeout Indication TX_USR Interface txtlpu_req High I User Interface Request to Send TLPs — I TLP Data to be Transmitted on PCI Express Link txtlpu_st High I Start of TLP Signal that Indicates Start of New TLP on the txtlpu _data Bus txtlpu_end High I End of TLP Signal that Indicates End of TLP on the txtlpu _data Bus txtlpu_data[31:0] txtlpu_nlfy High I User Interface Request to Generate a Nullified TLP This Signal is to be Asserted Along With End of TLP no_pcie_training High I No LTSSM Training to be performed pkt_type — I Packet type for credit info txpm_dllp_type — I PM packet type to transmit tx_pm High I Send PM DLLP, with PM data in “tx_data” l_retrain_link High I Initiate Link Retraining l_ext_sync High I Extended syn loc_lnk_cntl[3:0] High I Link Control bits from User Interface Bit 0 – Set Hot_Reset bit in TS1/TS2 Will switch the Core to Reset state if current state is Recovery Bit 1 – Set Disable_Link bit in TS1/TS2 Will switch the Core to Disable state if current state is Recovery Bit 2 – Set Loopback bit in TS1/TS2 Will switch the Core to Tx_Loopback state if current state is Recovery Bit 3 – Set Disable_scramble bit in TS1/TS2 l_go_config High I Direct the Core to Switch to Configuration State txtlp_rdy High O The Data Link Layer is Ready to Accept TLPs from Transaction Layer crdt_avail — O Credit Available for the Packet Type Note2: 1. For all PCI Express Line Interface signals (both input and output) refer to the ORT42G5 and ORT82G5 data sheet for their usage. 2. External Circuit Interface: rx_detect signal to be generated by an external circuit whenever the start_rx_detect signal is asserted. Refer to the Receiver Detection section in “PHY Interface for the PCI Express Architecture”. 3. For usage of loc_lnk_cntl and l_go_config signals refer to the Link Training and Status State Machine section of the PCI Express specifications. 14 Lattice Semiconductor PCI Express User’s Guide PCI Express Core Design Flow Lattice has created a detailed software IP tutorial available on the Lattice web site at www.latticesemi.com. Both a simple IP module evaluation and tutorial and a more detailed ispLeverCORE™ tutorial are available for download. Type “tutorial” in the Lattice web site search engine. References • PCI Express Specification 1.0A • ispLEVER® Software Online Help Manual Technical Support Assistance Hotline: 1-800-LATTICE (North America) +1-503-268-8001 (Outside North America) e-mail: techsupport@latticesemi.com Internet: www.latticesemi.com 15 Lattice Semiconductor PCI Express User’s Guide Appendix for ORCA® Series 4 FPSCs – ORT42G5 Table 3. Performance and Resource Utilization1 Name of Parameter File ORCA 4 PFUs LUTs Registers EBR PIO fMAX (MHz) pci_exp_t42g5_1_001.lpc 937 3,406 3,078 10 116 66.7 1. Performance and utilization characteristics are generated using an ORT42G5-2BM484. When using this IP core in a different density, package, speed, or grade within the ORCA 4 family, performance and utilization may vary. Supplied Netlist Configurations The Ordering Part Number (OPN) for all configurations of this core is PCI-EXP-T42G5-N1. Table 3 lists the netlists available as Evaluation Packages for the ORCA Series 4 devices, which can be downloaded from the Lattice web site at www.latticesemi.com. You can use the IPexpress software tool to help generate new configurations of this IP core. IPexpress is the Lattice IP configuration utility, and is included as a standard feature of the ispLEVER design tools. Details regarding the usage of IPexpress can be found in the IPexpress and ispLEVER help system. For more information on the ispLEVER design tools, visit the Lattice web site at www.latticesemi.com/software. 16 Mouser Electronics Authorized Distributor Click to View Pricing, Inventory, Delivery & Lifecycle Information: Lattice: PCI-EXP-T42G5-N1