GMII eVC

GMII e Verification Component

IP Part Number: DR924-GMII-eVC

IEEE 802.3 compliant MAC layer to PHY layer interface

Targeted for an e Verification Environment
Modular, Extensible/Configurable and Reusable
Random Generators, Self-Checking, Error Injection
Straight Forward Integration
Compatible to Intrinsix GMII-SGMII Conversion Module

Applications

Ethernet Switches, Routers and transceivers operating at 10 Mb/s, 100 Mb/s and 1000 Mb/s

Overview

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

The GMII 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 core
Viewable interfaces, which can be extended easily
Coverage stats. for interface and implementation specific state machines

Port Signals
GMII eVC interface
Fields			Description
gmiiPorts			List of GMII eVCs
numFramesTx			Number of frames to send
numFramesRx			Number of frames received
framesReceived			List of frames received
numberOfFrame			Frame ID
lengthOfHead			Length of the head (in octets)
lengthOfTail			Length of the tail (in octets)
interFramePeriod			Delay between successive frames (either burst of single frame transmissions)
kindOfFrame			GOOD/BAD frame (request TX_ER assertion if kindOfFrame = BAD)
directionOfFrame			Tx or Rx
carrierExtendTx			Request PHY to transmit a Carrier Extend code-group
carrierExtendErrorTx			Request PHY to transmit a Carrier Extend Error code-group
burstTransmission			Request a burst transmission
preambleSize			Size of the preamble beginning the frame transmission. Defaults to 7
defautlPreambleCode			Default Preamble code (defaults to 0x55)
defaultCarrierExtendCode			Default carrier extend code (defaults to 0x0f)
defaultCarrierExtendErrorCode			Default carrier extend error code (defaults to 0x1f)
logEnable			Enable logging of messages
debugLevel			Debug level of messages
maxNumMessages			Max number of messages to output
messageMask			Bit field used for masking error messages
numFramesTxed			Number of frames already transmitted
frame			Frame which is being transmitted
frameAutoGen			Bit for auto-generating the fields in a frame object
gmii_loop_back			Bit for looping back the GMII side signals for stand alone test
Events			Description
collisionDetected			Rising edge of COL
carrierIndicate			Rising edge of CRS
gtxClk			Rising edge of GTX_CLK
txClk			Rising edge of TX_CLK
refClk			gtxClk or txClk depending on 1000 Mbps or 10/100 Mbps operation
rxClk			Rising edge of RX_CLK
frameReceived			Frame received
frameCheckErrorRx			RX_DV and RX_ER asserted or carrierExtendErrorRx
carrierExtendRx			RX_DV not asserted, RX_ER asserted and RXD = 0x0F
carrierExtendErrorRx			RX_DV not asserted, RX_ER asserted and RXD = 0x1F
falseCarrierRx			RX_DV not asserted, RX_ER asserted and RXD = 0x0E
dataReceptionErrorRx			Bad frame received (RX_ER asserted when RX_DV asserted)
frameStart			Start of frame transmission/reception
frameEnd			End of frame transmission/reception
txResetDone			Tx BFM reset done
rxResetDone			Rx BFM reset done
Methods			Description
printFrame()			Prints the contents of the frame struct
logMessage()			Outputs a message to stdout based on debugLevel
txReset()			TCM to reset the Tx BFM
preTxHook()			Hook method for any pre-transmission processing
postTxHook()			Hook method for any post-transmission processing
Port Signals
Fields			Description
txInvariant()			TCM to check for x�s and z�s on Tx
rxReset()			TCM to reset the Rx BFM
preRxHook()			Hook method for any pre-reception processing
PostRxHook()			Hook method for any post-reception processing
rxInvariant()			TCM to check for x�s and z�s on Rx

GMII DUT Interface
Signal Name	Direction	Clock Domain		Description
TXD[7:0]	Output	GTX_CLK		Gigabit Transmit Data: This is a group of 8 signals, which are driven synchronous to GTX_CLK. TXD7 is the most significant bit
TX_EN	Output	GTX_CLK		Transmit Enable: This signal is synchronous to GTX_CLK and provides precise framing for data carried on TXD7-0 for the external PMD. It is asserted when TXD7-0 contains valid data to be transmitted
TX_ER	Output	GTX_CLK		Transmit Error: This signal is synchronous to GTX_CLK and provides error indications and also is used for carrier extension and packet bursting functions
GTX_CLK	Input			GMII Transmit Clock: A continuous clock used for 1000 Mb/s. It is the reference clock for Transmit GMII signaling. The clock frequency is 125 MHz
TX_CLK	Input			Transmit Clock: A continuous clock used for MII application. The frequency is 25/2.5 MHz for 100/10 Mb/s operation.
COL	Input			Collision Detect: Asserted high to indicate detection of a collision condition (assertion of CRS due to simultaneous transmit and receive activity) in Half Duplex modes. This signal is not synchronous to either MII clock (GTX_CLK, TX_CLK or RX_CLK). This signal is not defined (LOW) for Full Duplex modes
RXD[7:0]	Input	RX_CLK		Gigabit Receive Data: This is a group of 8 signals, sourced from an external PMD, that contains data aligned on byte boundaries and are driven synchronous to RX_CLK. RXD7 is the most significant bit
RX_ER	Input	RX_CLK		Receive Error: Asserted high synchronously by the external PMD whenever it detects a media error
RX_DV	Input	RX_CLK		Receive Data Valid: This indicates that the external PMD is presenting recovered data on the RXD signals, and the RX_CLK is synchronous to the recovered. This signal encompasses the frame, starting with the SFD and excluding any EFD
RX_CLK	Input			Receive Clock: A continuous 125MHz clock, sourced by an external PMD device or recovered from the incoming data.
CRS	Input			Carrier Sense: Asserted high to indicate the presence of carrier due to receive or transmit activity in Half Duplex mode. For full Duplex operation CRS is asserted only for receive activity
SPEED	Input			Speed: Operational frequency specified as 2�b00 � 10 Mbps, 2�b01 � 100 Mbps, 2�b10 � 1000 Mbps, 2�b11 � reserved
TX_EVEN	Input			Parity: shows whether the current Txed code group is on even or odd numbered. It is being used to predict the correct numbers of bytes, which are transmitted crossed from the GMII side.

Architectural Description

Figure 3 shows the high level architecture of the GMII Verification Component (eVC). The GMII eVC is made up of a Frame Generator, a Frame Monitor, physical transmitters and receivers and coverage groups.

The Frame Generator block keeps track of the number of frames to be sent using the GMII protocol (implemented in DR924_gmiiFrameGenerator.e)

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

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 (implemented in DR924_gmiiPhysicalRx.e)

The Frame monitor block keeps track of the number of frames received, and stores them in a list. These frames can then be compared with the expected data to create a self-checking test (implemented in DR924_gmiiFrameCollector.)

The Coverage block collects cover information both for the interface and the implementation specific items such as state machines.

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.)

The GMII eVC can serve as the interface to a PHY layer device or a MAC layer device. The Rx and Tx clocks are inputs to the eVC, driven from either the RTL or a clock generator block in the test-bench and handled in e as events. For the configuration where the eVC acts as a PHY layer device, the test-bench supplies the Rx clock and the DUT supplies the Tx clock to the eVC (as shown in Figure 1). Likewise, when the eVC acts as a MAC layer device, the test-bench must supply the Tx clock and the RTL the Rx clock to the eVC.

Simulation Core

Intrinsix has developed a GMII to/from SGMII Conversion Core, which uses the SGMII and GMII eVCs for complete module level verification. The GMII to/from SGMII Conversion core is a Verilog component.