Migrating from SPI 4.2 to SPI 5 IP Core - Architectural Changes and Re-usability

By Kaushal D. Buch, eInfochips Ltd.,
Ahmedabad, India.

Abstract:

High bandwidth data transfers have led to migration from existing packet interface standards to advanced ones. SPI (System Packet Interface) v4.2 has, for many years, remained an industry standard for packet based transfers from link layer to PHY layer. However, due to increasing bandwidth requirements, there is a need to migrate to SPI 5, which supports a data rate four times that of SPI 4.2. This article discusses the architectural changes and IP re-usability scope for modifying an existing SPI 4.2 Transmitter and Receiver IP Core. SPI 4.2 and SPI 5 have a great deal of functional similarity which makes this IP migration smoother. The paper considers an existing SPI 4.2 IP core and examines the architectural changes and re-usability of the sub-modules. The addition of a few modules, which are a part of SPI 5 protocol, is also highlighted.

Introduction

SPI 4.2 and SPI 5 are quite similar protocols as far as the data transfer sequence and packet formation is concerned. The entire data path is functionally similar, except for the data rate, which is 4 times higher in SPI 5. The SPI 4.2 standard supports a minimum data rate 622 Mbps per line, while SPI 5 standard supports 2.2488 Gbps. As SPI 4.2 has remained an industry standard protocol, ready-to-use IPs are available. This paper analyzes the functional differences in the protocols and considers a case-study by converting an existing SPI 4.2 IP core to SPI 5 IP core.

The architectural changes are discussed for each block of existing SPI 4.2 IP and corresponding changes for making it SPI 5 compliant are described.
 
Migration to SPI 5 standard

Formation of data packets, training and status blocks are the main components of both SPI 4.2 and SPI 5 IP implementation. SPI 5 data packets are very similar to those of SPI 4.2. Moreover, the concept of data path and status trainings as well as status information formats is nearly the same. Hence, functional migration does not need drastic changes. The pin configurations and data bus sizes are the same, except for the status clock line, which is not present in SPI 5 standard.
 
Architectural Changes & Additions

1. The data rate of SPI 5 is four times that of SPI 4.2. Hence, to translate an existing SPI 4.2 IP with 64-bit interface to a SPI 5 IP, the clock speed needed would be nearly 622 MHz, giving an aggregate throughput of 622 MHz * 64 = 2.488 Gbps. However, it is not always possible, especially in smaller packets, to achieve a rate of 2.488 Gbps per line on SPI 5 bus. In that case, as suggested by the SPI 5 protocol specifications, a ‘token count’ algorithm needs to be implemented.  (Refer TOKEN_MAX and TOKEN_GEN design parameters and their implementation in SPI 5 specifications document)

2. Status path is aligned with the data path clock in SPI 5 standard, unlike in the SPI 4.2 standard where the status clock is separate. This requires some architectural changes in the status path to reduce the backpressure on the status path FIFO.

3. The input data from the link layer in case of SPI 5 IP needs to be over-clocked by 9 % (Considering an overhead of 4-bytes for a 32 byte packet).

4. Addition of LFSR is required for scrambling and de-scrambling of data and status information in transmitter and receiver respectively.

5. The receiver operating frequency has to be the same as the transmitter operating frequency in order to ensure throughput and compliance with the specifications.

6. The pool status information needs to be sent, the format of which is slightly different from the SPI 4.2 protocol, and hence changes have to be made to comply with the SPI 5 protocol and the data rate.

7. Packet formation (in transmitter) needs address data word and address control word which is not present in the SPI 4.2 protocol. The receiver needs similar changes in the defragmentation of the packet. However these are optional features as per SPI 5 specification.

 
Modifications in SPI 4.2 IP Core

Figures 1 and 2 show the modifications needed in the SPI 4.2 IP core (Tx and Rx) to make it compliant with the SPI 5 standard.

These changes are categorized into three categories – The blocks that need to be removed, the blocks that need to be modified and the blocks that need to be added for both the transmitter and receiver core.

As seen in the Fig. 1 & 2, most of the blocks can be re-used. The major modifications need to be made in the packet framer to comply with the specifications of SPI 5 protocol. Here it is assumed that the port arbitration and credit management is done outside the transmitter and receiver IPs.

In order to achieve the data rate of SPI 5,  the SPI 4.2 IP core needs a different set of timing constraints and methods of achieving better timing e.g. pipelining, retiming etc.  As the target technology for SPI 5 (65nm) is usually smaller than SPI 4.2 (90nm), there is a possibility of having lesser number of critical timing paths.
 


Figure 1: SPI 4.2 Transmitter IP block diagram indicating changes needed to migrate to SPI 5 compliant transmitter IP.
 


Figure 2: SPI 4.2 Receiver IP block diagram indicating changes needed for migration to SPI 5 compliant receiver IP.


Conclusion

The paper explains architectural and reuse approaches to design SPI 5 IP from SPI 4.2 IP. A case study of an existing SPI 4.2 transmitter IP was considered and architectural changes and module re-use were examined. It is inferred that there is about 15%-20% change and enhancement in transmitter and 10%-15% in the receiver of SPI 4.2 IP to functionally comply with the SPI 5 standard. The percentage figure will depend on the existing SPI 4.2 IP architecture and features.
 
Acknowledgements

I would like to thank Mr. Anand S Moghe, Head – ASIC Design and Backend services, eInfochips Ltd., for his encouragement and guidance.

References

1. Optical Internetworking Forum (OIF) SPI Level 4 Phase 2 Specifications – OIF-SPI-4-02.1
2. Optical Internetworking Forum (OIF) SPI Level 4 Phase 2 Specifications – OIF-SPI-5-01.1