XGMII e Verification Component

IP Part Number: DR905-XGMII-eVC

 

Features

• IEEE 802.3ae/D3.4 compliant MAC layer to PHY layer interface

• Targeted for an e Verification environment

• Modular, Extensible/Configurable and Re-useable

• Self Checking, Random Generators

• Stand Alone Configuration with eVC Loop Back

• Straight Forward Integration

Applications

Ethernet Switches, Routers and transceivers operating at 10 Gb/s

 

Overview

The port diagram above shows an UML-port diagram for the XGMII (10 Gigabit Media Independent Interface) Verification Component. It is a ready-to-use, out-of-the-box verification environment for a core using the XGMII protocol.

 

The XGMII e Verification Component is designed to satisfy the following requirements:

• Transfer frames between a MAC layer device and a PHY device

• Inject error conditions into the device under test

• Viewable interfaces, which can be extended easily

• Coverage monitors for interface state machines

Structure Description

 

 

Table 1: XGMII eVC struct descriptions overview

 

 

Table-2 XGMII DUT Interface port signals

XGMII Control Characters (RXC/TXC = 1), Table-3

Idle (0x07) occurs

1. During an Inter-frame Gap

2. When there is no data to send/receive

Start (0xFB) occurs

1. For a 1 byte duration at the beginning of a frame

2. Always on Lane 0

Terminate (0xFD) occurs

1. For a 1 byte duration at the end of a frame

2. On any Lane

Error (0xFE) occurs

1.       When an error is detected in a received signal

2.       When an error needs to be forced into a transmitted signal

3.       When a Start or Sequence ordered_set control character appears on any octet other than lane 0

 

XGMII Normal Data Character (RXC/TXC = 0), Table-3

 

�  Frame Data (0x00 � 0xFF) occurs

During normal data transmission

 

Table-3 XGMII lane encoding

 

XGMII Ordered Set (RXC/TXC = 1), Table-5

 

�  Sequence ordered set (0x9C) occurs

 

1.   When a Local or Remote link fault is detected on a receive or transmit data path respectively

2.   Always on Lane 0

 

Table-5 XGMII Sequence ordered_sets for link fault signaling

 

Link Fault status is signaled in a four bytes Sequence ordered_set. The PHY indicates a Local Fault and the RS indicates a Remote Fault.

The RS reports the fault status of the link. Local fault indicates a fault detected on the receive data path between the remote RS and the local RS. Remote Fault indicates a fault on the transmit path between the local RS and the remote RS. The RS implements the link fault signaling state machine

The RS outputs TXC[3:0] and TXD[31:0] are controlled by the state machine variable link_fault within the RS.

�         Link_fault = OK

1.       The RS sends MAC frames as requested. In the absence of MAC frames, the RS generates Idle control characters.

�         Link_fault = Local Fault

2.       The RS continuously generates Remote Fault Sequence ordered_sets.

�         Link_fault = Remote Fault

3.       The RS continuously generates Idle control characters.

 

The RS inputs RXC[3:0] and RXD[31:0] are monitored by the state machine for Sequenced ordered_sets. The variable link_fault is set to indicate the value of a received Sequence ordered_set when four fault sequences containing the same fault value have been received with each pair of fault sequences separated by less than 128 columns and no intervening sequences of a different fault value.

 

�         Link_fault = OK

1.       No fault.

�         Link_fault = Local Fault

2.       Fault detected by the PHY.

�         Link_fault = Remote Fault

3.       Fault detection signaled bt the remote RS.

 

 

 

 
 

Architectural Description at Figure 10 illustrates the high level architecture of the XGMII Verification Component (eVC).

 

• The Frame Generator block converts raw data into frames to be sent using the XGMII protocol

 

• The Physical Tx block generates and transmits these frames across the DUT on the fly. Errors can be injected into the frames for transmission to verify the DUTs response to various error conditions

 

• The Physical Rx block collects data from the DUT and converts it into frames. Also, this block implements functionality to ensure that there are no protocol errors or timing violations in the received data.

 

•  The Frame monitor block converts packets from the Physical Rx block to raw data, which can then be compared with the expected data to create a self-checking

 

• The Coverage block collects coverage information of the generated input frames using cover structures. It can also collect implementation specific coverage information such as internal FSM coverage.

 

Pre and post transmission and reception hooks are provided to facilitate any other processing required by the testbench (such as hooking up scoreboards, predictors and checkers in the verification environment).