User manual

ManualsBrandsXilinx ManualsSoftwareWelder UG181

LogiCORE™ IP

SPI-4.2 Lite v4.3

User Guide

UG181 June 27, 2008

Summary of content (136 pages)

PAGE 1
LogiCORE™ IP SPI-4.2 Lite v4.
PAGE 2
R Xilinx is disclosing this Document and Intellectual Property (hereinafter “the Design”) to you for use in the development of designs to operate on, or interface with Xilinx FPGAs. Except as stated herein, none of the Design may be copied, reproduced, distributed, republished, downloaded, displayed, posted, or transmitted in any form or by any means including, but not limited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of Xilinx.
PAGE 3
Table of Contents Preface: About This Guide Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Typographical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Online Document . . . . . . . . . . . .
PAGE 4
Bursting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 FIFO Threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 Calendar COE File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PAGE 5
Constraints Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 New Target Region or Device Package. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Modifying the UCF File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Chapter 6: Special Design Considerations Sink Clocking Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PAGE 6
www.xilinx.com SPI-4.2 Lite v4.
PAGE 7
Schedule of Figures Chapter 2: Core Architecture Figure 2-1: SPI-4.2 Lite Core in a Typical Link Layer Application . . . . . . . . . . . . . . . . . . . 18 Figure 2-2: Sink Core Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Figure 2-3: Source Core Block Diagram and I/O Interface Signals . . . . . . . . . . . . . . . . . . 31 Chapter 3: Generating the Core Figure 3-1: SPI-4.2 Lite Sink and Source Main Customization Screen . . . . . . . . . . . . . .
PAGE 8
Figure 4-30: Addressable Status FIFO Interface: 4-Channel Configuration . . . . . . . . . . . 89 Figure 4-31: Addressable Status FIFO Interface: 256-channel configuration . . . . . . . . . . 90 Figure 4-32: Addressable Status FIFO Interface - SPI-4.2 Interface to User Interface . . 91 Figure 4-33: Transparent Status FIFO Interface Block Diagram . . . . . . . . . . . . . . . . . . . . . 92 Figure 4-34: Transparent Source Status FIFO Interface: 256-channel Configuration . . .
PAGE 9
Schedule of Tables Chapter 2: Core Architecture Table 2-1: Sink SPI-4.2 Interface Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Table 2-2: Sink Control and Status Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Table 2-3: Sink FIFO Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Table 2-4: Sink Calendar Control Signals . . . . . . . . . . . . . . . . . . .
PAGE 10
R Table 6-3: SysClk Clocking Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Table 6-4: TSClk Clocking Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 Appendix A: SPI-4.2 Lite Control Word Table A-1: SPI-4.2 Lite Control Word Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 www.xilinx.com SPI-4.2 Lite v4.
PAGE 11
R Preface About This Guide This user guide describes the function and operation of the Xilinx LogiCORE™ IP SPI-4.2 (PL4) Lite core, and provides information about designing, customizing, and implementing the core. Contents This guide contains the following chapters: • Preface, “About this Guide” describes the organization and purpose of the user guide and the conventions used in this document. • Chapter 1, “Introduction” introduces the SPI-4.
PAGE 12
R Preface: About This Guide Conventions This document uses the following conventions. An example illustrates each convention.
PAGE 13
R Conventions Online Document The following conventions are used in this document: Convention Meaning or Use Blue text Cross-reference link to a location in the current document Blue, underlined text Hyperlink to a website (URL) SPI-4.2 Lite v4.3 User Guide UG181 June 27, 2008 www.xilinx.com Example See the section “Additional Resources” for details. Refer to “Title Formats” in Chapter 1 for details. Go to www.xilinx.com for the latest speed files.
PAGE 14
R 14 Preface: About This Guide www.xilinx.com SPI-4.2 Lite v4.
PAGE 15
R Chapter 1 Introduction The SPI-4.2 (PL4) Lite core implements and is functionally compliant to the OIF-SPI-4-02.1 System Packet Interface Phase 2 specification and supports both VHDL and Verilog design environments. This chapter introduces the SPI-4.2 Lite core and provides related information, including recommended design experience, additional resources, technical support, and how to submit feedback to Xilinx. About the Core The SPI-4.
PAGE 16
R Chapter 1: Introduction Technical Support To obtain technical support specific to the SPI-4.2 Lite core, visit www.xilinx.com/support. Questions are routed to a team of engineers with expertise using the SPI-4.2 Lite core. Xilinx will provide technical support for use of this product as described in the SPI-4.2 Lite User Guide and the SPI-4.2 Lite Getting Started Guide. Xilinx cannot guarantee timing, functionality, or support of this product for designs that do not follow these guidelines.
PAGE 17
R Chapter 2 Core Architecture This chapter describes the SPI-4.2 Lite core architecture and interface signals. System Overview The SPI-4.2 Lite core is comprised of two separate cores that enable the transmission (Source core) and reception (Sink core) of data. • Sink Core. Receives data from the SPI-4.2 interface. It takes the 16-bit interface and maps it to a 32-bit or 64-bit interface enabling the internal logic to run at a quarter of the line rate. • Source Core. Transmits data on the SPI-4.
PAGE 18
R Chapter 2: Core Architecture data access and facilitates integration within a system. Dedicated signals are used to configure the Sink and Source cores in circuit and monitor a suite of status registers. Virtex-4 or Spartan-3 Device SPI-4.2 Interface User Interface SPI-4.2 Lite Sink Core Rx Data Path Rx Status Path SPI-4.2 Sink Interface User Sink Interface SPI-4.2 Lite PHY Layer Device User’s Logic (Xilinx FPGA or ASSP) SPI-4.
PAGE 19
R Sink Core Interfaces standard FIFO interface, and the FIFO read and write operations are performed in independent clock domains. The Source core implements the following features: • Supports 32-bit or 64-bit user data width. • Optionally transmits only complete data bursts. • Provides both master and slave clocking to facilitate multiple core implementations. • Enables addressable or transparent access to SPI-4.2 flow control data.
PAGE 20
R Chapter 2: Core Architecture The functional modules and signals which comprise the different interfaces are shown in Figure 2-2 and defined in tables in the following sections. SnkEn Control and Status nterface SnkOof SPI-4.
PAGE 21
R Sink Core Interfaces Sink SPI-4.2 Interface The SPI-4.2 interface uses LVDS I/O buffers to receive 16-bit data words. The 16-bit data words received on the SPI-4.2 interface are combined into 32-bit or 64-bit data words by the SPI-4.2 Lite core, which allows the user interface to run at a half (32-bit interface) or quarter (64-bit interface) of the data rate.
PAGE 22
R Chapter 2: Core Architecture Sink User Interface The Sink User Interface includes all signals other than those on the SPI-4.2 Interface. The high-performance logic on the Sink back-end enables the user interface to run at higher frequencies than the SPI-4.2 Interface. This is sometimes required if a large percentage of the traffic consists of small packets. The User Interface is subdivided into five smaller interfaces.
PAGE 23
R Sink Core Interfaces Table 2-2: Sink Control and Status Signals (Continued) Direction Clock Domain SnkOof Output SnkFFClk Sink Out-of-Frame: Active high signal that indicates that the SPI-4.2 Lite Sink block is not in frame. This signal is asserted when SnkEn is deasserted or the Sink block loses synchronization with the data received on the SPI-4.2 Interface. This signal is deasserted once the Sink block reacquires synchronization with the received SPI-4.2 data.
PAGE 24
R Table 2-3: Chapter 2: Core Architecture Sink FIFO Signals (Continued) Direction Description SnkFFSOP Output Sink FIFO Start of Packet: When asserted (active high), this signal indicates the start of a packet is being read out of the Sink FIFO. SnkFFEOP Output Sink FIFO End of Packet: When asserted (active high), this signal indicates that the end of a packet is being read out of the Sink FIFO.
PAGE 25
R Sink Core Interfaces Sink Status and Flow Control Interface (Calendar Control and Status FIFO) The Sink Status and Flow Control interface enables you to send flow control data on the SPI-4.2 Interface. The status information is sent based on the channel order and channel frequency defined in the programmable calendar. Table 2-4 and Table 2-5 define the calendar interface and status FIFO interface signals.
PAGE 26
R Table 2-5: Chapter 2: Core Architecture Sink Status FIFO Signals (Continued) Name SnkStatAddr[3:0] Direction Clock Domain Input SnkStatClk Description Sink Status Address bus: The Sink Status Address determines the group of 16-channel status that SnkStat will be updating. Bank 0: SnkStatAddr=0, channels 15 to 0 Bank 1: SnkStatAddr=1, channels 31 to 16 Bank 2: SnkStatAddr=2, channels 47 to 32 ...
PAGE 27
R Sink Core Interfaces Table 2-6: Sink Static Configuration Signals Name NumDip4Errors[3:0] NumTrainSequences[3:0] SnkCalendar_M[7:0] Direction Range Static Input 1-15 Static Input 1-15 Input 0-255 Value of 0 is set to 1 Value of 0 is set to 1 (effective range 1-256) Description Number of DIP-4 Errors: The Sink Interface will go out-of-frame (assert SnkOof) and stop accepting data from the SPI-4.2 bus after receiving NumDip4Errors consecutive DIP-4 errors.
PAGE 28
R Table 2-6: Chapter 2: Core Architecture Sink Static Configuration Signals (Continued) Name SnkAFThresNegate[8:0] RSClkDiv Direction Range Static Input SnkAFThresAssert to 508 Values less than SnkAFThresAssert are set to SnkAFThresAsset. Values greater than 508 are set to 508. Sink Almost Full Threshold Negate: The SnkAFThresNegate parameter defines the minimum number of empty FIFO locations that exist when SnkAlmostFull_n is deasserted.
PAGE 29
R Sink Core Interfaces Sink Clocking Interface The Sink core supports two clocking implementations: embedded clocking and user clocking. The embedded clocking configuration provides a complete solution with the clock circuitry embedded within the Sink core. The user clocking configuration allows the clocking scheme to be implemented external to the Sink core. A list of the Sink clocks for embedded clocking and their description is provided in Table 2-7.
PAGE 30
R Chapter 2: Core Architecture Table 2-9: Sink Core Clocks: User Clocking Clock Pins RDClk0_USER Direction Input (User Interface) Description RDClk0_USER: This clock is used for clocking the internal logic of the core. Max. Frequency Virtex-5: 275 MHz Virtex-4: 190 MHz Virtex-II Pro: 160 MHz Virtex-II: 160 MHz Spartan-3: 115 MHz Spartan-3E: 90 MHz Spartan-3A/3AN/3A DSP: 105 MHz RDClk180_USE R Input (User Interface) RDClk180_USER: This clock is the inverted equivalent of RDClk0_USER.
PAGE 31
R Source Core Interfaces Figure 2-3 illustrates the functional modules and signals in each interface—all signals are defined in sections following this illustration. SysClk SrcEn SPI-4.
PAGE 32
R Chapter 2: Core Architecture In addition to transmitting 16-bit data words, the SPI-4.2 interface also receives flow control data at 1/4 rate of its data interface. The 2-bit status received can be presented to you in 2 interfaces: transparent and addressable. Table 2-10 defines the Source SPI-4.2 interface signals. Table 2-10: Source SPI-4.2 Interface Signals Direction Clock Domain Output n/a Output TDClk SPI-4.2 Transmit Data Bus (LVDS): The 16-bit data bus is used to transmit SPI-4.
PAGE 33
R Source Core Interfaces Source Control and Status Interface The Source Control and Status signals either control the operation of the entire Source core or provide status information that is not associated with a particular channel (port) or packet. Table 2-11 defines the source control and status signals.
PAGE 34
R Table 2-11: Chapter 2: Core Architecture Source Control and Status Signals (Continued) Name SrcPatternErr Direction Clock Domain Output SrcFFClk Description Source Data Pattern Error: When this signal is asserted (active high), it indicates that the data pattern written into the Source FIFO is illegal.
PAGE 35
R Source Core Interfaces Source FIFO Interface The Source FIFO Interface signals allow you to write data into the FIFO to be transmitted on the SPI-4.2 Interface. Table 2-12 defines the Source FIFO signals. Table 2-12: Source FIFO Signals Direction Clock Domain SrcFFClk Input n/a SrcFFWrEn_n Input SrcFFClk Source FIFO Write-Enable: When asserted (active low) at the rising edge of SrcFFClk, data and packet information is written into the FIFO.
PAGE 36
R Chapter 2: Core Architecture Source Status and Flow Control Interface (Calendar Control and Status FIFO) The Source Status and Flow Control Interface enables you to receive flow control data from the SPI-4.2 interface. The status information is received based on the channel order and frequency defined in the programmable calendar. The Source Calendar Control signals are defined in Table 2-13. The Source Status FIFO Signals are defined in Table 2-14.
PAGE 37
R Source Core Interfaces Table 2-14: Source Status FIFO Signals (Continued) Name Direction Clock Domain Input SrcStatClk SrcStatAddr[3:0] (Addressable I/F Only) Description Source Status Address: For the Addressable Interface, the Source Status Address determines which group of 16-channels gets its status driven onto SrcStat on the following clock cycle.
PAGE 38
R Chapter 2: Core Architecture Note that there are legal values for each of the signals. If the configuration signal is set to an illegal number, the core automatically sets it to the minimum value. Table 2-15 defines the Source Static Configuration signals.
PAGE 39
R Source Core Interfaces Table 2-15: Source Static Configuration Signals (Continued) Name Direction SrcCalendar_M[7:0] Input Range 0-255 (effective range 1-256) Description Source Calendar Period: The SrcCalendar_M parameter sets the number of repetitions of the calendar sequence before the DIP-2 parity and framing words are received. The Source core implements this parameter as a static register synchronous to SrcStatClk, and it can be updated in circuit by first deasserting SrcEn.
PAGE 40
R Chapter 2: Core Architecture the slave clocking signals. The minimum frequency for all clocks is dependent on the minimum frequency of the DCM. Table 2-16: Source Core Clocks: Master Configuration Clock Pins Direction Description SysClk_P Input (differential) SysClk: A The frequency of TDClk is the same as SysClk. Virtex-5: 275 MHz SysClk_N It is recommended that SysClk should be a low jitter (<50ps) reference clock, as any jitter present on the SysClk input will appear on the TDClk output.
PAGE 41
R Source Core Interfaces Table 2-17: Source Core Clock Status Signals: Master Configuration (Continued) Direction Clock Domain DCMLost_TDClk Output N/A Indicates TDClk input has stopped (status bit one of TDClk DCM) SrcClksRdy Output N/A Indicates all Source core clocks are ready for use. Signal Name Table 2-18: Description Source Core Clocks: Slave Configuration Clock Pins SysClk0_GBSLV Direction Description Input SysClk0: This clock is used to clock the internal source core logic.
PAGE 42
R 42 Chapter 2: Core Architecture www.xilinx.com SPI-4.2 Lite v4.
PAGE 43
R Chapter 3 Generating the Core The SPI-4.2 Lite core is a fully configurable implementation of the OIF-SPI4-02.1 Specification. Using the CORE Generator GUI, you can configure the core and customize the delivered files including the example wrapper and UCF files. Note: After the core is generated, only static configuration signals options can be modified by changing the input values. If other modifications are required, you must regenerate the core with new options.
PAGE 44
R Chapter 3: Generating the Core Main Screen The main SPI-4.2 Lite screen defines the component name, core options, and UCF File options. Figure 3-1: SPI-4.2 Lite Sink and Source Main Customization Screen Component Name The Component Name is the base name of the output files generated for the core. The name must begin with a letter and be composed of the following characters: a to z, 0 to 9, and “_”. Core Options Number of Channels The SPI-4.2 Lite core supports between 1 and 256 channels.
PAGE 45
R Sink Status Options Screen Calendar Options in this section affect the behavior of the Sink core with respect to its calendar and status interfaces. Iterations of Calendar Sequence Before DIP2 This is the value of static configuration signal SnkCalendar_M; it is the number of times the Sink core will repeat the calendar sequence before sending a DIP2 value and frame word on RStat. The valid range is 1 to 256.
PAGE 46
R Chapter 3: Generating the Core Rate This is the value of static configuration signal RSClkDiv; it selects the frequency of RSClk with respect to RDClk. Alignment This is the value of static configuration signal RSClkPhase; it determines whether RStat transitions on the rising or falling edge of RSClk. Status I/O This controls whether RStat and RSClk I/O in the generated wrapper file use LVDS or LVTTL I/O.
PAGE 47
R Source Status Options Screen to normal. The valid range is the Almost Full Assert value to 508 and is also measured from the full level. Clocking Clock Mode The Sink core netlist will contain a complete clocking solution if Embedded Clocking is selected. If User Clocking is selected, you must provide a clock generation method external to the Source core. For more information, see “Sink Clocking Options,” page 111.
PAGE 48
R Chapter 3: Generating the Core Status Interface Status FIFO Interface This option selects whether the Source core netlist is generated with an addressable or transparent user status interface. For more information, see the “Source Status and Flow Control Signals,” page 85. Status I/O This option controls whether the Source core status I/O in the generated wrapper file uses LVDS or LVTTL I/O. Synchronization These options select the default static configuration parameters for core synchronization.
PAGE 49
R Source Other Options Screen Burst Size in Credits This is the value of static configuration signal SrcBurstLen; it is the maximum burst length in credits. The valid range is from 1 to 63. Burst Mode This is the value of static configuration signal SrcBurstMode. It specifies how the Source core transmits data. Complete Bursts Only causes the core to send only data bursts that are of Burst Size (as defined above) or terminated by an EOP.
PAGE 50
R Chapter 3: Generating the Core Calendar COE File Format The initial contents of the calendar can be assigned by specifying the desired information in a separate text file called a COE file. To select and load a COE file, first create the desired coe file, select Load Coefficients on the parameterization window, and choose the desired file from the file dialog box. An example COE file for a 12-channel SPI-4.
PAGE 51
R Chapter 4 Designing with the Core This chapter contains general design guidelines, detailed descriptions about the behavior of each interface, example waveforms, and implementation considerations. To design an application using the SPI-4.2 Lite core, follow the guidelines provided in this chapter. General Design Guidelines This section describes the steps required to implement each feature of the SPI-4.2 Lite core into a fully-functioning design integrated with user application logic.
PAGE 52
R Chapter 4: Designing with the Core Keep it Registered The best method to simplify timing and increase system performance in an FPGA design is to keep everything registered. That is, all inputs and outputs from the user application should come from, or connect to, a flip-flop. While registering signals may not be possible for all paths, it simplifies timing analysis and helps you achieve timing closure. Recognize Timing Critical Signals Watch the timing and loading on the signals listed below.
PAGE 53
R Sink Core • Initializing Status Calendar After the core exits the reset mode, the sink and status calendars must be initialized or programmed. There are two ways to do this: ♦ Initialize calendar with a default value: Using the CORE Generator GUI load an initialization file with the calendar contents. See Chapter 3, “Generating the Core” for more information. ♦ Programming calendar after reset: Using the calendar control interface to program the calendar contents.
PAGE 54
R Chapter 4: Designing with the Core channel 2 and an SOP for channel 1, followed by three 16-bit words. The last control word (C4) is an EOP for channel 1. The data received on the SPI-4.2 Interface is processed and stored in the Sink FIFO. Figure 4-1 also shows the data being read out of the FIFO and uses forward slashes to indicate that there is latency in processing and storing the SPI-4.2 data.
PAGE 55
R Sink Core than 14 bytes, four idle cycles are required to meet the SOP spacing requirement. After the four idle cycles, the transfer begins with a start-of-packet control word (C3) for channel 2. Next, three clock cycles (of two bytes each) are used to transfer the data associated with channel 2. The transfer concludes with an end-of-packet control word (C4).
PAGE 56
R Chapter 4: Designing with the Core Table 4-1: Formatting SPI-4.2 Interface Data (RDat) 64-bit User Interface (Example) Data Received on the SPI-4.2 Interface (RDat [15:0]) SOP RCtl RDClk cycle 1 1 0 2 0 3 0 4 0 5 Data Read from the Sink FIFO (SnkFFData[63:0]) N/A SnkFFClk cycle n Control Bits Read from the Sink FIFO N/A b:[1001.0000.0010.pppp] SPI-4.2 Lite Word 0 (P0) F1E2 SPI-4.2 Lite Word 1 (P1) D3C4 SPI-4.2 Lite Word 2 (P2) B5A6 SPI-4.2 Lite Word 3 (P3) F9E8 SPI-4.
PAGE 57
R Sink Core Table 4-2: SPI-4.2 Control Word Mapping to 64-bit User Interface Control Word Associated SPI-4.
PAGE 58
R Chapter 4: Designing with the Core Table 4-3: SPI-4.2 Control Word Mapping to 32-bit User Interface (Continued) Control Word End of Packet (EOP, odd bytes valid) Associated SPI-4.
PAGE 59
R Sink Core ♦ SnkBusErrStat[5]: Control word with payload bit not set and non-zero address (excluding Training Control word). ♦ SnkBusErrStat[7:6]: Tied to zero. (reserved) If the core receives two (or more) back-to-back payload control words, the last one received is used and the others are discarded. If the core receives two (or more) EOPs back-to-back, the first one is used and the others are discarded. For more information see “Error Handling,” page 72.
PAGE 60
R Chapter 4: Designing with the Core deasserted on the next clock cycle. The Sink FIFO read logic should then evaluate the SnkFFEmpty_n signal to verify that there is no data in the FIFO in case an additional word was simultaneously written into the FIFO. An example of this is provided with the SPI-4.2 Lite core in the Design Example (see the pl4_lite_fifo_loopback_read.v/vhd file.) This example also illustrates the Sink FIFO Valid signal, which is asserted while there is valid data on the data bus.
PAGE 61
R Sink Core operations occurring on the sink user interface. Configure the SnkAFThresAssert value according to your specific system requirements. See “FifoAFMode and Sink Almost Full,” page 67 for a description of the behavior of Sink FIFO interface when the Sink Almost Full flag is asserted. Sink Overflow The assertion of Sink Overflow flag (SnkOverflow_n) indicates that there is a write operation attempted on the FIFO when there are no empty FIFO locations available.
PAGE 62
R Chapter 4: Designing with the Core Calendar RAM SnkCalClk 0 1 SnkCalWrEn_n 2 Sink Calendar Control SnkCalAddr[8:0] 3 SnkCalendar_Len 4 SnkCalData[7:0] 5 SnkCalDataOut[7:0] . . . SnkCalendar_M 509 510 511 Sink FIFO Status Interface Status Memory SnkStatClk SnkStatAddr[3:0] SnkStat[31:0] SnkStatAddr = 0 Bank 0: Ch 0-15 0 1 8 9 2 3 4 5 6 7 10 11 12 13 14 15 ... 15 SnkStatWrEn_n SnkStatMask[15:0] RSTAT[1:0] ...
PAGE 63
R Sink Core SnkCalAddr=1, and so forth, until the end of the Calendar is reached, as defined by SnkCalendar_Len. The waveform in Figure 4-7 illustrates the programming of the Sink Calendar. In this example, SnkCalendar_Len is set to five and SnkCalendar_M is set to zero; indicating that the calendar length is six, and should be repeated once. This means that the Sink Calendar will be expected to drive the FIFO Status Channel data (onto the SPI-4.
PAGE 64
R Chapter 4: Designing with the Core Status for 16 channels each clock cycle can be written. The SnkStatAddr bus is used to select which 16 channels are written, and the core supports configurations of 1–256 channels. The 16 channels of FIFO Status that are written are addressed as follows: • Bank 0: SnkStatAddr[3:0]=0 for channels 15 to 0 • Bank 1: SnkStatAddr[3:0]=1 for channels 31 to 16 • Bank 2: SnkStatAddr[3:0]=2 for channels 47 to 32 • Bank 3: SnkStatAddr[3:0]=3 for channels 63 to 48 • ...
PAGE 65
R Sink Core Sink Status FIFO Interface: Example 1 This example illustrates writing to the Status FIFO Interface for a 10-channel SPI-4.2 Lite Sink core as shown in Figure 4-9. Because there are fewer than 17 channels, the Sink Status Address bus (SnkStatAddr[3:0]) is permanently tied to zero. In this example, the mask functionality is used to indicate that only 10 channels have valid status. The mask can change from clock-cycle to clock-cycle, but in this illustration it is fixed (SnkStatMask= 0x03FF).
PAGE 66
R Chapter 4: Designing with the Core Table 4-5: Status Written to Status FIFO Interface Status Address Status Mask Starving Status 0-1 Bank 0 1111.1111.1111.1111 CH 0-15 none 2 Bank 0 0000.0000.0000.0001 none CH 0 3 Bank 1 1000.0000.0000.0000 none CH 31 4-5 Bank 2 1111.1111.1111.1111 CH 32-47 none 6-7 Bank 3 1111.1111.1111.1111 CH 48-63 none 8-9 Bank 0 1111.0000.0000.
PAGE 67
R Sink Core SnkCalendar_M 0 = 0000 0000 SnkCalendar_Len 3 = 0 0000 0011 SnkStatClk SnkStatWr_n SnkStatMask[15:0] 0000.0000.0000.1111 SnkStatAddr[3:0] SnkStat[31:0] 0000 0x00000002 0x000000A2 0x000000AA RSClk RStat Figure 4-11: 11 10 00 DIP 11 10 00 10 DIP 11 10 DIP 11 Sink Status Path - User Interface to SPI-4.2 Interface Insertion of DIP2 Errors The sink core enables you to force the insertion of DIP2 errors for use during system testing and debugging.
PAGE 68
R Chapter 4: Designing with the Core RDClk_P RDat_P D D D D D D D D D D D D D D D D D D D D D D D SnkFFClk SnkAlmostFull_n SnkOof SnkStatClk SnkStat 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RSClk RStat 00 00 00 00 00 00 11 11 11 11 11 11 11 11 11 11 11 11 11 00 00 00 00 00 00 00 Figure 4-12: FIFO Almost Full Mode “00” FIFO Almost Full Mode “01” When the FIFO Almost Full Mode (FifoAFMode) is set to “01,” and the Sink core becomes Almost Full, the Sink interface remains in-frame (SnkOof dea
PAGE 69
R Sink Core FIFO Almost Full Mode “10” or “11” When the FIFO Almost Full Mode (FifoAFMode) is set to “10” or “11,” and the Sink core becomes Almost Full, the Sink Status logic will continue to drive out user status information (that is, continue in normal operation). In this last case, take immediate action to prevent FIFO overflow and loss of data. This is illustrated in Figure 4-14.
PAGE 70
R Chapter 4: Designing with the Core setting has the added advantage of providing a benchmark of the system margin, based on the UI (unit interval or bit time). System Margin (ps) = UI(ps) * (working phase shift range/128) Xilinx does not recommend that a single DCM PHASE_SHIFT value will be effective across all hardware platforms. Xilinx also does not recommend that you attempt to determine the PHASE_SHIFT setting empirically.
PAGE 71
R Sink Core Figure 4-15 shows a state machine diagram illustrating the Sink core startup sequence and error condition processing.
PAGE 72
R Chapter 4: Designing with the Core Sync Data In the Sync Data state, normal core operation is enabled. In this state, the Sink core continuously checks DIP-4 parity, stores data received on RDat[15:0] into the Sink FIFO, and sends FIFO Channel status on RStat. The core is In Frame in this state. Sync Train The Sink core enters the Sync Train state when a training pattern is detected on RDat[15:0]. The Sink core stops storing data to the Sink FIFO while in this state.
PAGE 73
R Sink Core Figure 4-16 illustrates back-to-back short packets. In this example there are four channels that are each sending 17-byte packets with a maximum burst of 16 bytes.
PAGE 74
R Chapter 4: Designing with the Core • SnkBusErrStat[5]: Control word with payload bit not set and non-zero address (excluding Training Control word) • SnkBusErrStat[7:6]: Unused and tied to zero (reserved) If the core receives two (or more) back-to-back payload control words, the last one received is used and others are discarded. If the core receives two (or more) back-to-back EOP control words, the first one is used and the others are discarded.
PAGE 75
R Sink Core When a DIP-4 error occurs on a payload control word (start of burst for the next packet), the Sink core stores a SnkFFPayloadDIP4 flag. If the payload control word was also the end-of-burst control word for the previous packet, then SnkFFDIP4Err would also be asserted for the previous packet. Since the OIF SPI-4.
PAGE 76
R Chapter 4: Designing with the Core Reserved Control Words As defined by the OIF SPI-4.2 specification, a reserved control word contains an SOP, but the payload control bit (RDat[15]) is not set to a one. If this occurs and is followed by data, the Sink core asserts SnkFPayloadErr for the duration of the burst, indicating that the burst did not have a correct payload control word. This indicates that the SOP and address configuration will not be valid. This error will also be flagged on SnkBusErr.
PAGE 77
R Source Core Source Data Path: Example 1 An example of the data received on the user interface and subsequently transmitted on the SPI-4.2 Interface is shown in Figure 4-21. In this illustration, a 14-byte packet of data is written into channel 1, followed by an 8-byte packet into channel 2. On the SPI-4.2 bus, the transfer begins with a payload control word (C1) indicating the start of packet (SOP), and address of the data to follow. Next, seven SPI-4.
PAGE 78
R Chapter 4: Designing with the Core containing the end-of-packet information for channel 2. Finally, the start-of-packet and address information for channel 3 are sent in the payload control word (C3). If the payload control words did not contain SOP indications (such as payload resumes), the Source core would not be required to enforce minimum SOP spacing. The Source core will then pack the EOP and Payload Control word into a single cycle and will not insert idle cycles.
PAGE 79
R Source Core 64-bit words from the Source FIFO are transmitted on the SPI-4.2 data bus. The DIP-4 parity depends on this control word and any proceeding transfer; therefore, it is left as “pppp” (shown in the 13th TDClk clock cycle). Following this example are two tables showing the mapping between the packet status signals on the user interface and SPI-4.2 control words for a 32-bit user interface (Table 4-7) and for a 64-bit user interface (Table 4-8).
PAGE 80
R Table 4-7: Chapter 4: Designing with the Core SPI-4.2 Control Word Mapping to 32-bit Interface Control Word Start of Packet (SOP) Associated SPI-4.
PAGE 81
R Source Core Table 4-8: SPI-4.2 Control Word Mapping to 64-bit User Interface Associated SPI-4.
PAGE 82
R Chapter 4: Designing with the Core Transmitting Idle Cycles Idle cycles are sent on the SPI-4.2 Interface only when there is no data in the FIFO. The core will also insert idle cycles when the control signal IdleRequest (see Table 2-11) is asserted. When this signal is asserted, the transmission of data is halted on the next burst boundary and idle cycles are forced onto the SPI-4.2 Interface. The insertion of training patterns always takes precedence over the transmission of idle cycles.
PAGE 83
R Source Core The control signal TrainingRequest is used to request that training patterns be sent out of the Source SPI-4.2 interface. When this signal is asserted, data transmission is halted on the next burst boundary and training patterns are transmitted on the SPI-4.2 Interface. For more information on the behavior of TrainingRequest, see “Transmitting Training Patterns”. The control signal IdleRequest signals that idle control words are to be sent on the SPI4.2 bus.
PAGE 84
R Chapter 4: Designing with the Core SrcFFClk SrcFFWrEn_n SrcFFAddr CH1 CH1 CH2 SrcFFData SrcFFMod 000 000 SrcFFSOP SrcFFEOP SrcFFErr SrcFFAlmostFull_n SrcFFOverflow_n Figure 4-24: Source FIFO Almost-full Condition Source FIFO Overflow Figure 4-25 shows the overflow response of the Source FIFO. The assertion of SrcFFAlmostFull_n indicates that the FIFO is almost full, and that data should no longer be written into the FIFO.
PAGE 85
R Source Core Writing to the Source FIFO A pause to a transfer on a credit (16 bytes) boundary is illustrated in Figure 4-26. In the example shown, two packets for unique channels are transferred into the FIFO. You write 32 bytes of data for channel 1, followed by 32 bytes of data for channel 2. Next, the final eight bytes of data and associated EOP for channel 1 is written to the FIFO. Finally, the remaining 16 bytes of data and associated EOP is written into the FIFO for channel 2.
PAGE 86
R Chapter 4: Designing with the Core User Interface Source Core FIFO Channel 0 MUX FIFO FIFO Channel 1 POLLING Status I/F Arbiter Figure 4-27: Typical User Design Example To enable designing back-end user logic, the Source core presents status information in two ways: • Addressable Status Interface. This interface allows polling the status of 16 channels at a time. This polling is synchronous to a user-defined clock (SrcStatClk).
PAGE 87
R Source Core Initializing the Calendar In-Circuit At start-up, you can program the Source calendar buffer by first deasserting Source Enable (SrcEn), then using the calendar write enable, address bus, and data bus. SrcCalAddr is used to indicate the location in the calendar buffer, and SrcCalData is used to indicate the channel number that should be written into that location. This programming defines the sequence that the status for each channel will be received.
PAGE 88
R Chapter 4: Designing with the Core • ... • Bank 14: SrcStatAddr[3:0]=14 for channels 239 to 224 • Bank 15: SrcStatAddr[3:0]=15 for channels 255 to 240 The status that is accessed is mapped to the 16-bit bus as follows (assuming SrcStatAddr [3:0] = 0): • SrcStat[1:0] => Channel 0, where SrcStat[1] is the MSB of the 2-bit status • SrcStat[3:2] => Channel 1 • SrcStat[5:4] => Channel 2 • ...
PAGE 89
R Source Core The Source Status Channel (SrcStatCh[7:0]) indicates which channel status was last updated on the SPI-4.2 Interface and is qualified by the Source Status Channel Valid signal (SrcStatChValid=1). SrcStatChValid enables SrcStatCh[7:0] to be encoded, and the valid signal is disabled when the core processes a received DIP-2 or framing word. Note that the SrcStatusCh[7:0] and SrcStatChValid use the SPI-4.2 Interface clock domain (TSClk_GP).
PAGE 90
R Chapter 4: Designing with the Core • Bank 1: SrcStatAddr[3:0]= 0001, for channels 31 to 16 • Bank 2: SrcStatAddr[3:0]= 0010, for channels 47 to 32 • Bank 3: SrcStatAddr[3:0]= 0011, for channels 63 to 48 • ... • Bank 15: SrcStatAddr[3:0]= 1111, for channels 255 to 240 The status read in the example shown in Figure 4-31 is summarized in Table 4-10.
PAGE 91
R Source Core internal status path clock (SrcStatClk) is synchronous to the external status path clock (TSClk). In other words, SrcStatClk is tied to TSClk_GP. This enables one to always be accessing the last updated status information, which is achieved by connecting SrcStatAddr directly to the most significant four bits of the SrcStatCh bus. In this example, the status for each channel alternates between starving and satisfied.
PAGE 92
R Chapter 4: Designing with the Core deasserted (equal to zero), the interface is receiving DIP-2 or framing and the data on SrcStat[1:0] is not valid. For the Transparent Interface, all outputs use the SPI-4.2 Interface clock domain (TSClk_GP). SrcStat[1:0] Q TStat_Delayed[1:0] D 2 TSClk_GP SrcStatChValid Q Write_En D TSClk_GP SrcStatCh[7:0] Q FifoWrAddress D 1 TSClk_GP 1 FifoWrAddress is the channel address retrieved from the Calendar.
PAGE 93
R Source Core Read 0 Read 1 Read 2 Read 3 Read 4 Read 5 Read 6 Read 7 Read 8 Read 9 Rd 10 10 79 16 00 01 10 TSClk_GP SrcEn SrcStatValid SrcStatCh[7:0] DEC 0 2 128 129 9 SrcStat[1:0] BIN 01 10 00 01 01 Figure 4-34: 1 10 01 11 Transparent Source Status FIFO Interface: 256-channel Configuration Source Static Configuration Signals The source static configuration signals are inputs to the core, statically driven to determine the behavior of the core.
PAGE 94
R Chapter 4: Designing with the Core Source Burst Mode Example SrcBurstLen equals 2 credits and 1.5 credits are written into the FIFO followed by 0.5 credits. Figure 4-35 illustrates the behavior of the Source core when SrcBurstMode=0. Figure 4-36 illustrates the behavior of the Source core when SrcBurstMode=1.
PAGE 95
R Source Core RESET The Source core remains in the RESET state until the Reset_n signal is deasserted. When in the RESET state, the Source core transmits idle patterns on TDat[15:0] and the Status FIFO is driven to be satisfied (“10”) for all channels. HUNT When Reset_n is deasserted, the state machine goes to the HUNT state and sends continuous training patterns on the SPI-4.2 Interface.
PAGE 96
R Chapter 4: Designing with the Core Error Handling This section describes how the Source core handles the receipt of non-compliant SPI-4.2 data and subsequent error handling in a number of common scenarios. This section also provides additional information on the Source core error status signals. Source Behavior Before Synchronization • To go into frame, the Source core must receive the number of complete status sequences defined by NumDip2Matches.
PAGE 97
R Source Core ♦ • Case 2: If the core receives a number of consecutive DIP-2 errors as defined by NumDip2Errors. ♦ • Action: The Source core will transmit idle cycles when Reset_n is asserted. When Reset_n is deasserted, the core will initiate the synchronization start-up sequence. Action: The Source core terminates the current packet at the next burst boundary, and begins transmitting training patterns on TDat[15:0]. Case 3: If the core receives four framing sequences "11" in a row on TStat.
PAGE 98
R 98 Chapter 4: Designing with the Core www.xilinx.com SPI-4.2 Lite v4.
PAGE 99
R Chapter 5 Constraining the Core This chapter describes the timing and placement constraints required by the SPI-4.2 Lite core to meet the performance requirements, including a set of optional constraints. These constraints are provided in an example user constraints file (UCF). In this chapter, and are used to indicate the instance name used to instantiate the Sink and Source cores in HDL respectively.
PAGE 100
R Chapter 5: Constraining the Core the following examples, the target performance is 340 Mbps. Please ensure that modifications to these constraints do not create paths that are unconstrained.
PAGE 101
R Sink Core Required Constraints • NET "/U0/pl4_lite_snk_core0/pl4_lite_snk_cal0/rs clk_rst" MAXDELAY = 5.8 ns; • NET "/U0/pl4_lite_snk_reset01/snk_stat_clk_gen/ reset_out_i" MAXDELAY = 5.8 ns; • NET "/U0/pl4_lite_snk_reset01/snk_ff_clk_rst_gen /reset_out_i” MAXDELAY = 5.8 ns • NET "/U0/pl4_lite_snk_reset01/snk_ff_clk_rst_gen /fifo_reset_out_i" MAXDELAY = 5.
PAGE 102
R Chapter 5: Constraining the Core • INST "/U0/clk0/rdclk_dcm0" IOBDELAY_VALUE = 0; Placement Constraints Although the SPI-4.2 Lite core does not require fixed pinouts, there are several placement constraints that are critical to meet performance requirements and process through the Xilinx tools. The constraints generated in the CORE Generator system is only an example and should be modified.
PAGE 103
R Sink Core Optional Constraints • INST "RDClk*" LOC = "Bank3"; IOB Register Packing The following constraints are mandatory for the Sink core. It ensures that the output register 3 of the RStat and RSClk signals are packed in the IOB. This guarantees that the timing between the output pad and the register is met.
PAGE 104
R Chapter 5: Constraining the Core • INST "/U0/pl4_lite_snk_io0/buffer_data/Dat*" DIFF_TERM = TRUE; • INST "/U0/pl4_lite_snk_io0/buffer_data/Ctl" DIFF_TERM = TRUE; Area Group Constraints The area group constraints can be used by the user to define a specific placement of the sink core. These constraints are not required for Sink cores that use global clocking distribution but are recommended for Sink cores that use regional clocking distribution.
PAGE 105
R Source Core Required Constraints • NET "TSClk_P" TNM_NET = "TSClk" (for source status I/O type of LVDS); The following constraints are for the Source core user interface clocks, and are only required if the user interface signals are not looped back to the source core user interface.
PAGE 106
R Chapter 5: Constraining the Core through the Xilinx tools. The constraints generated in CORE Generator system are provided as an example only and should be modified. You can modify these constraints to: • Move the core placement to a different area • Target a different device (other than the device package configuration) See “Constraints Migration” for information on how to migrate the core to a different area or device-package. I/O Placement With SPI-4.
PAGE 107
R Source Core Optional Constraints • * INST "TSClk*" LOC = "Bank 9"; If global clocking is used, TSClk must be placed on a pin that is connected to a global clock buffer. Using the example UCF file: • * INST "TSClk*" LOC = "Bank4"; IOB Register Packing The following constraints are mandatory for the Source core. It ensures that the input registers of the TStat signal are packed in the IOB. This guarantees that the timing between the input pad and the register is met.
PAGE 108
R Chapter 5: Constraining the Core Timing Ignore Constraints If Source core static configuration signals are driven statically from a register, apply the timing ignore attributes (TIG) to the static configuration signals to create proper timing ignore paths. If these are driven statically from a wrapper file, then the TIG is not needed. In the example UCF, these constraints are commented out. Uncomment these constraints in your design.
PAGE 109
R Constraints Migration If the target region or device does not contain enough resources, this will result in tool errors; not due to portability issues but resource issues. Modifying the UCF File Once the target region is selected, the UCF file must be modified. While modifying the constraints, ensure that changes are within the specifications described by the Sink and Source core required constraints. Note: The use of optional constraints is up to user discretion.
PAGE 110
R Chapter 5: Constraining the Core • INST "TCtl*" LOC = "Bank7"; # 1 LVDS I/O pair • INST "TDat*" LOC = "Bank7"; # 16 LVDS I/O pair Specify pin placement for "TSClk" I/O. See “Placement Constraints,” page 105. For example: INST "TSClk" LOC = "Bank3"; Specify an area group constraint if regional clocking is used. In the example UCF file, area group "AG_pl4_lite_ src" is defined to be one clock region on the same side of the device. AREA_GROUP "AG_pl4_lite_src" RANGE = CLOCKREGION_X0Y0; 110 www.
PAGE 111
R Chapter 6 Special Design Considerations This chapter describes several design considerations to consider when designing with the Xilinx SPI-4.2 Lite core: • Clocking implementations • Multiple core implementations Sink Clocking Options The Sink core supports two clocking implementations: embedded clocking and user clocking. The embedded clocking configuration provides a complete solution with the clock circuitry embedded within the Sink core.
PAGE 112
R Chapter 6: Special Design Considerations BUFG IBUFGDS RDClk0_USER RDClk 100 MHz DCM CLK0 100 MHz IOB CLK180 RDClk180_USER CLK2X DCMReset_RDClk Denotes I/O on User Interface Locked_RDClk 100 MHz Path IOB DDR Flops 16 Q Sink Internal Data & Control Bus D 32 Q RDat[15:0] & RCtl IOB RDClk0_GP D 100 MHz 16 RDClk0_GP Q 100 MHz D RDClk180_GP 100 MHz 200 MHz Path Internal Bus RStat[1:0] & RSClk D RDClk0_GP 100 MHz Q RStat[1:0] & RSClk 25 MHz IOB EN Enable at ¼ (or 1/8) PL4 Rx da
PAGE 113
R Sink Clocking Options defined in Table 2-9, page 30. For all architectures other than Virtex-4 or Virtex-5 devices, user clocking can only be implemented using global clocking resources. SPI-4.
PAGE 114
R Chapter 6: Special Design Considerations .
PAGE 115
R Source Clocking Options BUFR BUFIO IBUFDS IDELAY RDClk0_USER O 100 MHz RDClk 100 MHz I IOB RDClk180_USER Denotes I/O on User Interface 100 MHz Path IOB DDR Flops 16 Q D 32 Sink Internal Data & Control Bus Q RDat[15:0] & RCtl IOB RDClk0_GP D 100 MHz 16 RDClk0_GP 100 MHz Q D RDClk180_GP 100 MHz 200 MHz Path Internal Bus RStat[1:0] & RSClk D RDClk0_GP 100 MHz Q RStat[1:0] & RSClk 25 MHz IOB EN Enable at ¼ (or 1/8) PL4 Rx data rate Figure 6-4: Sink User Clocking: Regional C
PAGE 116
R Chapter 6: Special Design Considerations cores. An example of using the Slave core to either share clock resources between Source cores or to implement a custom clocking solution is shown in Figure 6-5.
PAGE 117
R Source Clocking Options BUFG IBUFGDS DCM SysClk0_GP CLK0 SysClk CLKIN 100 MHz 100 MHz IOB SysClk180_GP DCMReset_TDClk Denotes I/O on User Interface Locked_TDClk 100 MHz Path IOB DDR Flops 16 32 Source Internal Data & Control Bus D D Q D Q TDat[15:0] & TCtl IOB SysClk0_GP Q 100 MHz 16 SysClk0_GP 100 MHz SysClk180_GP 100 MHz 200 MHz Path Figure 6-6: Source Clocking: Global Clocking for SysClk BUFR BUFIO TSClk_GP TSClk 25 MHz Internal Bus TStat[1:0] 25 MHz Q D TStat[
PAGE 118
R Chapter 6: Special Design Considerations Regional Clocking For Virtex-4 and Virtex-5 device designs, this implementation uses the regional clock buffer resources BUFIO and BUFR to generate a full-rate clock (SysClk0_GP), an inverted full-rate clock (SysClk180_GP) and the quarter-rate clock (TSClk_GP). The regional clocking implementation for SysClk is illustrated in Figure 6-8 and the regional clocking implementation for TSClk is illustrated Figure 6-9.
PAGE 119
R Source Clocking Options The clock implementation for SysClk and TSClk is selected in the CORE Generator GUI. Depending on the chosen clocking option, different clock resources will be used. Table 6-3 and Table 6-4 provide the clocking resource count for each clocking option.
PAGE 120
R Chapter 6: Special Design Considerations Multiple Core Implementations Using the Xilinx SPI-4.2 Lite Core, a designer can implement multiple SPI-4.2 Lite cores in a single design. Follow the guidelines below to instantiate multiple cores. Instantiating Multiple Cores When instantiating multiple cores, the user must instantiate the modules as separate components in the top-level RTL design because there are different netlists for each core.
PAGE 121
R Multiple Core Implementations ); When instantiating the cores, there are several synthesis attributes that must be included. The cores need to be defined as black boxes for the synthesis tool, and automatic insertion of IBUF or OBUF signals for the SPI-4.2 Lite interface signals must be disabled.
PAGE 122
R Chapter 6: Special Design Considerations For each core constraints, the instance name in the UCF file must be modified to match the instance names in the top-level RTL design. For the timing and I/O pin location constraints, change the names to match the I/O ports declared in the top-level design as shown in the examples below.
PAGE 123
R Multiple Core Implementations ............ ); SPI-4.2 Lite v4.3 User Guide UG181 June 27, 2008 www.xilinx.
PAGE 124
R 124 Chapter 6: Special Design Considerations www.xilinx.com SPI-4.2 Lite v4.
PAGE 125
R Chapter 7 Simulating and Implementing the Core The SPI-4.2 Lite core is provided as a Xilinx technology-specific netlist and simulation model. The following sections describe how to simulate and implement the SPI-4.2 Lite core in a user design. Functional Simulation Functional simulation of the SPI-4.2 Lite core is performed with the provided simulation models (UniSim models). The simulation models provide cycle-accurate simulations for use in the verification of the user's application. The SPI-4.
PAGE 126
R Chapter 7: Simulating and Implementing the Core In the first method, when defining the initial values of the calendar block RAM using a COE file, the CORE Generator system converts the calendar sequence defined in the COE file into calendar block RAM constraints in the example UCF file. During implementation, the UCF calendar constraints are used to initialize the Sink and Source calendar block RAM content with the desired sequence.
PAGE 127
R Synthesis Before attempting timing simulation, follow the steps below to ensure that the simulator environment is properly configured. 1. Compile the Xilinx SimPrim libraries (if not already compiled). For details, see Xilinx Answer Record 15338. 2. Run the design through the Xilinx tool flow. An implement script is provided with the example design. The user may use this script as an example for creating their environment. For details about the implementation script, see the SPI-4.
PAGE 128
R Chapter 7: Simulating and Implementing the Core 2. Add the necessary user source files to the project file. 3. Select target device and speed grade. 4. Synthesize the user application. Xilinx Tool Flow This section provides an overview of the Xilinx tool flow and discusses how to implement the SPI-4.2 Lite core and the user design with the Xilinx implementation tools. Detailed information about Xilinx tools can be found in the Xilinx Development System Reference Guide.
PAGE 129
R Xilinx Tool Flow Static Timing Analysis To evaluate timing closure on a design and create a timing report file (TWR) derived from static timing analysis of the physical design file (NCD), the trce command must be executed. The analysis is typically based on constraints included in the optional physical constraints file (PCF). An example of the trce command is provided below: trce -e 10 routed.ncd mapped.pcf -o routed.twr The trce command outputs a routed.
PAGE 130
R 130 Chapter 7: Simulating and Implementing the Core www.xilinx.com SPI-4.2 Lite v4.
PAGE 131
R Appendix A SPI-4.2 Lite Control Word This appendix defines the SPI-4.2 control word format as shown in Table A-1. This table is reproduced from Table 6.2 in the OIF-SP14-02.1 specification. Table A-1: SPI-4.
PAGE 132
R Appendix A: SPI-4.2 Lite Control Word Table A-1: SPI-4.2 Lite Control Word Format (Continued) Bit Position Label 3:0 DIP-4 Description 4-bit Diagonal Interleaved Parity 4-bit odd parity computed over the current control word and the immediately preceding data words (if any) following the last control word. 132 www.xilinx.com SPI-4.2 Lite v4.
PAGE 133
R Appendix B SPI-4.2 Lite Calendar Programming This appendix lists examples that describe how to program calendars for the Source Status FIFO and Sink Status FIFO of the SPI-4.2 Lite core. Overview In a typical application, the calendars for the Source FIFO status and Sink FIFO status will be programmed identically. In this case, the user may choose to combine the Rx and Tx calendar input signals (clocks, write enable, address, and data) and drive them from the same Source.
PAGE 134
R Appendix B: SPI-4.2 Lite Calendar Programming Example 3 In a OC-192c application, 1 channel requires the complete SPI-4.2 Lite bandwidth. In this case, the calendar length can be set to 1 (Calendar_Len=0). The calendar does not have to be programmed on start-up, as it will initialize to all zeros on power-up. 134 www.xilinx.com SPI-4.2 Lite v4.
PAGE 135
R Appendix C SPI-4.2 Lite Core Verification Extensive software testing with an internally developed test suite is performed for each SPI-4.2 Lite release. Using our in-house verification environment, the SPI-4.2 Lite Core was tested in RTL, post-ngdbuild, and timing simulation. When using the in-house verification environment, the SPI-4.
PAGE 136
R Appendix C: SPI-4.2 Lite Core Verification • ♦ SPI-4.2 bus traffic that caused the SPI-4.2 Lite sink FIFO to be constantly almost full ♦ Backend data traffic that caused the SPI-4.2 Lite source FIFO to be constantly almost full ♦ SPI-4.2 bus traffic that caused the sink FIFO to overflow ♦ Backend data traffic that caused the source FIFO to overflow Verification of invalid data ♦ SPI-4.2 bus traffic that contained incorrect DIP-4 values ♦ SPI-4.