226 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.

11, November 2008

Reusable Verification Environment for verification of Ethernet packet

in Ethernet IP core, a verification strategy- an analysis
1 2 3
L.Swarna Jyothi Harish R Dr.A.S.Manjunath
1 2 3
Professor Verification engineer CEO and MD,
JSS Academy of Technical Education Manvish eTech Pvt Ltd
Bangalore, Research Scholar Bangalore
Dr.MGR University, Chennai,

Summary
Design reuse and verification reuse are important to satisfy time- 1. Introduction
to-market requirements. Designer must be able to reuse
Intellectual Property in the design as golden model. Reuse of Verification is a methodology used to demonstrate the
verification environment across different designs of the domain
functional correctness of a design. With automation
saves time to market further and improves total design
verification quality. The Physical Layer is a fundamental layer
human errors in a process are minimized. Automation
upon which all higher level functions in a network are based. takes human intervention completely out of the process [1,
However, due to the plethora of available hardware technologies 2, 3]. However, automation is not always possible,
with widely varying characteristics, this is perhaps the most especially in processes that are not well defined and
complex layer in the OSI architecture. The implementation of this continue to require human ingenuity and creativity, such as
layer is often termed Physical layer device (PHY). The Physical hardware design.
Layer defines the means of transmitting raw bits rather than
logical data packets over a physical link connecting network Another possibility is error due to human intervention by
nodes. A PHY chip is commonly found on Ethernet devices. Its
reducing it to simple and foolproof steps. Human
purpose is digital access of the modulated link and interface to
Ethernet Media Access Control (MAC) using media independent
intervention is needed only to decide on the particular
interface (MII) interface. This paper discusses Verification sequence or steps required to obtain the desired results. It
process, issues involved in verification process and Test is usually the last step toward complete automation of a
Methodologies. A broad outline of the comparison of traditional process. However, just like automation, it requires a well-
verilog and specman verification methodologies has been defined process with standard transformation steps. The
presented here. It also explains verification strategy and reuse of verification process remains an art that, to this day, does
design environment with reference to verifying the Ethernet not yield itself to well-defined steps.
packet in Ethernet Intellectual Property (IP) Core. Design Reuse
is achieved through verilog tasks which were used in specman
Choosing the common origin and reconvergence points
environment. Ethernet Phy e Verification component (eVC) is an
in house development. Ethernet eVC is built with phy as a
determines what is being verified. These origin and
separate eVC and host being a task driven verilog Bus functional reconvergence points are often determined by the tools
model (BFM). This allowed us to create a virtual host used to perform the verification. It is important to
environment using a combination of verilog BFM and eVC. understand where these points lie to know which
Verification environment reuse for different application with transformation is being verified.
different interface is done by developing a wrapper around the
Design Under Test (DUT) interface and then interfacing it to the The main purpose of functional verification [9] is to
environment. A detailed test plan is made for the complete and ensure that a design implements intended functionality.
exhaustive test for Ethernet MAC Receiver. Coverage goals, without functional verification, one must not trust that the
coverage obtained and coverage analysis indicate efficiency of
the verification methodology.
transformation of a specification document into design and
Register Transfer Logic (RTL) code was performed
correctly, without misinterpretation of the specifications.
Key Words:

Ethernet eVC, BFM, DUT, MAC, Verification, Reuse, Test

** This research is funded by All India Council for
methods, MDIO, Coverage
Technical Education under Research Promotion
Scheme

Manuscript received November 5, 2008

Manuscript revised November 20, 2008
IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008 227

Figure 1 shows an overview of the steps involved in Those components can then be used to verify multiple
verification of a design under test. entities which have a particular interface. eVCs are
verification components written in the e verification
Verification activity consists of driving vector stream into language [11]. The e language is designed specifically for
device and checking the vector stream coming out of the verification. Reuse and extensibility are fundamental e
device. Higher level languages [12] are needed, as High- language design principles.
level language eases the creation of an expected value
generator. Data check verifies the data correctness while The document is organized as follows: It discuss
temporal check verifies timing and protocol. Here the Verification process in Section 2, issues in verification in
shared objects are used for input stimulus. It supports Section 3, issues in verification methodologies in section 4,
cycle-based behavior, events, and synchronizes with HDL Test methodologies in section 5, Specman based
simulator. Verification in section 6 and Traditional verification based
methodology in section 7. Section 8 presents a detailed
case study with reference to a reusable Verification
Environment for verifying Ethernet packet in Ethernet IP
core. It discusses aspects such as, Management Data Input
Output (MDIO), Verification strategy, Macro language,
Test cases, Test Plan for Ethernet MAC receiver, Coverage
Goals and the Bug file. Finally, Section 9 presents the
conclusions drawn from the entire work.

2 Verification process

Test Test 1 Test 2 Testbase Test n-1 Test n

Plan

Collecting
Checking Output
Cover
Plan

Generating Driving DUT

Input Output
DUT
Spec

Coverage
Figure 1. Generalized Verification Flow

Figure 2. Generalized verification process

Verification planning is an important and integral part of
verification, irrespective of the size of the system. About Figure 2 show clearly the components used in test
70% of the design cycle time is spent on verification; with environment like test plan, coverage to be achieved,
proper verification planning some of the issues faced generation of test vectors and its driving to the DUT
during the later phases of design can be addressed earlier.
For SOC’s it is observed that most of the peripherals are
3. Issues in verification
reused [7] from the previous design step with some
modifications done on the feature set. Use of a pre-
configured and pre-verified suite of code and IP means that Issues to be addressed during any verification activity are
adaptation and subsequent re-verification of the code for • Capturing of all features of design (functional aspects).
specific applications is greatly eased [4, 5, 8]. The reuse of • Compliance to all protocols.
verification code and methodology is a major factor • Coverage for all possible corner cases.
providing significant reduction of the overall verification • Checking for locking states in the Finite State Machines
costs [6] One of the fundamental basics of design and (FSMs).
verification reuse is the standardization of interfaces [10]. • Working of design in any random state.
This has resulted in a number of interface and bus • Elimination of redundant tests to save unnecessary
protocols that are used to connect different entities simulation cycles and cost.
together. The logical conclusion for verification is to • Equivalence check with reference design.
organize testbench components around those interfaces.
228 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008

• Methodology availability, for verification of each design 5. Test Methodologies

modification.
• Generation of data patterns for directed or random test. Four prominent Test Methodologies are:
• Ease of generating flexible and modular test
environment 5.1 Deterministic
• Reusability and readability of test environment.
• Handling of simulation time in automated test The oldest and most common test methodology used
environment.
today is deterministic testing. These tests are developed
manually and normally correspond directly to the
4. Issues in Verification Methodologies functional test plan. Engineers often use deterministic tests
to exercise corner cases, specific sequences that cause the
Lack of effective automation during functional device to enter extreme operational modes. These tests are
verification due to size and complexity of design, makes normally checked manually. However, with some
development of test environment, scheme for test additional programming the designer can create self-
generation and deterministic tests an intensive manual checking deterministic tests.
effort. Checking and debugging test results is also
predominantly a manual process.
Although deterministic testing offers the verification
engineer precise control, providing accessibility to hard-to-
Design Complexity and size makes version control and
reach corner cases, it has several drawbacks. Generating
tracking of design and verification process difficult, both at
deterministic tests is a time-consuming, manual
specification level and functional, which can often lead to
programming effort. Although simple tests can be written
architectural-level bugs that require enormous effort to
in minutes, the more complex ones can take days to write
debug. Debugging is always a problem, especially when
and debug. For example, to test a corner case requiring that
they occur in unpredictable places. Even the most
two asynchronous data streams reach a specific point at
comprehensive functional test plan can completely miss
exactly the same time, the verification engineer might have
bugs generated by obscure functional combinations or
to resort to trial-and-error methods, running the test, seeing
ambiguous spec interpretations. This is why so many bugs
how far off it is, correcting it, and trying again. Moreover,
are found in emulation, or after first silicon is produced.
midstream changes to the design is temporal behavior can
Without the ability to make the specification itself
cause the engineer to go through this process repeatedly.
executable, there is really no way to ensure comprehensive
When this test is completed, the corner case is tested
functional coverage for the entire design intent.
through only one possible path.
The relative inefficiency with which today's verification
environments accommodate midstream specification An average project normally develops many hundreds of
changes also poses a serious problem. Since most deterministic tests, which is easily spread over several
verification environments are an ad hoc collection of HDL man-months to create. Checking deterministic tests also
code, C code, a variety of legacy software, and newly consumes considerable time and resources, whether it is
acquired point tools, a single change in the design can performed manually or written into the test.
force a ripple of required changes throughout the
environment, eating up time and adding substantial risk. 5.2 Pre-run generation

Perhaps the most important problem faced by design and Pre-run generation is a newer methodology for generating
verification engineers is the lack of effective metrics to tests that addresses some of the productivity problems
measure the progress of verification. Indirect metrics, such associated with deterministic testing by automating the test
as toggle testing or code coverage, indicate if all the flip- generation process. C or C++ programs (and sometimes
flops are toggled or all lines of code were executed, but even VHDL and Verilog, despite the lack of good software
they do not give any indication of what functionality was constructs) are usually used to create the tests prior to
verified. For example, they do not indicate if a processor simulation. The programs read in a parameter/directives
executed all possible combinations of consecutive file that controls the generation of the test. Often these files
instructions. There is simply no correspondence between contain simple weighting systems to direct the random
any of these metrics and coverage of the functional test selection of inputs.
plan. As a result, the verification engineer is never really
sure whether a sufficient amount of verification has been The generator normally outputs the test into a file, which
performed. is then read by the simulator and stored in memory. The
simulator reads the next entry whenever it is prepared to
IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008 229

inject the next set of inputs. Although pre-run generation model in C or C++. Stimuli are injected into the reference
provides much higher throughput than deterministic testing, model as well as the device, and their outputs are
it is difficult to control. The parameters are static and do compared. In gray and white-box methodologies, the
not provide much flexibility. Also, most generators of this comparisons also include the state of internal registers and
type do not allow interdependencies between data streams nodes.
if each data stream is generated independently. This can
cause the generator to generate unlikely or even illegal Rule-based approaches are more common in
tests. communication devices for networking applications, where
there can be several legal outputs for the same input, it is
Reaching corner cases using pre-run generation is nearly not easy to predict the correct result. In this case, the
impossible. The engineer has very little control over the engineer often uses specialized techniques to check data
sequences generated. This makes it difficult to force the integrity and protocols, such as scoreboarding, which
occurrence of specific combinations. As such, pre-run tracks information about cells or packets without worrying
generation makes a suitable complement to deterministic about the order in which they appear on the output ports.
testing, but cannot replace it.
Engineers perform these checks either on-the-fly or post-
Another problem with pre-run generation is that it is hard run. Simple checks and protocol checks can be performed
to maintain. As the verification process progresses, new on-the-fly by the stubs and monitors using an HDL. Post-
parameters are often needed. This normally requires run checks are often performed using a C/C++ or PERL
modifying the program, sometimes affecting delicate program. The outputs of the test are either saved in a
interdependencies between different parts of the generator. simulator memory and then dumped into a file, or written
into the file directly. The program reads the inputs ,
Maintenance problems can also occur when updating the outputs and checks the correctness of the results. Often,
program after a bug is found in the RTL design. To these methodologies still require some amount of manual
temporarily avoid generating the same bug test sequence checking, usually achieved by viewing actual waveforms
again, the engineer must modify the code until the bug is or data dumps.
fixed in the RTL design. When the bug is fixed, the code
must be again remodified. Several such modifications The problem with these checking strategies stems from
often coexist in the code. The modifying and remodiying the way they are most commonly implemented today.
process sometimes introduces bugs into the generator, Post-run checking wastes cycles. If a test runs for 500,000
which may not be noticed until several hours or days of cycles, but a bug occurred after cycle 2,000, then 498,000
simulation have transpired. The cost of developing and cycles were wasted. In addition, since the post-run
maintaining such a generator requires a minimum of checking cannot detect a problem in real-time, the designer
several man-months per project, and increases significantly does not have access to the values of the registers and
as the generation becomes more complex. memories of the device at the time the problem occured. In
general, debugging these problems requires rerunning the
A side-effect of this methodology is that the full test is simulation to the appropriate point.
usually very large, since it is generated in advance. It is
commonly loaded into a simulation memory at the On-the-fly checking is more powerful. However, on-the-
beginning of the test and run from there. This significantly fly checks are most often implemented in Verilog or
increases the memory requirements for simulation, often VHDL. These languages do not have a powerful temporal
causing the simulator to swap memory. This can slow language to simplify protocol checks. They are low level
down the simulation by orders of magnitude. and lack features like dynamic memory, which simplifies
the process of writing the stubs/monitors and increases
5.3 Checking Strategies performance.

The two most popular ways to determine test results are In addition, reference model checking is often hard to
to compare them to a reference model or to create rule- implement on-the-fly, since intermediate results are not
based checks. Both of these checking methods must always available. On-the-fly reference models also require
include both the temporal behavior and protocols of the a direct interface to the simulator (through PLI or FLI)
device as well as the verification of data. which is not easy to write and maintain.

Reference models are most common for processor-like 5.4 Coverage Metrics
designs where the correct result can be predicted with
relative ease. Designers usually develop the reference Measuring progress is one of the most important tasks in
230 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008

verification, and is the critical element that enables the

designer to decide when to end the verification effort. • Automates the verification process, reducing the work
Several methods are commonly used: needed to develop the verification environment and tests
considerably.
• Toggle testing verifies that over a series of tests, all • Increases product quality by focusing on verification
nodes toggled at least once from 1 to 0 and back; effort to areas of new functional coverage and by
• Code coverage demonstrates that, over a series of tests, enabling the discovery of bugs not anticipated in the
all the source lines were exercised. In many cases there functional test plan.
is also an indication as to whether branches in
conditional code were executed. Sometimes an Coverage Constraints
Constraints
indication of state-machine transitions is also available;
• Possibly the most common metric used to measure
progress is to track how many bugs are found each week.
Test case Driver Driver Test case
After a period of a few weeks with very low or zero generator / input DUT / input generator
bugs found, the designer assumes that the verification BFM BFM

process has reached a point of diminishing returns. Error injector Error injector
Collecto Collecto
r r
Unfortunately, none of the metrics described above has
any direct relation to the functionality of the device, nor is
there any correlation to common user applications. Neither
Monitor
Monitor
toggle testing nor code coverage can indicate if all the
types of cells in a communication chip with and without Score Board
Cyclic Redundancy Check (CRC) errors have entered on
all ports. These metrics cannot determine if all possible
sequences of the instructions in a row were tested in a Figure 3. Generalized Verification environment
processor.
• Provides functional coverage analysis capabilities to
As a result, coverage is still measured mainly by the gut help measure the progress and completeness of the
feeling of the verification manager, and eventually the verification effort.
decision to tape out is made by management without the
support of concrete qualitative data. Not knowing the real Raises the level of abstraction used to describe the
state of the verification progress causes verification environment and tests from the RTL level to the
engineers to perform many more simulations than specification level, capturing the rules defined in the specs
necessary, trading off CPU cycles for "confidence". This in a declarative form and automatically ensuring
usually results in redundant tests that provide no additional conformance to these rules.
coverage or assurance that verification is complete. The
real risk is that the design will be sent to production with Figure 3 gives a generalized verification environment
bugs in it, resulting in another round of silicon. The cost of which can be used as guideline environment for
re-spinning silicon includes non-recoverable engineering developing verification environment for most of the
(NRE) costs to do the additional production process, the designs. The environment consists of the components,
cost of extending the teams work on the project, and the Input BFM driver, Collector, Coverage, Test case
major cost of reaching the market a few weeks late. generator, Error injector, constraints, Scoreboard and
Monitor.
6. Specman based verification
7. Traditional Verification Methodology
Specman based verification is a methodology for
Some important points are:
functional verification that solves many of the problems of
design and verification engineers encountered with today's
7.1 Productivity & Quality Issues
methodologies. This is done by capturing the rules
embodied in the specifications (design/ interface/
Verification is more than 50% of an overall project cycle.
functional test plan) in an executable form. An effective
It May require tens of thousands of lines of verification
application of this methodology provides four essential
code. Design spec changes cause major verification delays.
capabilities to help to break through the verification
Implementing all identified tests in test plan within the
bottleneck.
project schedule is the Productivity issue.
IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008 231

7.2 Requirement for Productivity Improvement MDIO, Direct Memory Access (DMA) support,
Configuration registers, Control logic, Transmitter FSM
The verification environment must be created and/or and Receiver FSM.
maintained efficiently. Human should spend more time at
higher level details providing simulation goals, analyzing
errors reported by checkers and providing more direction
when goals are not being met. 8.1 MDIO
The MDIO is a simple serial interface between the host
and an external PHY device. It is used for configuration
7.3 Quality Issues and status read of the physical device. A host processor
responsible for system configuration and monitoring
Verification complexity makes it a challenge to think of all typically uses the MDIO to perform individual accesses to
possible failure scenarios. It does not provide a way to try the various PHY devices.
scenarios beyond the expected failure scenarios.
It implements the IEEE 802.3 Clause 22 standard MDIO
7.4 Requirement for Quality Improvement interface used in Ethernet systems up to 1Gbit/s. MDIO
Master core allows access to registers within multiple
Confidence about the ratio of identified bugs must connected Slaves. The features such as simple register
increase. An automatic way to know what has been tested based user application interface for the MDIO, MDIO
must be available. frame generation with serial port tristate control, busy
indication to user application during ongoing transaction
7.5 Task-based Strategy are provided. PHY interrupt goes active when status
change is indicated to application.
To improve test-writing productivity higher level of
abstraction is used for specifying the vector stream, and Host initiates an operation by writing into the
higher-level tasks are created in HDL or C. Task-based configuration registers of the MAC. MDIO reads these
strategy limitations are, high test writing effort, many registers and performs the tasks. It then reports it to the
parameters values must be selected manually and high - host by writing into the configuration registers which is
level intent is not readily apparent. polled by the Host continuously.
There is no need to buy new tools or licenses and it
provides homogeneous environment.
MAC

8. Case study:
HOST
Configur
A Verification Environment for verifying ation
MII/GMII

Ethernet packet in Ethernet IP core

PHY
MDIO
When verifying the Ethernet IP core it is necessary to
take several critical components into consideration. The MDIO

interfaces to the host as well as the PHY, which posed

extremely serious verification challenges. An automated
test bench, creating a verification environment takes time.
The time could be reduced by reusing common elements
between designs and different applications developments.
Figure 4. MDIO overview
In addition, as with many verification projects today, our
goals were to develop a high-quality device in an A mux is used for selecting 8 bit field of MDIO frame at
extremely tight time schedule. This section describes our a time and loading it to parallel in serial out register. The
approach to the verification of this complex device and PHY data is shifted out at the rising edge of PHY clock.
how we addressed the conflicting needs of quality versus The most significant bit of the data is shifted first. During
complexity versus time. a read cycle the data from PHY is shifted into the serial in
parallel out register and a demux drives it to the required
data bus.
The functional architecture consists of a host interface
and a standard MII interface. The IP core consists of
232 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008

The control block consists of counters which generates quickly as possible. The verification environment designed
enable signal for the functioning of mux, demux, SIPO and is shown figure 5.
PISO. It also generates the status signals to be written into
the configuration registers. It also generates the PHY Same components of the existing environment can be
enable signal to drive PHY data as the data line is a shared used for different application with different interface by
tri-stateable bus, which is driven by the MAC for write developing a wrapper around the DUT interface and then
transactions or by the PHY devices during read. interfacing it to the environment. Verification environment
consists of BFM, test case generator, monitor and checker.
The clock generator module generates Management Data
Clock by dividing host clock. The division factor is set in As with any commercial IP or SOC development with an
the configuration register field. aggressive timescale, the minimization of risk is key to
delivery. For many commercial developers the decision to
8.2 Verification strategy adopt a new verification paradigm can seem too risky.

Verification strategy for the Ethernet core was fairly The Specman Elite environment was built with the PHY
sophisticated. The design was very complex and the eVC and the host eVC with few verilog tasks. This
verification team was tasked with ensuring as high a allowed us to create a virtual host environment using e
quality device as possible. Also, the verification team had masters, slaves and bus arbitrators.
the requirement that the environment lend itself easily to
reuse for future generations, and that engineers who didn't
create the environment be able to be productive within it as
T A S K L IB R A R Y (G E N E R A L P U R P O S E )

T r a n s c a tio n C o v e ra g e D U T
G e n e ra to r

T e s tC a s e M a s te r
PCI BUS

IP C o re
G /T B F M

D a ta
G e n e ra to r P IB

M o n it o r

D a ta C h e c k e r
(S c o re B o a rd )

Figure 5. Verification environment

Specman Elite automated key aspects of the verification Just like an IP design core, this allowed time to be spent on
environment. Specifically, it works by generating stimuli verifying the unique aspects of the design rather than the
into the device, inputs which can be fully random or fully standard components.
directed. In this way, we can reach specific corner cases in
the design without having to force a specific state. We can 8.3. Macro language
generate the inputs pre-run, on the fly, or a combination of
the two.
One of the major objectives for the verification
environment was the ability for the non-Specman "savvy"
. An eVC is a reusable piece of verification code written in engineers to be able to easily use the environment to
e verification language with ERM (e reusable develop tests. We achieved this through “verilog tasks"
methodology) methodology. Specifically, the PHY eVC is that were built in a layered way using Specman Elite
a reusable verification environment developed in house.
IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008 233

macros. In fact, a huge number of the Ethernet verification displays a detailed plan for verification of MAC receiver
tests are sequences of code similar to the above. stages.

Through a constraint mechanism it was a simple matter to Scoreboard

direct the traffic to be of say one burst length. Different
frames and different configurations of the core were tested. PHY

The complete verification suite in the Specman Elite Phy Protocols

environment comprised more than 56 test cases and

Collector Receiver DUT BFM
randomization of the packet. This is an extremely small
amount of tests given the complexity of the design, and it
enabled us to get unparalleled coverage with a minimum
number of tests and lines of code.

Monitor
8.4 Test Cases

The test cases to check the functionality of the Ethernet

Mac Receiver according to specification are: Figure 6. Receiver environment

1. Check the Reset condition of Receiver by making the

RESET Bit 0 or 1 in RCB Block.
2. Check the Receiver Enable and Disable condition
(RECEN=1) Receiver Mode
3. Check the clock reception in case of Gigabit Media
Access Interface (GMII)/MII.
4. Check the transfer of MII to GMII mode and vice Non-
versa. Promiscuous
Promiscuous
State
5. Check for the GMII Mode. state
• Full Duplex Mode:
• Half Duplex Mode Figure 7. Modes of Receiver
6. Check for MII Mode:
• 10/100 Mbps (Full Duplex Mode)
• Half Duplex Mode: Ethernet MAC Mode
Configuration
5 Check behavior of Receiver for Promiscuous Mode Register(Bit79:78)
for the Different Frame reception. 00=10Mbps
01=100Mbps
6 Check the Successful Data reception. 10=1000Mbps
7 Check for end of Reception (Receive status)

8.5. Test Plan for the Ethernet MAC Receiver IN RCB Bit50

if '1' if '0'
Various Environment components used in the verification
of Receiver (Figure 6) are, Receiver DUT, BFM to drive Half Duplex Full Duplex
different types of frames and various Inputs to the DUT,
Monitor to monitor the various inputs and outputs of the Datawidth=4 bits from Phy Datawidth=8Bit from Phy
Receiver DUT, Collector to collect the data from output of
the DUT and Scoreboard to compare the data driven by the
BFM and the output of the DUT. Figures 7, 8, 10 to 12 Figure 8.Receiver for modes MII/GMII at different
display the details of configuration for test plan. Figure 9 speeds
234 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008

Physical layer side

Wait for Phy_Mac_Carrier_ sense

dont receive
receiver enable(bit52=1)
frames
yes

receives the preamble and SFD

and receiver valid becomes'1'

Check the DA and SA Field to mac client

Individual
Multicast Broadcast
Address
addressed field addressed field
Field

Check with Mac Address Field

RCB bit 49=0(length/type enable)

Discard Frame RCB bit 49=1(length/type disable) to mac client

Check Length/Type Field

if too short frame Data Frame Control Frame Too long frame VLAN

Check the
In Full Duplex Mode
Allignment of Length Error
Only
Octets

yes No

Match the Data octets Allignment

stores in RXRAM
with the Length Field Error

yes if full
to transmiiter no

Check FCS Length Error

if too short FCS Correct FCS error

frame

strip the Pad bits Received Ok Status

DA,SA

Length
Data

to mac client

Figure 12. Verification of different stages of the receiver

IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008 235

Data from Phy 8.6 Coverage Goals and Details

Coverage goals
Half Duplex Full duplex The line coverage to be achieved is 100%.
The condition coverage to be achieved is 85%.
The FSM coverage to be achieved is 100%.
If RXRAM Full
The toggle coverage to be achieved is 90%.
The average coverage to be achieved is 90%.
Half Duplex Full duplex

Coverage tools/methodology followed

VCS Coverage Metrics (vcm) is used for coverage.
frame discard Discard frame and RX-
and Coverage obtained
TX
indication to 1-Pause frame timer The line obtained is achieved is 100%.
Mac client value The condition obtained is achieved is 90%.
missing 2-Dest.Address The FSM obtained is achieved is 95%.
frame 3-request to send the The toggle obtained is achieved is 90%.
frame
Coverage Analysis
The average coverage achieved is 80%. Since Random
Figure 9. RXRAM Full condition at the time of reception
testing is not done, the coverage achieved is not close to
of Frame for Half/Full Duplex mode
100%. The offset is most in Condition Coverage and
Toggle coverage. This is expected as not all combinations
in a truth table will happen.

Team statistics : Team members – 2, No of man days – 82,

if Rx_err asserted
Coverage > 90%

with receiver valid without receiver valid

8.7 Bug File

discard frame False carrier
status:??? Indication =========================================
=======================================Bu
gNo:0 Block:RX Reported By:XXX Assigned
Figure 10. Collision Condition
To:YYY Status:CLOSED
==========================================
======================================Filed
If from Phy layer on:10:09 8 Mar 2008 Closed on:06:49 9 Mar 2008
Collision detected Resolved on: Title : Data frames greater than or equal
to 494 are not being recieved properlyDescription : For
before slot time
data frames greater than or equal to 494 are not being
recieved. The testcase is hanging. rx_ok is not coming
for either of the frames.Logfile : Dumpfile :
/export/home/sd27347/GBETHERNET/testbench/stand_al
Late collision and one/rx/simulation/run/rx_failing.shmFiles Modified :no
discard frame
discard frame
files Comments :error in testbench and not in dut
==========================================
Figure 11. Rx Error from Phy Side ======================================Bug
No:1 Block:RX Reported By:XXX Assigned
To:YYY Status:CLOSED
==========================================
======================================Filed
on:02:38 9 Mar 2008 Closed on:09:00 9 Mar 2008
236 IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008

Resolved on: Title : data length greater than 1496 is References

reported as frame long error .same as for tagged
frameDescription : Frame long error is [1] Janick Bergeon ,Writing test benches – functional
coming for data frame length greater than 1496, it should verification of HDL models
only come for 1500 for untagged and for tagged it is [2] Faisal I Haque. Et.al., The art of verification with
1504.Logfile : Dumpfile : Files Modified :fdb.v VERA
Comments :total cnt was checked for 1504 for untagged [3] Samir Palnitkar, Design verification with e
frames and 1508 for tagged frames and earlier we were [4] Brendan Mullane and Ciaran MacNamee, Circuits and
checking for 1500 for both the cases System Research Centre (CSRC), University of
========================================== Limerick, Limerick, Ireland, Developing a Reusable IP
======================================Bug Platform within a System-on-Chip Design Framework
No:2 Block:rx Reported By:XXX Assigned To:YYY targeted towards an Academic R&D Environment
Status:CLOSED www.design-reuse.com/.
========================================== [5] Ben Chen, , Cisco Systems, Shankar Hemmady,
======================================Filed Rebecca Lipon of Synopsys, Verification IP reuse for
on:03:42 17 Mar 2008 Closed on:05:09 20 Mar 2008 complex networking ASICs- eetindia.com
Resolved on: Title : receiver is having the delay to give [6] 0. Petlin, A. Genusov, ASIC Alliance Corporation,
rx_ok in case of short frameDescription :In case of Short L.Wakeman, Lucent Technologies, Methodology and
frame reception, there is delay to get rx_ok, and this delay Code Reuse in the verification of telecommunication
is depending upon the number of padding bytes in the SOCs, Proceedings of 13th Annual IEEE International
frame. <enter detailed description of the bug ASIC/SOC Conference, 2000 (Cat. No.00TH8541)
here>Logfile : Dumpfile : Files Modified :fdb.v Verification Planning for Core based Designs
Comments :added a condition in fcs state "padded bytes [7] Anjali Vishwanath, Ranga Kadambi, Infineon
are not counted with total cnt so min frame size 50 is Technologies Asia Pacific Pte Ltd Singapore
taken" [8] Kambiz Khalilian, Stephen Brain, Richard Tuck,
========================================== Glenn
====================================== Farrall, Infineon Technologies Reusable Verification
Infrastructure for A Processor Platform to deliver fast
9. CONCLUSION SOC development, www.design-reuse.com/.
[9] Managing Functional Verification Projects
Using a new verification methodology can appear Meeting the challenges of high-level verification in
daunting as it represents such a critical high-impact part of today’s SoCs- Synopsys white paper-Oct 2007
any IP development. The Ethernet project demonstrates [10] Hannes Froehlich, Verisity Design, Increased
that when facing a tough verification challenge, teams that Verification Productivity through extensive Reuse,
take the challenge often find that the risks are in fact Design and Reuse, Industry articles.
manageable and the benefits are significant. By using this [11] Verification Reuse Methodology, Essential Elements
approach , we were able to meet all our stringent for Verification Productivity Gains- Verisity white
requirements for the verification of this complex system. papers-2002
The extensibility of the e language, the macro facility and [12] Accllera verilog LRM:
the power of Specman Elite's built-in generator were key http://www.accellera.org/home
elements that enabled this approach to be successful in
short duration and smaller team effort compared to doing
the same using complete verilog environment.

Acknowledgements

We thank Dr.S.Ravi, Professor and Head of ECE

department, Dr.MGR Research and Educational Institute
for the paper review. We also thank All India Council for
Technical education for research funding and JSS
Academy of Technical Education, Bangalore for providing
the facilities. We Thank Ms. Chaya Asst. Professor,
JSSATE for editing the script.
IJCSNS International Journal of Computer Science and Network Security, VOL.8 No.11, November 2008 237

Ms.L.Swarna jyothi is working currently as a Professor Mr. Harish has 13 years of experience in reputed
of Information Science and Engg Department at JSS industries, out of which 8 years in
Academy of Technical Education, Bangalore Visvesvaraya ASIC/VLSI/Verification/Testing/Design Involving
Technological University, INDIA. She has a total of ASICs, Models, and SoCs. He has experience in test plan
25years of academic experience. Her research interests are development, environment development, test cases
assertion-based verification, design for verification, implementation, models development, random testing and
verification reuse and VLSI Education. She has six reputed coverage. His Verification Experience include Hyper
conference Publications in the related field. Her research Transport Tunnel/Cave, Controller Area Network (CAN),
has been funded by All India Council for Technical PCIe, GB Ethernet, Flexray. He has expertism in Verilog,
Education under Research Promotion scheme. She has Specman e, ESEPro. VCS, Ncsim, Verilog-XL and
already coordinated three projects sanctioned by AICTE Specview..His education includes Bachelor of engineering
and project grants are about 30 lakhs. She has received her in Telecommunications and Master of Business
Bachelors Degree in Engineering in Electronics and Management from Bangalore University, Bangalore.
Communication Engg from Bangalore University and Hereceived his MS (Software Systems) Degree from BITS,
Masters Degree in Engineering in Comp Sc and Engg Pilani, India
from Anna University, Chennai, INDIA. She is pursuing
her PhD in Dr.MGR Research and Educational Institute, Dr.A.S. Manjunath is the Managing Director and CEO of
Chennai Manvish eTech Pvt, Ltd, Bangalore, INDIA. He has been a
successful entrepreneur for over 12 years. He has done his
PhD and UG degrees are from Bangalore University. His
Masters Degree is form Mysore University India. He has
worked as Professor and as an academician for over 13
years, in Bagalore University, India. He is guiding three
PhD scholars and has 22 conference/journal papers to his
credit.