0 spi-4.2 core v6application-notes.digchip.com/077/77-43554.pdf · 2009. 2. 8. · spi-4.2 core...

Features• Fully compliant with OIF-SPI4-02.1 System Packet

Interface Level-4 (SPI-4) Phase 2 standard

• Supports POS, ATM, and Ethernet 10 Gbps applications

• Sink and Source cores selected and configured through Xilinx CORE Generator™ tool, providing easy customization

• Supports Dynamic Phase Alignment full bandwidth ranging up to 944 Mbps

• Delivers Sink and Source cores as independent solutions enabling flexible implementation

• Provides optional 64– or 128–bit user interface supporting easy integration of back-end user logic

• Supports 1 to 256 addressable channels with fully configurable SPI-4.2 calendar interface

• Facilitates mux/demux and bridging functions with a Xilinx standard FIFO User Interface

• Supports LVTTL and LVDS FIFO Status path operating at 1/4 (or 1/8) of the data rate

• Provides DIP–4 and DIP–2 parity generation and verification

• Provides Sink and Source FIFO signals for resetting the FIFO without restarting the interface

• Optimized fixed pinouts to insure compliance with SPI-4.2 timing specifications

• Common pinout for static and dynamic alignment implementations

• Available under terms of the SignOnce IP License

0

SPI-4.2 Core v6.3

DS209 February 15, 2006 0 0 Product Specification

LogiCORETM Facts

Core Specifics

Supported Device Family Virtex™-II, Virtex-II Pro

Core Performance

Virtex-II Pro: Dynamic Phase Alignment

622–700 Mbps (-5 speed grade)700–800 Mbps (-6 speed grade)800–944 Mbps (-7 speed grade)

Virtex-II Pro: Static Alignment

Up to 700 Mbp/s (-5,-6,-7 speed grades)

Virtex-II: Dynamic Phase Alignment

622–700 Mbps (-5 speed grade)700–800 Mbps (-6 speed grade)

Virtex-II: Static Alignment

Up to 640 Mbps (-4 speed grade)Up to 700 Mbps (-5,-6 speed grade)

Core Resources: Static Alignment

Rx Tx

Virtex-II Slices 2200 1900

Virtex-II Block RAM 8 6

Global Clock Buffers 2 (3)(2) 3 (4)(1)

Digital Clock Managers (DCM) 1 2

Core Resources: Dynamic Alignment

Rx Tx

Virtex-II Slices 3100 1900

Virtex-II Block RAM 9 6

Global Clock Buffers 3 3 (4)(1)

Digital Clock Managers (DCM) 1 2

Documentation

SPI-4.2 Getting Started GuideSPI-4.2 to Quad SPI-3 Reference Design

SPI-4.2 Clocking Design Example

Design File Formats EDIF netlist

Constraints File .ucf and.ncf

Design Tool Requirements

Xilinx Tools Xilinx ISETM v8.1i SP1 or higher

Support

Support provided by Xilinx, Inc. at www.xilinx.com/support

1. If the performance required is greater than 700 Mbps, or the core is targeted to Virtex-II Pro, then the Source core requires four global clock buffers.

2. If the performance required is greater than 700 Mbps or the core is targeted to Virtex-II Pro, the Sink core requires 3 global clock buffers.

DS209 February 15, 2006 www.xilinx.com 1Product Specification

© 2006 Xilinx, Inc. All rights reserved. All Xilinx trademarks, registered trademarks, patents, and further disclaimers are as listed at http://www.xilinx.com/legal.htm. All other trademarks and registered trademarks are the property of their respective owners. All specifications are subject to change without notice.

NOTICE OF DISCLAIMER: Xilinx is providing this design, code, or information "as is." By providing the design, code, or information as one possible implementation of this feature, application, or standard, Xilinx makes no representation that this implementation is free from any claims of infringement. You are responsible for obtaining any rights you may require for your implementation. Xilinx expressly disclaims any warranty whatsoever with respect to the adequacy of the implementation, including but not limited to any warranties or representations that this implementation is free from claims of infringement and any implied warranties of merchantability or fitness for a particular purpose.

http://www.xilinx.comhttp:www.xilinx.com/legal.htmhttp://www.xilinx.com/legal.htmhttp://www.xilinx.com/legal.htmhttp://www.xilinx.com/support/services/contact_info.htmhttp://www.xilinx.com/ipcenter/signonce.htm

SPI-4.2 Core v6.3

Table of ContentsFeatures ................................................................................................................................................................................1

Applications ..........................................................................................................................................................................5

Sink Core.............................................................................................................................................................................. 5

Sink Data Path: SPI-4.2 Interface .......................................................................................................................................7

Sink SPI-4.2 Data Path ................................................................................................................................................... 7

Sink Data Path: User Interface .........................................................................................................................................12

Sink Control and Status Signals ...................................................................................................................................12

Sink FIFO Interface Signals .......................................................................................................................................... 14

Sink Status Path and Flow Control.................................................................................................................................. 17

Sink Calendar Initialization............................................................................................................................................ 18

Sink Flow Control ..........................................................................................................................................................19

Sink FIFO Status Interface: Example 1 .........................................................................................................................20



Insertion of DIP-2 Errors ...............................................................................................................................................23

Sink Static Configuration Signals ....................................................................................................................................24

FifoAFMode and Sink Almost Full................................................................................................................................. 26

Sink Synchronization Start-up ......................................................................................................................................... 28

Sink Data Capture Implementation .................................................................................................................................. 29

Dynamic Alignment ....................................................................................................................................................... 29

Static Alignment ............................................................................................................................................................ 30

Sink Clocking Implementation ......................................................................................................................................... 31

Sink Core Operation.......................................................................................................................................................... 35

Short Packet Support (Less Than 16-byte Packet Support) ......................................................................................... 35

EOP Abort Handling...................................................................................................................................................... 36

Loss of RDClk ............................................................................................................................................................... 36

Sink FIFO Burst Error ................................................................................................................................................... 36

Sink SPI-4.2 Bus Error and Sink Bus Error Status[7:0] ................................................................................................ 36

Sequential Payload Control Words ............................................................................................................................... 37

Sequential End-of-Burst Control Words........................................................................................................................ 37

Sink DIP-4 Error Handling............................................................................................................................................. 37

Reserved Control Words ...............................................................................................................................................38

Source Core ....................................................................................................................................................................... 39

Source Data Path: SPI-4.2 Interface................................................................................................................................. 41

Source Data Path: User Interface..................................................................................................................................... 47

Source Control and Status Signals ............................................................................................................................... 47

Source FIFO Interface Signals...................................................................................................................................... 49

Source Status Path and Flow Control ............................................................................................................................. 52

Source Calendar Initialization ....................................................................................................................................... 53

Source Flow Control: Addressable Status Interface ..................................................................................................... 53

Source Flow Control: Transparent Status Interface ......................................................................................................57

2 www.xilinx.com DS209 February 15, 2006Product Specification

http://www.xilinx.com

SPI-4.2 Core v6.3

Source Static Configuration Signals ............................................................................................................................... 60

Source Burst Mode .......................................................................................................................................................60

Source Synchronization Start-up..................................................................................................................................... 63

Source Clocking Implementation .....................................................................................................................................64

Master Clocking ............................................................................................................................................................65

Slave Clocking .............................................................................................................................................................. 68

Source Core Operation ..................................................................................................................................................... 69

Source Behavior Before Synchronization ..................................................................................................................... 69

Source Behavior After Synchronization ........................................................................................................................ 70

EOP Abort Insertion ......................................................................................................................................................70

Source Out of Frame ....................................................................................................................................................70

Source DIP-2 Error Handling ........................................................................................................................................70

Source Pattern Error Handling ......................................................................................................................................71

Incorrect Burst Termination........................................................................................................................................... 71

SPI-4.2 CORE Generator Interface ................................................................................................................................... 71

Core Generator Parameters ......................................................................................................................................... 72

Calendar COE File Format ...........................................................................................................................................81

Constraining the Core....................................................................................................................................................... 81

SPI-4.2 Design Example Constraints............................................................................................................................ 81

Loopback Constraints ................................................................................................................................................... 81

Sink Interface Constraints ............................................................................................................................................. 82

Source Interface Constraints ........................................................................................................................................ 82

Simulating and Implementing the Core........................................................................................................................... 82

Functional Simulation.................................................................................................................................................... 82

Generating a Simulation Model .....................................................................................................................................82

Timing Simulation .........................................................................................................................................................83

Synthesis of Example Design ....................................................................................................................................... 83

Xilinx Tool Flow............................................................................................................................................................. 84

Core Verification ................................................................................................................................................................85

SPI-4.2 Hardware Verification....................................................................................................................................... 86

Additional Documentation.................................................................................................................................................88

Design Implementation ................................................................................................................................................. 88

SPI-4.2 Getting Started Guide ......................................................................................................................................88

SPI-4.2 Timing Budget Reference Guide ......................................................................................................................88

References .........................................................................................................................................................................88

Related Information ...........................................................................................................................................................88

Ordering Information .........................................................................................................................................................88

Appendix A: SPI-4.2 Control Word Format ..................................................................................................................... 89

Appendix B: SPI-4.2 Calendar Programming ..................................................................................................................90

Appendix C: Device and Package Support ..................................................................................................................... 90

Revision History ................................................................................................................................................................ 92



SPI-4.2 Core v6.3

ApplicationsThe SPI-4.2 (PL4) Interface core enables the interconnection of physical-layer devices to link-layer devices in 10 Gb/s POS,ATM, and Ethernet applications. The symmetric interface can be used to implement both the PHY and Link layer.

Figure 1 shows the core being used in a typical link-layer application.

Driven by the improved efficiencies and lower cost-per-Mbit of Packet-over-SONET/SDH, the core is ideally suited for linecards in gigabit routers, terabit, and optical cross-connect switches, and a wide range of multiservice DWDM andSONET/SDH-based transmission systems.

The SPI4-02.1 interface is widely used to connect network processors with OC-192 framers and mappers, as well as Gigabitand 10-Gigabit Ethernet data link MACs. The Xilinx SPI-4.2 Interface is a high-performance, low-pin-count data transfer pro-tocol that is ideally suited for these applications.

In addition to providing a fully compliant SPI-4.2 solution, Xilinx has collaborated with leading network device developerssuch as PMC-Sierra, Intel, and Mindspeed to ensure the Xilinx SPI-4.2 core interoperates with the latest industry PHYdevices.

Sink CoreThe core has four primary functional blocks: (1) Sink FIFO, (2) SPI-4.2 Data Path, (3) SPI-4.2 Status Path, and (4) Calendarand Status Registers. The core also has a set of static configuration signals, which are used to customize the core. The inputand output signals and the functional blocks of the Sink core are illustrated in Figure 2. The interfaces to each of thesemodules and the available static configuration signals are described in detail below.

Figure 1: SPI-4.2 Core in Typical Link Layer Application

Virtex-II Device

PL4 Source Core

PL4Interface

UserInterface

PL4 PHY

LayerDevice

(Virtex-II

orASSP)

User’sLogic

(Link Layer

Processor)

PL4 Sink Core

UserSink

Interface

PL4Sink

Interface

Rx Data Path

Rx Status Path

Tx Data Path

Tx Status Path

UserSource

Interface

PL4Source

Interface



SPI-4.2 Core v6.3

Figure 2: Sink Core Block Diagram and I/O Interface Signals

SPI-4.2 Sink Core

Sink

Interface

RDClk

RDat[15:0]

Sink

FIFO

Interface

Sink

Status

Interface

RSClk

RStat[1:0]

SnkFFClk

SnkFFRdEn_n

SnkFFAddr[7:0]

SnkFFData[63:0]

SnkFFMod[2:0]

SnkFFSOP

SnkFFEmpty_n

SnkFFErr

SnkFFEOP

SnkFFAlmostEmpty_n

SnkStatClk

SnkStatAddr[3:0]

SnkCalClk

SnkCalWrEn_n

SnkCalAddr[8:0]

SnkCalData[7:0]

Status

Registers

Calendar

SPI-4.2

Sink

Interface

Sink FIFO

Interface

Sink FIFO

Status

Interface

SnkTrainValid

SnkFFDIP4Err

SnkEn

Sink Control

and Status

Sink Calendar

Control

RCtl

SnkAlmostFull_n

SnkBusErr

Static Configuration Signals

SnkFFValid

SnkOverflow _n

SnkOof

SnkFFPayloadErr

Reset_n

SnkCalDataOut[7:0]

SnkStat[31:0]

SnkStatWrEn_n

SnkStatMask[15:0]

SnkFFPayloadDIP4

SnkFFBurstErr

SnkFifoReset_n

SnkDIP2ErrRequest

SnkBusErrStat[7:0]



SPI-4.2 Core v6.3

Sink Data Path: SPI-4.2 InterfaceThe signals on the Sink SPI-4.2 Interface are defined in Table 1.

Sink SPI-4.2 Data Path

The SPI-4.2 datapath interface uses LVDS I/O buffers paired with double data rate (DDR) registers. The SPI-4.2 Sink coreruns up to 400 MHz LVDS DDR I/O (800 Mbp/s) in Virtex-II and up to 472 MHz (944 Mbp/s) in Virtex-II Pro.

The 16-bit data words received on the SPI-4.2 Interface are combined into 64-bit or 128-bit data words by the SPI-4.2 core.This allows the user interface to run at a quarter (64-bit interface) or an eighth (128-bit interface) of the data rate (forexample, for a 700 Mbp/s SPI-4.2 data rate and a 128-bit user interface, the user can write data into the Source core at 87.2MHz).

The resulting data words are written into an asynchronous FIFO. The received 16-bit control words are stored out of bandin the FIFO, along with the corresponding data word. The received control words that are not idle, or training words, cancontain the information listed below:

• Start or continuation of the following packet

• Link address of the following packet

• End of the preceding packet

• Number of valid bytes in the last word of the preceding packet

• Error conditions in the preceding packet

The assignment of each bit in the control word, as defined by the OIF SPI-4.2 specification, is detailed in Appendix A:SPI-4.2 Control Word Format.

Sink Data Path: Example 1

An example of the data received on the SPI-4.2 Interface and subsequently read on the user interface is shown in Figure 3.In this illustration, the first received control word (C1) is a payload resume (with no SOP) for channel 1 followed by two 16-bitwords (channel 1, packet A and packet B). The second control word (C2) is an EOP for channel 1 and a payload resume forchannel 2 (with no SOP) followed by two 16-bit words. The third control word (C3) is an EOP for channel 2 and an SOP forchannel 1 followed by three 16-bit words. The last control word (C4) is an EOP for channel 1.

The data that is received on the SPI-4.2 Interface is processed and stored in the Sink FIFO. Figure 3 also shows the databeing read out of the FIFO and indicates, with forward slashes, that there is latency in processing and storing the SPI-4.2data. The first 64-bit word on the FIFO interface contains the two 16-bit words received for channel 1 with an EOP. Thesecond 64-bit word contains the two words received for channel 2 with an EOP. The last 64-bit word on the FIFO interfacecontains the three words written for channel 1. When the last word is read out of the FIFO, both the SnkFFSOP andSnkFFEOP for channel 1 are asserted.

Table 1: Sink SPI-4.2 Interface Signals

Signal Name DirectionClock

DomainDescription

RDClk_P

RDClk_N

Input n/a SPI-4.2 Receive Data Clock (LVDS): Source synchronous clock received with RDat and RCtl. The rising and falling edges of this clock (DDR) are used to clock RDat and RCtl.

RDat_P[15:0]

RDat_N[15:0]

Input RDClk SPI-4.2 Receive Data Bus (LVDS): The 16-bit SPI-4.2 data bus used to receive data and control information.

RCtl_P

RCtl_N

Input RDClk SPI-4.2 Receive Control (LVDS): SPI-4.2 Interface signal that indicates whether data or control information is present on the RDat bus. When RCtl is Low, data is present on RDat. When RCtl is High, control information is present on RDat.



SPI-4.2 Core v6.3

Sink Data Path: Example 2

The Sink core automatically and optimally handles any size packet including short packets (less than eight cycles apart),which have multiple SOPs or payload control words.

• Received SOPs less than eight cycles apart: the data will be passed through the core as received, and aSnkBusErr will be flagged indicating a protocol violation.

• Received Payload Control words less than eight cycles apart: Though the SPI-4.2 specification requires thatsuccessive SOPs must occur not less than eight cycles apart, there is no restriction on payload control words, whichare not SOPs. The Sink core can processes single payload control words followed by single data words(CTL-DATA-CTL-DATA-CTL, etc.). Since this is not a protocol violation, no SnkBusErr is asserted.

Figure 4 shows the transfer of short packets from the SPI-4.2 Interface through the Sink FIFO to the User Interface. Becauseeach of these packets contains less than 14 bytes, or seven clock cycles of data, idle control word insertion is necessary tomeet the start-of-packet spacing requirement of eight cycles. The transfer on the SPI-4.2 Interface begins with a payloadcontrol word (C1), indicating a start of packet (SOP) on channel 1. Next, two clock cycles, of two bytes each, are used totransfer the data associated with channel 1. The transfer concludes with an end-of-packet control word (C2). Because thetransfer is less 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, areused to transfer the data associated with channel 2. The transfer concludes with an end-of-packet control word (C4).

Figure 4 also shows the data being read out of the FIFO and indicates with forward slashes that there is latency inprocessing and storing the SPI-4.2 data. The first 64-bit word on the FIFO interface contains the four bytes of valid datareceived for channel 1. The control signals SnkFFSOP and SnkFFEOP are active, indicating that this is the start and end ofthe packet for channel 1. The second 64-bit word contains the six bytes of valid data for channel 2, and the control signalsSnkFFSOP and SnkFFEOP are both asserted.

Figure 3: Sink Data Path — SPI-4.2 Interface to User Interface

RDat_P

RDClk_P

RCtl_P

1A 1B 2A 2B 1CC1 C3 C4C2 1A 1B

CH1

2A 2B -- --1A 1B -- --

100100

SnkFFClk

SnkFFRdEn_n

SnkFFAddr

SnkFFData

SnkFFMod

SnkFFSOP

SnkFFEOP

CH2

1A 1B 1C --

110

CH1

SnkFFValid



SPI-4.2 Core v6.3

Table 2 shows an example of how the data and control received on the SPI-4.2 Interface is formatted and presented to theuser on the Sink FIFO Interface. (Note that control words are shown in binary and payload transfers are shown ashexadecimal.) After an SOP is received, the following 16-bit word transfer is left justified (for example, written to the mostsignificant 16 bits) into the data to be written into the FIFO (for a 64-bit interface: SnkFFDat[63:48], for a 128-bit interface:SnkFFDat[127:112]). The table shows the receipt of an SOP for channel 2, then a series of payload word transfers. TheDIP-4 parity depends on this control word and any proceeding transfer, and it is shown in the table as “pppp.”

Following this example are tables that show the mapping between SPI-4.2 Control Words and packet status signals for a64-bit user interface (Table 3) and a 128-bit user interface (Table 4.).

Figure 4: Sink Data Path — Short Packet Transfers with Minimum SOP Spacing Enforced

Table 2: Example of Formatting SPI-4.2 Interface Data (RDat) for a 64-bit User Interface

Data Received on the SPI-4.2 Interface

(RDat [15:0])RCtl

RDClkcycle

Data Read from the Sink FIFO(SnkFFData[63:0])

SnkFFClkcycle

Control Bits Read fromthe Sink FIFO

SOP

b:[1001.0000.0010.pppp]

1 1 N/A n N/A

SPI-4.2 Word 0 (P0)

F1E2

0 2

SPI-4.2 Word 1 (P1)

D3C4

0 3

SPI-4.2 Word 2 (P2)

B5A6

0 4

CH1

1A 1B -- --

100

SnkFFClk

SnkFFRdEn_n

SnkFFAddr

SnkFFData

SnkFFMod

SnkFFSOP

SnkFFEOP

RDat_P

RDClk_P

RCtl_P

1A 1B I I I 2A 2B 2CI

CH2

2A 2B 2C --

110

I IC1 C3 C4C2



SPI-4.2 Core v6.3

SPI-4.2 Word 3 (P3)

F9E8

0 5 SnkFFData[63:0] =

P0.P1.P2.P3 =

[F1E2.D3C4.B5A6.F9E8]

n + 1 SnkFFSOP = 1

SnkFFEOP = 0

SnkFFMod = 000

SnkFFErr = 0

SnkFFAddr = 00000010

SPI-4.2 Word 4 (P4)

1F2E

0 6

SPI-4.2 Word 5 (P5)

3D4C

0 7

SPI-4.2 Word 6 (P6)

5B6A

0 8

SPI-4.2 Word 7 (P7)

9F8E

0 9 SnkFFData[63:0] =

P4.P5.P6.P7 =

[1F2E.3D4C.5B6A.9F8E]

n + 2 SnkFFSOP= 0

SnkFFEOP = 0

SnkFFMod = 000

SnkFFErr = 0


SPI-4.2 Word 8 (P8)

ABCD

0 10

SPI-4.2 Word 9 (P9)

1200

0 11

EOP / MOD

b:[0110.aaaa.aaaa.pppp]

1 12

SnkFFData[63:0] =

P8.P9 =

[ABCD.1200.0000.0000]

n + 3 SnkFFSOP= 0

SnkFFEOP = 1

SnkFFMod = 011

SnkFFErr = 0


Table 3: SPI-4.2 Control Word Mapping to 64-bit User Interface

Control WordAssociated SPI-4.2 Control

Word bits on RDat(Qualified by RCtl=1)

Associated Sink FIFO Signals

Start of Packet (SOP) RDat[15] = 1, RDat[12] = 1 SnkFFSOP,SnkFFAddr[7:0]

SPI-4.2 Core v6.3

End of Packet (EOP, 2 bytes valid) RDat[14:13] = 10 SnkFFEOP, SnkFFMod[2:0]

When RDat[14:13] = 10:

Mod = 000 if data bits 63-0 have valid data





When RDat[14:13] = 11:





End of Packet

(EOP Abort, error condition)

RDat[14:13] = 01 SnkFFErr & SnkFFEOP

Table 4: SPI-4.2 Control Word Mapping to 128-bit User Interface




Start of Packet (SOP) RDat[15] = 1, RDat[12] = 1 SnkFFSOP,SnkFFAddr[7:0]

SPI-4.2 Core v6.3

Sink Data Path: User InterfaceThe Sink User Interface includes all the signals to the core other than those on the SPI-4.2 Interface (See "Sink Data Path:SPI-4.2 Interface" on page 6) or the Status Interface (See "Sink Status Path and Flow Control" on page 16). The userinterface can operate up to 200 MHz in Virtex-II or up to 236 MHz in Virtex-II Pro with a 64-bit data interface. The Sink coresalso supports a 128-bit user interface that can run up to 75% the speed of the 64-bit interface, and enables the user to runthe back-end logic at half the rate required by the 64-bit interface. The high performance supported on the Sink back-endenables the user interface to run at higher frequencies than the SPI-4.2 Interface. This is sometimes required if a largepercentage of the traffic consists of small packets.

The user interface has three major sections:

• Control and status signals. These signals apply to the operation of the entire Sink core.

• FIFO interface signals. These signals allow the user to access the data received on the SPI-4.2 Interface.

• Flow Control Interface. These signals are used to send flow control information on the SPI-4.2 Interface.

Each of these user interface sections are presented in detail below.

Sink Control and Status Signals

The Sink core control and status signals either control the operation of the entire Sink core or provide status information thatis not associated with a particular channel (port) or packet. The description of these signals is summarized in Table 5.


When RDat[14:13] = 10:

MOD = 0000 if data bits 127-0 have valid data

MOD =1110 if data bits 127-16 have valid data

MOD =1100 if data bits 127-32 have valid data







When RDat[14:13] = 11:









End of Packet

(EOP Abort, error condition)

RDat[14:13] = 01 SnkFFErr & SnkFFEOP

Table 4: SPI-4.2 Control Word Mapping to 128-bit User Interface (Continued)






SPI-4.2 Core v6.3

The Sink core is reset asynchronously by the signal Reset_n and there are three global status signals:

• Sink Out-of-Frame (SnkOof) is asserted Active High whenever the core loses synchronization with the SPI-4.2interface.

• Sink Bus Error Status (SnkBusErrStat[7:0]) is asserted Active High when a SPI4-2 protocol violation or an errorthat is not associated to one particular data packet occurs. Each bit of the SnkBusErrStat bus corresponds to one ofthe following detected conditions:

- SnkBusErrStat[0]: Minimum SOP spacing was violated.

- SnkBusErrStat[1]: Sequential control words with EOP is received. (EOP followed immediately by another EOP)

- SnkBusErrStat[2]: Sequential payload control words are received. (A payload control word is followedimmediately by another payload control word.)

- SnkBusErrStat[3]: DIP-4 error received during idles or raining patterns.

- SnkBusErrStat[4]: Reserved control words received.

- SnkBusErrStat[7:5]: Tied to zero.

If the core receives two (or more) back-to-back payload control words, the last one received is used, the others are dis-carded. If the cores receives two (or more) EOPs back-to-back, the first one is used, and the others are discarded. For moreinformation see "Sink Core Operation" on page 34.

• Sink Bus Error (SnkBusErr) is asserted Active High when any of the error conditions that flags the Sink Bus ErrorStatus bus is triggered. SnkBusErr is triggered concurrently with SnkBusErrStat.

• Sink Training is Valid (SnkTrainValid) is asserted Active High when valid training data is received. The behavior ofthis signal is illustrated in the timing diagram in Figure 5. As is shown, the SnkTrainValid signal is driven High for theduration of a complete training pattern after it has successfully been received.

Figure 5: Sink Training Valid Status

Table 5: Sink Control and Status Signals


DomainDescription

Reset_n Input n/a Reset: Active Low signals that asynchronously initializes internal flip-flops, registers, and counters. When Reset_n is asserted, the Sink core will go out of frame and the entire data path is cleared (including the FIFO). The Sink core will also assert SnkOof, and deassert SnkBusErr and SnkTrainValid. When Reset_n is asserted, the Sink core will transmits framing "11" on RStat and continue to drive RSClk.

SnkFifoReset_n Input SnkFFClk Sink FIFO Reset: This Active Low signal enables the user to reset the Sink FIFO and the associated data path logic. This enables the FIFO to be cleared while remaining in frame.

Coming out of SnkFifoReset_n, the Sink core will wait until a SOP control word is received to begin writing data into the FIFO.

Training Control Training DataIdle Training DataMultiple Training

Patterns

RdClk

SnkFFClk

RDat

SnkTrainValid

000F 0FFF F000 F0000FFF



SPI-4.2 Core v6.3

Sink FIFO Interface Signals

The Sink FIFO Interface signals allow the user to access the data (received on the SPI-4.2 Interface) that is stored in theFIFO. The description of each of these signals is summarized in Table 6. The information on signals SnkFFData,SnkFFAddr, SnkFFSop, SnkFFEop, SnkFFMod, SnkFFErr, SnkFFDIP4Err, SnkFFPayloadErr, SnkFPPayloadDIP4and SnkFFBurstErr is qualified by the assertion of SnkFFValid. Waveforms illustrating the handshaking and FIFO statussignals are given in Figure 6 and Figure 7. The Sink FIFO Interface signals are synchronous to SnkFFClk, and the FIFO is512 words deep. Each FIFO word can contain up to one credit (16-bytes) of data from a single packet.

Sink FIFO Almost Empty

The behavior of the Almost-Empty (SnkFFAlmostEmpty_n) status signal is illustrated in Figure 6. As is shown in thiswaveform, the almost-empty flag is asserted with the second to last word read out of the FIFO. When this signal is true(active low), it indicates that one word remains in the FIFO, and the user should deassert the read enable signal on the nextclock cycle. The Sink FIFO read logic should then evaluate the SnkFFEmpty_n signal to verify that there is no data in theFIFO in case an additional word was simultaneously written into the FIFO. An example of this interface is provided with the

SnkEn Input SnkStatClk Sink Enable: Active High signal that enables the Sink core. When SnkEn is deasserted, the Sink core will go out of frame and will not store any additional data into the FIFO. The current contents of the FIFO remain intact.

The Sink core will also assert SnkOof, and deassert SnkBusErr and SnkTrainValid. When SnkEn is deasserted, the Sink core will transmits framing "11" on RStat and continue to drive RSClk.

SnkOof Output SnkFFClk Sink Out-of-Frame: Active High signal that indicates that the SPI-4.2 Sink block is not in frame. This signal is set when the Sink block loses synchronization with the data received on the SPI-4.2 Interface. This signal is negated once the Sink block reacquires synchronization with the received SPI-4.2 data.

SnkBusErr Output SnkFFClk Sink Bus Error: Active High signal is an error indication thatflags SPI-4.2 protocol violations or bus errors that are notassociated with a particular data packet. For more informationsee "Sink Core Operation" on page 34. The specific errorcondition that caused the SnkBusErr assertion can be read fromSnkBusErrStat.

SnkBusErrStat[7:0] Output SnkFFClk Sink Bus Error Status: Individual bits of this bus correspond to a specific Sink Bus Error condition and is asserted concurrently with SnkBusErr. The error conditions detected are flagged as follows:

SnkBusErrStat[0]: Minimum SOP spacing violation.SnkBusErrStat[1]: Sequential control words with EOP receivedSnkBusErrStat[2]: Sequential payload control words received.SnkBusErrStat[3]: DIP-4 error received during Training or on Idles.SnkBusErrStat[4]: Reserved control words received.SnkBusErrStat[7:5]: Always tied to zero.

SnkTrainValid Output SnkFFClk Sink Training Valid: Active High signal that indicates that a valid training pattern has been received. This signal is held Active for the duration of the training pattern (20 SPI-4.2 bus clock cycles), if the training pattern received is successfully decoded.

Table 5: Sink Control and Status Signals (Continued)


DomainDescription



SPI-4.2 Core v6.3

SPI-4.2 core in the Design Example (see the pl4_fifo_loopback_read.v/vhd file.) This example also illustrates theSink FIFO Valid signal, which is asserted while there is valid data on the data bus.

Sink FIFO Empty

The behavior of the Empty (SnkFFEmpty_n) status signal is illustrated in Figure 7. As shown in the waveform, the emptyflag is asserted with the last word read out of the FIFO. In this example, the Almost-Empty flag is asserted prior to a readaccess being initiated. In this case, there is one data word remaining in the FIFO. To access this word, the user asserts theSink FIFO Read Enable signal for one cycle.

Sink Almost Full

The behavior of Sink Almost Full flag is dependent on the static configuration signals SnkAFThresAssert andSnkAFThresNegate. When the SnkAlmostFull_n flag is asserted SnkAFThresAssert specifies the number of emptyFIFO locations available. Each FIFO location can contain up to one credit (16 bytes) worth of data from a single packet. TheSnkAFThresNegate specifies when the SnkAlmostFull_n flag is deasserted.

The number of bytes that can be written into the SPI-4.2 sink interface after the Sink Almost Full flag is asserted dependsthe received packet sizes, data patterns, and the operations occurring on the sink user interface. Hence it is advised thatusers configure the SnkAFThresAssert value based on their system requirements.

The following is an example of how to choose a SnkAFThresAssert value. It is assumed that the packets received on theSPI-4.2 interface prior to the assertion SnkAlmostFull_n flag are credit multiples and are not interleaved by idles ortraining patterns. The SnkFFClk is connected to RDClkDiv_GP. A user wants the capability to write 16 credits into theSPI-4.2 interface after the SnkAlmostFull_n flag is asserted and not have the Sink core overflow. For this traffic pattern,the customer must add 12 to the SnkAFThresAssert value to compensate for the data that is received by the Sink core buthas not been written into the FIFO. Hence he needs to set this SnkAFThresAssert value to 28. This will ensure that onceSnkAlmostFull_n is asserted, the Sink core will not overflow if 16 credits are written into the SPI-4.2 sink interface.

"FifoAFMode and Sink Almost Full" on page 25 describes the behavior of the Sink FIFO interface when the sink almost flagis asserted.

Figure 6: Sink FIFO Almost Empty

Figure 7: Sink FIFO Empty

SnkFFData

SnkFFRdEn_n

SnkFFClk

SnkFFAlmostEmpty_n

SnkFFValid

SnkFFEmpty_n

SnkFFData

SnkFFRdEn_n

SnkFFClk

SnkFFAlmostEmpty_n

SnkFFValid

SnkFFEmpty_n



SPI-4.2 Core v6.3

Table 6: Sink FIFO Interface Signals

Signal Name Direction Description

SnkFFClk Input Sink FIFO Clock: All Sink FIFO Interface signals are synchronous to the rising edge of this clock.

SnkFFRdEn_n Input Sink FIFO Read-Enable: When detected low at the rising edge of SnkFFClk, data and status information is read out of the FIFO on the next rising edge of SnkFFClk.

SnkFFAddr[7:0] Output Sink FIFO Channel Address: Channel number associated with the data on SnkFFData.

SnkFFData[63:0]

or

SnkFFData[127:0]

Output Sink FIFO Data Out: The data read from the Sink FIFO. Bit 0 is the LSB.

The core can be configured to have a 64-bit or 128-bit User Interface. The 128-bit interface enables the user to run at half the clock rate required for a 64-bit interface.

SnkFFMod[2:0]

or

SnkFFMod[3:0]

Output Sink FIFO Modulo: These signals indicate which bytes on the SnkFFData bus are valid when the SnkFFEOP signal is asserted.

SnkFFMod[2:0] is used with a 64-bit interface.

SnkFFMod[3:0] is used with a 128-bit interface.

See Table 3 on page 9 and Table 4 on page 10 for bit mapping.

SnkFFSOP Output Sink FIFO Start of Packet: When set (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 set (Active High), this signal indicates that the end of a packet is being read out of the Sink FIFO.

SnkFFErr Output Sink FIFO Error: When set (Active High), this signal indicates that the current packet is terminated with an EOP abort condition. This signal is valid only when SnkFFEOP is asserted.

SnkFFEmpty_n Output Sink FIFO Empty: When set (Active Low), this signal indicates that the Sink FIFO is empty, and no more data can be read until it is deasserted. This signal is asserted with the last data word read out of the FIFO.

SnkFFAlmostEmpty_n Output Sink FIFO Almost Empty: When this signal is true (Active Low), it indicates that one word (64-bits or 128-bits) remains in the FIFO, and the user should deassert the read enable signal 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 interface is provided with the SPI-4.2 core in the Design Example (see the pl4_fifo_loopback_read.v/vhd file).

SnkFFValid Output Sink FIFO Read Valid: When true (Active High), this signal indicates that the information on SnkFFData, SnkFFAddr, SnkFFSOP, SnkFFEOP, SnkFFMod, SnkFFErr, SnkFFDIP-4Err, SnkFFPayloadErr, SnkFFPayloadDIP4, and SnkFFBurstErr are valid.

SnkFFDIP-4Err Output Sink FIFO DIP-4 Error: When set (Active High), this signal indicates that a DIP-4 parity error was detected with the SPI-4.2 control word ending the current burst or packet of data. The DIP-4 error is stored in the FIFO, along with the preceding packet or burst of data. This provides the user information regarding which channel and burst/packet of data preceded the DIP-4 error. For more details see "Sink Core Operation" on page 34.



SPI-4.2 Core v6.3

Sink Status Path and Flow ControlThe Sink FIFO Status Channel interface enables the user to send flow control data on the SPI-4.2 Interface. The channelorder and frequency that the status is sent is programmed by the user in a calendar. A two-bit register is provided for eachlocation in the calendar to store the channel status information (hungry=01, starving=00, satisfied=10). Figure 8 illustrateshow the calendar information is retrieved to determine the order and frequency that a particular channel’s FIFO Statusinformation is transmitted on RStat. A detailed description of the calendar interface and the FIFO Status interface isprovided below and a summary of the Sink Status Path signals and their definitions is provided in Table 7.

SnkFFPayloadDIP-4 Output Sink FIFO Payload DIP-4 Error: When true (Active High), this signal indicates that a DIP-4 error occurred with the SPI-4.2 control word starting the next packet or burst of data. The signal is asserted at the end of that packet or burst of data. For more details see "Sink Core Operation" on page 34.

SnkFFBurstErr Output Sink FIFO Burst Error: When true (Active High), this signal indicates when the Sink core has received data that stops on a non-credit boundary without an EOP. SnkFFBurstErr may be used by the user’s logic to indicate missing EOPs, or incorrectly terminated bursts. In this case the Sink core does not assert SnkFFEOP or SnkFFErr. For more details see "Sink Core Operation" on page 34.

SnkFFPayloadErr Output Sink FIFO Payload Error: When set (Active High), this signal indicates that data was received without a valid payload control word preceding it. Since it is not a payload control word and it is not clear what the packet Address and SOP should be, it is flagged as an error. This is asserted High with each data word coming out of the FIFO, and will remain High until a valid payload “control word - data sequence” is received. For more details see "Sink Core Operation" on page 34.

SnkAlmostFull_n Output Sink Almost Full: When true (Active Low), this signal indicates that the Sink core is approaching full (as defined by the parameter SnkAFThresAssert), and that immediate action should be taken to prevent overflow.

SnkOverflow_n Output Sink Overflow: When true (Active Low), this signal indicates that the Sink core has overflowed and is in an error condition. Data will be lost if SnkOverflow_n is asserted, since no more data will be written into the FIFO until it is not in an overflow state.

Table 6: Sink FIFO Interface Signals (Continued)

Signal Name Direction Description



SPI-4.2 Core v6.3

Figure 8: FIFO Status Calendar and Status Memory Block Diagram

Sink Calendar Initialization

At start-up, the circuitry provided by the user programs the Sink Calendar buffer by first de-asserting Sink Enable (SnkEn),then using the calendar write enable, address bus, and data bus. SnkCalAddr is used to indicate the location in thecalendar buffer, and SnkCalData is used to indicate the channel number that should be written into that location. Whenoutputting RStat, the status for the channel written to SnkCalAddr=0 is output first, followed by SnkCalAddr=1, etc., untilthe end of the Calendar is reached, as defined by SnkCalendar_Len.

The waveform in Figure 9 illustrates the programming of the Sink Calendar. In this example, SnkCalendar_Len is set tofive and SnkCalendar_M is set to zero (indicating that the calendar length is six, and should be repeated once). This meansthat the Sink Calendar will be expected to drive the FIFO Status Channel data (onto the SPI-4.2 bus) in the followingsequence: status for channel 3, status for channel 0, status for channel 1, status for channel 2, status for channel 3, andstatus for channel 0.

Status Memory

0 1 2 3 4 5 6 7

8 9 10 11 12 13 14 15

248 249 250 251 252 253 254 255

15

247

. . .

. . .

Sink FIFO

StatusInterface

Sink Calendar

Control

SnkStatClk

SnkStatAddr[3:0]

SnkStat[31:0]

SnkStatWrEn_n

SnkStatMask[15:0]

SnkCalClk

SnkCalWrEn_n

SnkCalAddr[8:0]

SnkCalData[7:0]

SnkCalDataOut[7:0]

Calendar RAM

.

.

.

0

1

2

3

4

5

509

510

511

SnkCalendar_M

SnkCalendar_Len

RSTAT[1:0]

SnkStatAddr = 0

Bank 0: Ch 0-15



SPI-4.2 Core v6.3

To verify what has been programmed into the calendar buffer, the user can read the contents using the Sink Calendar DataOut bus (SnkCalDataOut[7:0]). When the calendar write enable signal is deasserted, the data stored in the locationspecified by the calendar address is driven onto the SnkCalDataOut bus. See “Appendix B: SPI-4.2 CalendarProgramming” for more examples on programming the SPI-4.2 Calendar.

Sink Flow Control

There are two typical ways to implement the SPI-4.2 Sink flow control:

• Automatic. For a single channel system or a system that does not require flow control on a per-channel basis, the SPI4.2 Sink core can be configured to perform flow control automatically.

• Manual. If per-channel flow control is required, then the core enables the user to fully customize the interface. A typical implementation is shown in Figure 10. In this case, external FIFOs are used to provide additional per-channel storage and to facilitate per-channel flow control. A programmable full indication on the user’s individual FIFOs can be used to drive the status interface of the Sink core. This gives the user flexibility in implementing the optimal flow control for their system requirements.

- If implementing large channel solutions, the user’s individual FIFOs may be shared by sets of channels oralternative approaches may be implemented that enable minimizing the external logic required.

The Sink FIFO Status interface has a 32-bit bus for all channel configurations (e.g., whether the core is configured for fourchannels or 128 channels or 256 channels). This allows the user to write the FIFO Status Channel data for 16 channels ata time. There are four address lines for selecting which 16 channels the user is accessing. (Note that for systems using 1-16channels, the address lines are permanently set to zero.) The latency between the User Interface and SPI-4.2 Interface forthe Sink Status Path is seven RSClk cycles and one SnkStatClk cycle.

The user can write the status for 16 channels each clock cycle. The SnkStatAddr bus is used to select which 16 channelsare written, and the core supports configurations of 1-256 channels. The 16 channels of FIFO Status that are written areaddressed as follows:

• Bank 0: SnkStatAddr[3:0]=0 for channels 15 to 0




• ...



The status that is written is mapped to the 16-bit bus as follows:

For Bank 0: SnkStatAddr[3:0]=0

• SnkStat[1:0] => Channel 0, where SnkStat[1] is the MSB of the 2-bit status

• SnkStat[3:2] => Channel 1

Figure 9: Sink Calendar Initialization

SnkCalendar_M

SnkCalendar_Len

SnkCalClk

SnkCalWrEn_n

SnkCalAddr[8:0]

SnkCalData[7:0]

0x00 0x01 0x02 0x03

CH3 CH0 CH1 CH2

SnkCalDataOut[7:0]

0x04 0x05

CH3 CH0

CH3 CH0 CH1

0x00 0x01 0x02 0x03

SnkCalendar_M=0 (0000.0000)

SnkCalendar_Len=5 (0.0000.0101)



SPI-4.2 Core v6.3


• ...




Figure 10: Typical Flow Control Implementation for 4-Channel System

Sink FIFO Status Interface: Example 1

This example illustrates writing to the FIFO Status Interface for a 10-channel SPI-4.2 Sink core, as shown in Figure 11. Asthere are fewer than 17 channels, the Sink Status Address bus (SnkStatAddr[3:0]) is permanently tied to zero. In thisexample, the mask functionality is utilized to indicate that only 10 channels have valid status. The mask can change fromclock cycle to clock cycle, but in this illustration it is fixed (SnkStatMask= 0x03FF).

The Sink Status Write signal (SnkStatWr_n) is used to write status values to be transmitted on the SPI-4.2 Interface in theorder specified by the calendar buffer. The status written in this example is as follows (note that the status data onSnkStat[31:0] is represented in hexadecimal):

Write Cycle Staving Status Satisfied Status

0,1,2,3 0-9 none

4 1-9 0

5 1,2, 4-9 0,3

6-7 4-9 0,1,2,3

8 0 1-9

FIFO

Channel 0

FIFOChannel 1

FIFO

Channel 2

FIFOChannel 3

Sink Core

FIFO

Status I/F

SPI-4.2Interface

UserInterface

MU

X

Status:

StarvingHungry

Satisfied

Flow ControlProgrammable

Full



SPI-4.2 Core v6.3


This example illustrates writing to the FIFO Status Interface for a 64-channel SPI-4.2 Sink core, as shown in Figure 12. Towrite the status for 64 channels, the user must address the following four banks depending on the status of the channel thatis being updated:

• Bank 0: SnkStatAddr[3:0]= 0000, for channels 15 to 0




In the example shown in Figure 12, the mask (SnkStatMask[15:0]) is used to update only the channels for which FIFOstatus has changed. The status written in this example is as follows:


Example 3 illustrates status received on the user interface and written to the SPI-4.2 bus. Figure 13 shows an RStatwaveform for a calendar length of four (SnkCalendar_Len=3) and calendar repetition value of one (SnkCalendar_M=0).

Figure 11: Sink FIFO Status Interface Example 1: 10-channel configuration

Write Cycle Status Address Status Mask Staving Status Satisfied 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.0000 none CH 12-15

Figure 12: Sink FIFO Status Interface Example: 64-channel Configuration

SnkStatClk

SnkStatMask[15:0]

SnkStatAddr[3:0]

BINARY

BINARY

SnkStat[31:0] HEX 0000.00AA

SnkEn

SnkStatWr_n

0000.0000

0000.0011.1111.1111

0000

Write 0 Write 1 Write 2 Write 3 Write 4 Write 5 Write 6 Write 7 Write 8

000A.AAA80000.00820000.0002

SnkStatClk

SnkStatMask[15:0]

SnkStatAddr[3:0]

BINARY

0000BINARY 0001 0010 0011

SnkStat[31:0] HEX 0000.0000

SnkEn

SnkStatWr_n

0000

0000.0000

1111.0000.0000.0000

Write 0 Write 1 Write 2 Write 3 Write 4 Write 5 Write 6 Write 7 Write 8

0000.0000.0000.0001

8000.00000000.0002

1111.1111.1111.1111 1111.1111.1111.1111

AA00.0000

1000.0000.0000.0000



SPI-4.2 Core v6.3

Note that FIFO status information is periodic, repeating the sequence of a framing pattern (11), a repeated set of FIFOstatus words (SnkCalendar_M + 1 times) in accordance with the programmed calendar order, and a DIP-2 value. Theprogrammed calendar sequence is channel 0, 1, 2, 3, and the following RStat[1:0] sequence is illustrated:

• Sequence #: CH0, CH1, CH2, CH3

• Sequence 1: 10, 00, 00, 00

• Sequence 2: 10, 00, 10, 10

• Sequence 3: 10, 10, 10, 10

Figure 13: Sink Status Path — User Interface to SPI-4.2 Interface

Table 7: Sink Status Interface Signals


DomainDescription

RSClk Output n/a SPI-4.2 Receive Status Clock: Source synchronous clock transmitted with RStat at 1/4 (or 1/8) rate of the RDClk. The rate of the status clock is controlled by the static configuration signal RSClkDiv. The user can select this signal to be either LVTTL or LVDS when the core is instantiated.

RStat[1:0] Output RSClk SPI-4.2 Receive FIFO Status: FlFO-Status-Channel flow control interface. The user can select this bus to be either LVTTL or LVDS when the core is instantiated.

SnkStatClk Input n/s Sink Status Clock: All Sink Status write signals are synchronous to this clock.

SnkStat[31:0] Input SnkStatClk Sink Status Bus: This 32-bit bus is used to access the FIFO Status of 16-channels at a time. The user can write the status for 16 channels each clock cycle.

The 16-channel status that are accessed simultaneously are grouped in the following manner: channels 15 to 0, channels 31 to 16, channels 47 to 32, . . . , channels 255 to 239.

SnkDIP2ErrRequest Input SnkStatClk Sink DIP-2 Error Request: This is an Active High signal that requests an incorrect DIP-2 to be sent out of the RStat bus. The Sink FIFO Status logic will respond by inverting the next DIP-2 value that it sends.

SnkCalendar_M

SnkCalendar_Len

SnkStatClk

SnkStat[31:0] 0x00000002 0x000000A2

SnkStatAddr[3:0] 0000

SnkStatMask[15:0]

SnkStatWr_n

0000.0000.0000.1111

0x000000AA

0 = 0000 0000

3 = 0 0000 0011

RSClk

RStat 0011 10 11 10 10 11 10DIP 00 DIP DIP 11



SPI-4.2 Core v6.3

Insertion of DIP-2 ErrorsThe Sink core enables the user to force the insertion of DIP-2 errors for use during system testing and debugging. This issupported by utilizing the SnkDIP2ErrRequest signal. When, SnkDIP2ErrRequest is asserted, the next DIP-2 value issent on RStat will be erred. The erroneous DIP-2 value is an inversion of the correctly calculated DIP-2.

SnkStatAddr[3:0] Input SnkStatClk Sink Status Address bus: The Sink Status Address determines which 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

. . .

Bank 15: SnkStatAddr=15 channels 255 to 239

SnkStatWr_n Input SnkStatClk Sink Status Write: The Sink Status Write qualifies the SnkStatMask signal. When SnkStatWr_n is asserted (Active Low), status for the different channels may be updated. When SnkStatWr_n is deasserted (Active High), SnkStat input will not be updated.

SnkStatMask[15:0] Input SnkStatClk Sink Status Mask Bus: The Sink Status Mask determines which 2-bit status among the 16 channels on SnkStat will be updated if SnkStatWr_n is asserted (Active Low):

SnkStatMask[x] = 1, status for channel x will be updated.

SnkStatMask[y] = 0, status for channel y will not be updated.

For example, if SnkStatMask[15] = 0, then SnkStat[31:0] = 00 will hold its current value.

If SnkStatMask are all zeros, none of the sixteen 2-bit status will be updated. If SnkStatMask are all ones, all sixteen of the 2-bit status will be updated.

SnkCalClk Input n/a Sink Calendar Clock: All Sink calendar signals are synchronous to this clock.

SnkCalWrEn_n Input SnkCalClk Sink Calendar Write Enable: When this signal is true (active low), the Sink Calendar is loaded with the data on the SnkCalData bus on the rising edge of SnkCalClk. When the signal is false, the Sink Calendar is read on SnkCalDataOut.

SnkCalAddr[8:0] Input SnkCalClk Sink Calendar Address Bus: This bus contains the address to write the calendar number indicated on the SnkCalData bus when SnkCalWrEn_n is asserted.

SnkCalData[7:0] Input SnkCalClk Sink Calendar Data Bus: This bus contains the “channel number” to write into the calendar buffer when SnkCalWrEn_n is enabled. The channel numbers written into the calendar indicates the order that status will be sent on RStat.

SnkCalDataOut[7:0] Output SnkCalClk Sink Calendar Data Output Bus: This bus contains the “channel number” that is read from the calendar buffer when SnkCalWrEn_n is disabled. The channel numbers read from the calendar indicates the order that status will be sent on RStat.

Table 7: Sink Status Interface Signals (Continued)


DomainDescription



SPI-4.2 Core v6.3

Sink Static Configuration SignalsStatic configuration signals are inputs to the core that are statically driven by setting them to a constant value in the top-levelwrapper file. The SPI-4.2 release includes a wrapper file that has the static configuration signals connected to the valuesselected in the CORE Generator GUI. Use the GUI to modify the signals you want to customize.

Two of the Sink Static Configuration signals can be changed in circuit. There are static registers for SnkCalendar_M andSnkCalendar_Len that are synchronous to SnkStatClk. To change these parameters while the core is operational, theuser must first deassert SnkEn.

Note that there are legal values for each of the signals. If you set the configuration signal to an illegal number, the core willautomatically set it to the minimum value. The Sink Static Configuration signals are defined in Table 8.

Table 8: Sink Static Configuration Signals

Signal Name Direction Range Description

NumDip4Errors[3:0] Static Input 1-15

Value of 0 gets set to 1.

Number of DIP-4 Errors: The Sink Interface will go out-of-frame (assert SnkOof) and will stop accepting SPI-4.2 data from across the data bus after receiving NumDip4Errors of consecutive DIP-4 errors.

NumTrainSequences[3:0] Static Input 1-15

Value of 0 gets set to 1.

Number of Complete Training Sequences: The number of complete training patterns which consist of 10 training control words and 10 training data words. The Sink interface requires NumTrainSequences of consecutive training patterns before going in frame (de-asserting SnkOof) and accepting SPI-4.2 data from across the data bus.

SnkCalendar_M[7:0] Input 0-255

(effective range 1-256)

Sink Calendar Period: The SnkCalendar_M parameter sets the number of repetitions of the calendar sequence before the DIP-2 parity and framing words are inserted.

The core implements this parameter as a static register synchronous to SnkStatClk, and it can be updated in circuit by first de-asserting SnkEn.

Note that the calendar period equals SnkCalendar_M + 1. For example, for SnkCalendar_M=22, the Sink Calendar Period will be equal to 23.

SnkCalendar_Len[8:0] Input 0-511

(effective range 1-512)

Sink Calendar Length: The SnkCalendar_Len parameter sets the length of the calendar sequence.

The core implements this parameter as a static register synchronous to SnkStatClk, and it can be updated in circuit by first de-asserting SnkEn.

Note that the calendar length equals SnkCalendar_Len + 1. For example, for SnkCalendar_Len=15, the Sink Calendar Length will be equal to 16.



SPI-4.2 Core v6.3

SnkAFThresAssert[8:0] Static Input 6 to SnkAFThresNegate

Values less than 6 get set to 6

Values greater than SnkAFThresNegate

get set to SnkAFThresNegate

Sink Almost-full Threshold Assert: The SnkAFThresAssert parameter specifies the threshold level at which the Sink core initiates flow control. It defines the minimum number of empty FIFO locations that exist when SnkAlmostFull_n is asserted. Note that the assert threshold must be less than or equal to SnkAFThresNegate. Additional information on SnkAFThresAssert can be found in the Sink Almost Full section.

When SnkAlmostFull_n is asserted, the core initiates the flow control mechanism selected by the parameter FifoAFMode. The FifoAFMode defines when the interface stops sending valid FIFO status levels and begins sending flow control information on RStat. This indicates to the transmitting device that the core is almost full and additional data cannot be sent.

SnkAFThresNegate[8:0] Static Input 6-508

Values less than 6 get set to 6.

Values greater than 508

get set to 508.

Sink Almost-full Threshold Negate: The SnkAFThresNegate parameter specifies the threshold at which the Sink core stops sending flow-control (de-asserts SnkAlmostFull_n) and resumes transmission of valid FIFO status levels. This indicates to the transmitting device that additional data can be sent.

The SnkAFThresNegate parameter specifies the minimum number of empty FIFO locations that exist in for SnkAlmostFull_n to be deasserted. Note that the negate threshold must be greater or equal to SnkAFThresAssert.

RSClkDiv Static Input n/a Sink Status Clock Divide: This static input is used to determine if the RSClk is 1/4 of the data rate, which is compliant with the OIF specification, or 1/8 of the data rate, which is required by some PHY ASSPs:

0: RSClkDiv = 1/4 rate (default value)

1: RSClkDiv = 1/8 rate

RSClkPhase Static Input n/a Sink Status Clock Phase: This static input determines whether the FIFO Status Channel data (RStat[1:0]) changes on the rising edge of RSClk or the falling edge of RSClk:

0: RSClkPhase = rising edge of RSClk (default value)

1: RSClkPhase= falling edge of RSClk

Table 8: Sink Static Configuration Signals (Continued)




SPI-4.2 Core v6.3

FifoAFMode and Sink Almost Full

The user can select the behavior of the Sink core when it is almost full. This is done by setting the static configuration signalSink FIFO in Almost-full Mode (FifoAFMode[1:0]). Figure 14, Figure 15, and Figure 16 are timing diagrams illustratingthe behavior of the core for each of the three modes.

FIFO Almost-full Mode 1

When the FIFO Almost-full Mode (FifoAFMode) is set to “00” and the Sink core becomes almost full, the Sink interface willgo out-of-frame, and the Sink Status logic will send the framing sequence “11” until SnkAlmostFull_n is deasserted. Thisis illustrated in Figure 14.

FifoAFMode[1:0] Static Input n/a Sink Almost-full Mode: Selects the mode of operation for the Sink interface when the Sink core reaches the almost-full threshold (SnkAFThresAssert).

If FifoAFMode is set to “00,” the Sink interface will go out-of-frame when the core is almost full, and the Sink Status logic will send the framing sequence “11” until Sink core is not almost full.

If FifoAFMode is set to “01,” the Sink interface will remain in frame (SnkOof deasserted), and the Sink Status logic will send satisfied “10” on all channels until SnkAlmostFull_n is deasserted.

If FifoAFMode is set to “10” or “11,” the Sink interface will remain in frame (SnkOof deasserted), and the Sink Status logic will continue to drive out the user’s status information (i.e., continue in normal operation). In this case, the user should take immediate action to prevent overflow and loss of data.

Table 8: Sink Static Configuration Signals (Continued)




SPI-4.2 Core v6.3


When the FIFO Almost-Full Mode (FifoAFMode) is set to “01” and the Sink core becomes almost-full, the Sink interface willremain in frame (SnkOof deasserted), and the Sink Status logic will send satisfied (“10”) on all channels untilSnkAlmostFull_n is deasserted. This is illustrated in Figure 15.


When the FIFO Almost-full Mode (FifoAFMode) is set to “10” or “11” and the Sink core becomes almost full, the Sink Statuslogic will continue to drive out the user’s status information (continue in normal operation). In this last case, the user shouldtake immediate action to prevent FIFO overflow and loss of data. This is illustrated in Figure 16.

Figure 14: FIFO Almost-full Mode 1


D D

11 11

D D D D D D D DD D DRDat_P

RDClk_P

D

SnkAlmostFull_n

SnkFFClk

00 00 00 00RStat

RSClk

SnkStat

SnkStatClk

00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 11 11 11 11 11 11 11 11 11 11 11

SnkOof

D D D D

00 00 000000 00 00

D D D D D

D D

10 10

D D D D D D D DD D DRDat_P

RDClk_P

D

SnkAlmostFull_n

SnkFFClk

00 00 00 00RStat

RSClk

SnkStat

SnkStatClk

00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 10 10 10 10 10 10 10 10 10 10 10 10

SnkOof

D D D D

00 00 000000 00 00

D D D D



SPI-4.2 Core v6.3

Sink Synchronization Start-upFigure 17 shows a state machine diagram illustrating the Sink core startup sequence and its error condition processing.After a core reset, the Sink core begins in the RESET state. While in the RESET state, the core sends the framing pattern(11) on RStat, and until synchronization is achieved the Sink core does not write data into the Sink FIFO.

The following summarizes the start up sequence for the Sink core:

1. Disable the Sink core (SnkEn = 0).

2. Assert and release the RDClk DCM Reset (DcmReset_RDClk), and wait until the RDClk DCM Locked signal (Locked_RDClk) is asserted.

3. Assert and release the Sink core reset (Reset_n).

4. Program the Sink Calendar (if required).

5. Enable the Sink core (SnkEn = 1).

For Dynamic Alignment Mode, pulse the PhaseAlignRequest signal High for 2 x the SnkFFClk period (just long enoughfor PhaseAlignRequest to be recognized), deassert PhaseAlignRequest, and wait for PhaseAlignComplete to beasserted. Repeat PhaseAlignRequest assertion only if Sink core goes out of frame during the operation (SnkOof = 1).Also, when Dynamic Alignment mode is used, the Sink core must be receiving a training pattern to perform the phasealignment (PhaseAlignRequest). Ensure that the Source core is capable of sending a training pattern at the startup andwhen "Sink Core Out of Frame" (SnkOof) has been asserted by the Sink core before doing an alignment.

Once the Sink core is enabled and the clock has been successfully aligned, the core enters the HUNT state and waits for aprogrammable number of consecutive training patterns (NumTrainSequences).

When the required number of training pattern matches is received, the core goes to the SYNC state and normal operationbegins. In this state, the core processes data received on the SPI-4.2 bus and stores it in the Sink FIFO. The core alsotransmits valid FIFO Status Channel data on the SPI-4.2 status bus.

While in the SYNC state, if a defined number of consecutive DIP-4 errors are detected (NumDip4Errors), or the Sinksection is disabled (SnkEn), the core will go back to the RESET state.


10 10

DD D D D D DD D D DRDat_P

RDClk_P

D

SnkAlmostFull_n

SnkFFClk

00 00 00 00RStat

RSClk

SnkStat

SnkStatClk

00 00 00 00 10 10 10 10 10 10 10 10 00 00 00 00 00 00

00 10 10 10 10 10 10 10 10 10 10 10 10

SnkOof

D D

00 00 001010 00 00

D D DD D D



SPI-4.2 Core v6.3

Sink Data Capture ImplementationThe SPI-4.2 core supports both static alignment and dynamic alignment of the Sink RDClk to RDat[15:0] as defined bythe SPI-4.2 standard. The method for aligning the received data affects only the Sink core. The Source core does notchange, whether static or dynamic alignment is selected. The user interface and I/O pinout are also the same regardless ofthe type of alignment required.

Dynamic Alignment

The Sink core can be configured to support dynamic alignment on the incoming source synchronous SPI-4.2 data stream(RCtl and RDat[15:0] with respect to the RDClk). Dynamic alignment provides the SPI-4.2 Interface with increasedsystem margin by removing data skew across the ingress SPI-4.2 bus as part of an interface timing budget. Theimplementation determines the ideal sampling point for each incoming bit independent of all other bits. A second alignmentphase uses the SPI-4.2 training pattern to remove any bus skew (potential for the sampled bits to have originated fromdifferent bus cycles) induced by the independent bit sampling or bus skew on the PCB or backplane.

The increase in timing margin on the interface does have a cost associated with FPGA resources and power dissipation.Selecting dynamic alignment as an implementation option will increase the size of the Sink logic by ~900 slices and coulddissipate more than 500mW of additional power (depending on the switching density of the bus). From a black boxperspective there are no differences in the Sink Core interface definition for the static and dynamic alignment options. Itshould be noted that the use of dynamic alignment does not relax the PCB design requirements for high-speed differentialsignals. Each individual bit pair should still have matched length and controlled impedance traces to ensure signal integrityat 300MHz and above.

Dynamic Alignment Implementation Considerations

There are two signals on the Sink user interface that are used in conjunction with Dynamic Alignment, which aresummarized in Table 9. The dynamic alignment algorithm requires training patterns on the SPI-4.2 bus to complete the

Figure 17: Sink Startup Sequence State Machine

SYNCHUNTRESET

Reset Asserted, Sink Disabled, or Consecutive

Incorrect DIP-4 Calculations Detected

Reset Asserted orSink Disabled

The Sink core remains in the reset stateuntil the following conditions are true:1. Reset_n is de-asserted2. Clock Alignment is complete. Automatic Static Alignment: RDClk is

aligned to the eye of the RDat[15:0]data bus.

Dynamic Alignment: Per bit deskew isperformed and RDClk is aligned to theeye of the RDat[15:0] data bus.

The Sink core transmits framing patternson RStat[1:0] while in the reset state .

The Sink core remains in the hunt stateuntil the following condition is true: A set number of consecutive training

patterns are received as defined bythe parameter NumTrainSequences.

The Sink core transmits framing patternson RStat[1:0] while in the hunt state.

In the sync state, the Sink core hascompleted the start-up sequence andnormal core operation is enabled.

In normal operation, the Sink corecontinuously checks DIP-4 parity, storesdata received on RDat[15:0] into theSink FIFO, and sends FIFO ChannelStatus on RStat.



SPI-4.2 Core v6.3

alignment. If PhaseAlignRequest is activated when the Sink logic is not receiving training patterns, the logic will fail toachieve lock or obtain an incorrect lock.

The user should not assert PhaseAlignRequest unless the Sink logic is indicating out-of-frame (SnkOof asserted). Whenthe Sink state machine is out-of-frame, it will send framing patterns (all 11s) on its FIFO status channel. The SPI-4.2specification requires the PHY Transmit device to respond to this condition by sending continuous training patterns.

An alternative solution is to assert PhaseAlignRequest twice. The first request will fail, which causes the Sink logic tobecome out-of-frame (SnkOof indicated); at this point, PhaseAlignRequest may be correctly asserted. Note that thereshould be some lag (that will be system dependent) between the receipt of the SnkOof indication and the assertion of thesecond PhaseAlignRequest to ensure that the Source side has started sending valid training sequences.

Static Alignment

The SPI-4.2 Core performs static alignment by using the RDClk DCM to shift the internal version of the RDClk such that itsedges are centered to the data eye of RDat/RCtl at the IOB DDR flip-flops. The ability of the DCM to shift the internal clockin small increments (~50ps) is critical for sampling the SPI-4.2 source synchronous signals. For statically aligned systems,the DCM output clock phase offset (set by PHASE_SHIFT in UCF file) is a critical part of the system. This, combined with therequirement that the PCB be designed with precise delay and impedance matching for all the differential pairs of the LVDSdata bus, are key for SPI-4.2 static alignment.

Static Alignment Implementation Considerations

The user determines the optimal DCM setting (PHASE_SHIFT) to ensure that the target system will have the maximumsystem margin and performance across voltage, temperature, and process (chip to chip) variations. Testing the system todetermine the best DCM PHASE_SHIFT setting has the added advantage of providing a benchmark of the system marginbased on the UI (unit interval or bit time).

System Margin (ps) = UI(ps) * (working phase shift range/128)

Xilinx does not recommend a singular DCM PHASE_SHIFT value that will be effective across all hardware platforms. Xilinxalso does not recommend that you attempt to determine the PHASE_SHIFT setting empirically. In addition to theclock-to-data phase relationship, other factors such as package flight time (package skew) and clock routing delays (internalto the device) affect the clock data relationship at the sample point (in the IOB) and are difficult to characterize.

The optimal PHASE_SHIFT setting should be investigated during hardware integration and debugging. Note that the phaseshift setting provided with the SPI-4.2 core in the constraints file is only a place holder, and has been determined to work onthe Xilinx SPI-4.2 hardware platform. (Note that this default setting has changed for the various SPI-4.2 releases to accountfor changes to the DCM DESKEW ADJUST attribute.)

Table 9: Dynamic Alignment Signals

Signal Name Direction Clock Domain Description

PhaseAlignComplete Output SnkFFClk Phase Alignment Complete: Active High signal that indicates that the phase alignment is complete.

PhaseAlignRequest Input SnkFFClk Phase Alignment Request: Active High signal that requests that the phase alignment of the data (RDat) to the clock (RDClk) be initiated. This signal can only be asserted when SnkOof and PhaseAlignComplete are

asserted.

SnkDPAModeSel Input SnkFFClk Sink DPA Mode Select: An input signal that determines whether the DPA mode is operating on fast (Active High) or slow delay implementation. In ‘‘‘‘‘‘, this pin should be

tied high.

SnkDPAMode Output SnkFFClk Sink DPA Mode: Active High signal that indicates whether the DPA mode has automatically selected a fast

or slow delay implementation. This output reflects the value of SnkDPAModeSel.



SPI-4.2 Core v6.3

For further information on how to find the ideal phase shift value for your system, please refer to the Xilinx SPI-4.2 solutionrecord 16112.

Note that the PhaseAlignRequest, PhaseAlignComplete, and SnkDPAMode signals are present but not currentlyimplemented for the Static Alignment core. PhaseAlignRequest should be tied to a constant zero.

PhaseAlignComplete and SnkDPAMode should be ignored.

Sink Clocking ImplementationFor the generation of the Sink I/O reference clock, the configuration options depend on whether the data is received utilizingStatic or Dynamic Phase Alignment. If the Sink core is configured for Static Phase Alignment, the core supports twoimplementations:

• CLK0/CLK180. his implementation uses the DCM to generate both a full-rate clock (Clk0) and an inverted full-rateclock (Clk180). This configuration provides improved performance on the Sink interface and is illustrated in Figure 18.

• CLK0/Local Inversion.This implementation distributes a signal full-rate clock (Clk0) and uses the inversion capabilityof the dual data rate registers to generate Clk180. This configuration uses fewer global clock resources and isillustrated in Figure . Note: This clocking scheme is not supported in Virtex-II Pro.

The user selects the clock implementation in the CORE Generator interface. For speeds up to 700 Mbp/s, either clockingscheme is acceptable. For clock rates over 700 Mbp/s, the CLK0/CLK180 scheme must be implemented.

If the core is configured for Dynamic Phase Alignment, then the configuration of the Sink clocks is implementedautomatically to ensure optimal performance. This configuration is illustrated in Figure 19.

A list of the Sink Clocks and their description is given in Table 10, the DCM reset and locked signals are defined in Table .



SPI-4.2 Core v6.3

Figure 18: Sink Clocks: Use DCM to Generate Clk180

RDClk0_GP

RDClk1 80_ GP

RDClkDiv_GP

IOBRDClk

Denotes I/O on User Interface

RDat[15:0] & RCtl IOBQ D

Q D

RDClk0_GP

RDClk180_GP

IOB DDR Flops

DIV2

RDClkDiv_GP

Q D

16 to

64

-bit

MU

X

Sink InternalData & Control

Bus

RDClkDiv_GP

D Q

EN

Enable at ¼ (or 1/8) SPI-4.2 Rx data rate

IOBRStat[1:0] & RSClkInternal Bus

RStat[1:0] & RSClk

CLK0

CLK180

DCM

DCMReset_RDClk

Locked_RDClk



SPI-4.2 Core v6.3

RDClk0_GP

RDClkDiv_GP

IOBRDClk

Denotes I/O on User Interface

RDat[15:0] & RCtl IOBQ D

Q D

RDClk0_GP

RDClk0_GP

IOB DDR Flops

DIV2

RDClkDiv_GP

Q D

16 to

64

-bit

MU

X

Sink InternalData & Control

Bus

RDClkDiv_GP

D Q

EN

Enable at ¼ (or 1/8) SPI-4.2 Rx data rate

IOBRStat[1:0] & RSClkInternal Bus

RStat[1:0] & RSClk

CLK0

CLK180

DCM

DCMReset_RDClk

Locked_RDClk

N/A



SPI-4.2 Core v6.3

Figure 19: Sink Clocks: Dynamic Phase Alignment

Table 10: Sink Clocks

Clock Pins Direction Description Max Freq.Global Clock

Buffer

RDClkDiv_GP Output(User Interface)

RDClkDiv General Purpose: This clock is half the frequency of RDClk. It is used for clocking the internal logic of the core and is routed to t

0 spi-4.2 core v6application-notes.digchip.com/077/77-43554.pdf · 2009. 2. 8. · spi-4.2 core...

Documents