Development of Verification Environment for Layered Protocol using SystemVerilog

By Ganesh S Dekate
Infineon Technologies India Pvt. Ltd, INDIA.


Abstract:

Today, functional verification consumes most of the time in the design of layered protocols like OSI Model, PCI Express, etc. As we think of reuse of design components, the reuse of verification components is also a demand to keep the pace with tight schedules and accelerate time-to-market of designs. The verification efforts spent at the module level should be utilized at the sub-system and system level. In other words, the verification components used for the verification of each individual layers should be capable of being reused when you put all the layers together.

The IEEE 1800 SystemVerilog hardware design and verification language has emerged to provide an efficient, industry-standard foundation on which to build reusable and interoperable verification environments using advanced verification methodologies such as coverage-driven, constrained-random test generation, SVA.

This paper explains how individual layered specific verification components such as, Transactor, Checker, Monitor which can be developed using SystemVerilog can be reused when you have all the layers connected at the sub-system and system level, and hence maximizes the verification productivity gains.

1.  Introduction

This paper will cover general aspect of verifying layered protocols like OSI Model, PCI Express, etc. This paper is not going to cover the complete verification of OSI Model but instead will concentrate on layered protocol in general and then verification of XAUI. We will first see what each section is going to concentrate on.

The 2nd section describes in general the layered protocol structures and its verifications. Initially, the concept of verifying individual layers and then complete RTL protocol stack. The same concept will be used for verification of XAUI (10 Gigabit Attachment Unit Interface) core and same concept can be used for other layered protocols cores as well.

3rd section will describe the XAUI (10 Gigabit Attachment Unit Interface). 4th section will focus on - Why SystemVerilog is chosen as verification language.

5th section will cover the development of verification environment for XAUI core. There are two types of verification strategies described: One with feeding back the data in the RTL stack from Tx path to the Rx path. Other one is verifying RTL stack with 3rd party XAUI IP.

2. Layered Protocol in General

This section is dedicated to the layered protocol in general, and not concentrating on OSI Model. Generally a layered protocol has more than one layer. The complete functionality of the protocol is divided into a series of layers. Each layer has the property that it only uses the functions of the layer below, and only exports functionality to the layer above.

This section provides an overview on verification of individual layers and then makes use of those components in the system level.

2.1 - Individual protocol layer verification environment

Figure 1 depicts the verification environment for protocol layer1. The details on each individual verification components will be discussed in subsequent sections. In figure1, dotted component could be removed if you do not need to have functional coverage. But it is better to have this as you will get more functional coverage. Same strategy would be used for the verification other protocol layers 2 and 3 as shown in figure 1.

Figure 1: Protocol Layer1 Verification environment

2.2 – Verification environment for stack of protocol layers

Figure 2 depicts the verification environment for stack of all three protocol layers. The transaction is generated by the transactor on the input Tx interface of Layer1. In this configuration the output Tx data from Layer3 is being fed back to the input Rx part of the Layer3. The information is received on the output Rx interface of Layer1 is the input to the Collector. The End2End Monitor/Checker checks the information transferred by the input Tx part of Layer1 with the information received by the output Rx part of Layer1.

Functional Coverage logic receives the information whether test is passed or not. Depending on this information Functional Coverage logic will update the functional coverage report if test is passed. If test failed the functional coverage report won’t be updated.

Pseudo-random/Directed testcase can be developed depending on Functional coverage report and hence the transaction can be generated.

Monitors M1, M2, M3 will monitor the data integrity between input data with the output data for Layer1, Layer2 and Layer3 respectively.

Assertion checkers C1, C2, C3 will check the protocol between the interface signals.

Figure 2: System level Verification environment for all the layers.

3.    OSI model – XAUI interface

The OSI (Open System Interconnections) reference model is a hierarchical structure of seven (Application, Presentation, Session, Transport, Network, Data link and Physical) layers that defines the requirements for communications between two computers.  

XAUI is pronounced as “Zowie” is a 10 Gigabit Attachment Unit Interface. This is a technical innovation that dramatically improves and simplifies the routing of electrical interconnections. The XAUI is designed as an interface extender, and the interface, which it extends, is the XGMII, the 10 Gigabit Media Independent Interface. The XGMII may be used to attach the Ethernet MAC to its PHY. The XAUI may be used in place of XGMII, or to extend, the XGMII in chip-to-chip applications typical of most Ethernet MAC to PHY interconnects.

The XGMII provides full duplex operation at a rate of 10 Gb/s between the MAC and PHY. Each direction is independent and contains a 32-bit data path, as well as clock and control signals. In total the interface is 74 bits wide. While XGMII provides a 10 Gb/s pipeline, the separate transmission of clock and data coupled with the timing requirement to latch data on both the rising and falling edges of the clock results in significant challenge in routing the bus more than the recommended short distance of 7 cm. For this reason, chip-to-chip, board-to-board and chip-to-optical module applications are not practical with this interface. Consequently, the XGMII bus puts many limitations on the number of ports that may be implemented on a system line card.

To overcome these issues, the IEEE 802.3ae 10 Gb Ethernet Task Force developed the XAUI interface and it delivers 10 Gb/sec (Gigabit/Seconds) of data throughput using four differential signal pairs in each direction. The self-clocked nature eliminates skew concerns between clock and data, and extends the functional reach of the XGMII by approximately another 50 cm. Conversion between the XGMII and XAUI  interfaces occurs at the XGXS(XAUI   Extender Sub-layer).

4.  Why SystemVerilog as verification language?

SystemVerilog (IEEE 1800TM) is the industry's first unified Hardware Description and Verification Language (HDVL) standard. It was developed originally by Accellera to dramatically improve productivity in the design of large gate-count, IP-based, bus-intensive chips. SystemVerilog has been adopted by 100's of semiconductor design companies and supported by many EDA, IP and training solutions worldwide.

This language is chosen because of following key advantages:

• One language for Design and Verification.

• SystemVerilog provides a complete verification environment with the help of features like:
• Constraint Random Generation
• Coverage Driven Verification
• Assertion Based Verification.

• SystemVerilog is an integrated part of the Simulation tool like Modelsim. There is no need for any external tool, GUI or interface (such as PLI) in order to run it. Hence, the adoption process of SystemVerilog is very fast causing designers and verification engineers to find it friendly and easy to use.

• The performance of doing verification using SystemVerilog is about 2 times faster than with any other verification languages, which requires external interface to the simulation tool.

• SystemVerilog is an extension of the popular Verilog language, the adoption process of SystemVerilog by engineers is extremely easy and straightforward. SystemVerilog enables engineers to adopt a modular approach for integrating new modules into any existing code. As a result, the risks and costs of adopting a new verification language are reduced.

5. XAUI Verification Environment

This section is dedicated to development of verification environment for XAUI cores. The verification environment for verifying individual XGXS, PCS and PMA would be same as shown in figure 1. Hence verifying individual cores is not covered here, instead would focus on verification when putting all the cores together.

First sub-section will focus on verification using looping-back the data from PMA.  Second sub-section will focus on verification XAUI RTL stack using 3rd party IP.

5.1 XAUI Verification environment with loop-back of data:

Figure 3 shows the verification environment for XAUI along with XGXS, PCS and PMA.

In this configuration the Tx data from PMA is being fed back to the Rx part of the PMA. The transaction will be generated by the transactor on the Tx interface of XGXS. The information is received on the Rx interface of XGXS is the input to the Collector.

The End2End Monitor/Checker checks the information transferred by the Tx part of XGXS with the information received by the Rx part of XGXS.

Functional Coverage logic written in SystemVerilog receives the information whether test is passed or not. Depending on this information if test is passed then Functional Coverage logic will update the functional coverage report. If test is failed then functional coverage report won’t be updated.

Pseudo-random/Directed testcase can be developed depending on Functional coverage report and hence the transaction can be generated.

Monitors M1, M2, M3 written in SystemVerilog will monitor the data integrity between input data with the output data for XGXS, PCS and PMA respectively.

Assertion checkers C1, C2, C3 written in SystemVerilog assertions checks the protocol between the interface signals.

Figure 3: Verification environment with loop-back.

5.2    XAUI Verification environment for RTL-3rd party IP

Figure 4 shows the verification environment for XAUI along with XGXS, PCS and PMA where RTL stack is being connected to the 3rd party XAUI IP.

In this configuration the Tx data from PMA is being fed to the Rx part of the 3rd party IP. The Tx data from 3rd party IP is being fed to the Rx part of the PMA.

There are two data paths in this configuration:

1) Data flow from RTL stack to 3rd party IP:

The Tx transaction on RTL stack side will be generated by the transactor on the Tx interface of XGXS.  This Tx info will be passed to the Tx part of PMA through XGXS, PCS.  The Tx data from PMA is the input data to 3rd party IP on the link side.  The received info on the 3rd party side from the RTL side will passed to the End2End monitor/checker. End2End monitor/Checker compares this received info on 3rd party side with the transmitted info from the RTL stack side. Depending on this comparison End2End monitor/Checker will convey the pass/fail information to the Functional coverage logic.

2) Data flow from 3rd party IP to RTL stack:

Transaction on 3rd party side will be generated by the Tx part of 3rd party model. As on the link side Tx part of 3rd party model is connected to the Rx part of RTL stack, Tx data from 3rd party model will be flown in to Rx part of the RTL stack.

A Collector on RTL stack side will collect the data received Rx part of RTL stack. This data will be passed to the End2End Monitor/Checker. The End2End Monitor/Checker will compare the data received from the collector and the data transmitted from 3rd party model. Depending on this comparison End2End monitor/Checker will convey the pass/fail information to the Functional coverage logic.

If there are no miss-compares in both of the cases described above, then only coverage report will be updated. The functional coverage report indicates the percent age of covered bins. If all of coverage bins are covered then simulations can be stopped.

Pseudo-random/Directed testcase can be developed depending on Functional coverage report and hence the transaction can be generated.

Monitors M1, M2, M3 will monitor the data integrity between input data with the output data for XGXS, PCS and PMA respectively.

Assertion checkers C1, C2, C3 will check the protocol between the interface signals.

Figure 4: Verification environment RTL-3rd party IP.

6.    Conclusions

• The individual protocol layered verification components can be re-used for verifying complete protocol stack of all the layers, and hence maximizes the productivity gains.

• Only one language can be used for design and verification of XAUI core.

• SystemVerilog can be extremely handy in developing a complete verification environment with the help of features like, Constraint Random Generation, Coverage Driven Verification and Assertion Based Verification.

7.    References

• IEEE Std 802.3-2005

• XAUI: An Overview. Version 1.0 March 2002, Authored by John D’Ambrosia, Tyco Electronics, Shawn Rogers, Texas Instruments, Jim Quilici, Intel Technologies.

• Xilinx presentation on ”XAUI, XGMII, XSBI - 10 GE Interfaces”.

• 10 Gigabit Ethernet and the XAUI Interface - New testing challenges for the 71612C 12.5 Gb/s error performance analyzer – Geoff Waters(January 2002), Agilent Technologies.

• Accrelera’s SystemVerilog LRM.