Using the design of an Ethernet (media access control) MAC as a sample, this case study will examine how complete verification can be done in an integrated and automated manner, saving time while improving quality. Two software tools will be highlighted that offer ease of use and thoroughness for users to verify an IP/SoC with certainty. The first creates tests for a variety of scenarios in a way that is more efficient and exhaustive than a pure constrained random methodology. The other forms a layer of abstraction around the IP/SoC from a specification.
ISequenceSpec™ (ISS) is used to create a specification of the sequences in the design. These sequences can be transformed into UVM sequences, firmware code, validation sequences, etc. from a common format. The UVM sequences generated by ISS can be imported into inFact™ from Mentor Graphics®. Next we show how to create exhaustive tests using these low level generated sequences using the inFact tool. As a sample we created a library of Ethernet sequences as follows:
Media Independent Interface Management (MIIM) module sequences (MIIM initialization and PHY access), Flow Control sequences (automatic, manual), Ethernet transmit packet sequences, Ethernet receive packet sequences, Ethernet initialization sequences (i.e., Ethernet controller initialization and Ethernet controller wake-up on ISR sequence). inFact is used to randomize these sequences and prove that the device will work in all practical scenarios.
THE HOLY GRAIL OF PORTABLE STIMULUS
Creating a single specification for testing a device and having it run on a variety of platforms is the Holy Grail which the current Portable Stimulus Working Group (PSWG) is seeking. As they say, there are a variety of ways to “skin a cat” (I’m against any animal cruelty but couldn’t resist using the phrase). inFact from Mentor Graphics provides a way to create the graph-based stimulus that works in a verification environment. This stimulus can be ported on to other platforms as well.
ISequenceSpec approaches the problem from a different perspective — one that starts from the specification of the registers and sequences. It can transform a specification into low level sequences. Such sequences understand and respect the target environment and are attuned for them. The tool uses an associated tool called IDesignSpec™ for specification of registers in the design.
This article describes our efforts to reap a higher level of productivity and quality by combining these two complementary tools. We use the ISequenceSpec tool suite for describing the low level sequences for the register memories in the addressable region of the design. These are then transformed into UVM sequences, firmware and sequences for other target domains.
THE ETHERNET MAC
A typical Ethernet controller provides the modules needed to implement an Ethernet node using an external PHY chip. In order to offload the CPU from moving packets of data to and from the module, typically an internal “descriptor based” DMA engine is included in the controller.
Typically the Ethernet controller consists of the following modules:
- Media Access Control (MAC) block: This module implements the MAC functions of the IEEE 802.3 specification.
- Flow Control Block: This module controls the transmission of PAUSE frames. Reception of PAUSE frames is handled within the MAC.
- RX Filter (RXF) Block: This module performs filtering on every receive packet to determine whether each packet is to be accepted or rejected.
- TX DMA/TX Buffer Management (BM) Engine: The TX DMA and TX BM engines perform data transfers from the system memory (using descriptor tables) to the MAC transmit interface.
- RX DMA/RX BM Engine: The RX DMA and RX BM engines transfer receive packets from the MAC to the system memory (using descriptor tables).
THE PROBLEM OF MIXING DIRECTED AND RANDOM SEQUENCES
Invariably hardware verification requires you to write directed sequences in some places and random sequences in others. The directed sequences come straight from the specification where the designer has ordained certain register bits to be set up in a certain way. Further, the order of programming the register fields is also directed. These sequences typically initialize and configure the device. They are described by the designer of the device in the programing manual or the datasheet.
On the other hand, a constrained random sequence is required in order to explore the entire state space. This is something that inFact can control. Not only can it generate the random sequences, it can also ensure that the proper coverage is achieved with as few simulation runs as possible.
The mix of the directed sequences as described in the datasheet and the constrained random sequences as required by the verification engineer are necessary in order to correctly configure and verify the device. Manually calling the directed sequences from inside the test sequences makes the environment very brittle. A small change in the specification will warrant a change in the test environment files. The focus of verification has to be on the constrained random sequences, assuming that the directed tests are correct by construction, or else the debug of constrained random sequences will become even more complex.
For example, within the Ethernet controller sequence ethInit, macInit, phyInit, and miimInit are all directed sequences, while the patternMatchRxFilter configures the filters in a variety of ways, and the txPacket sets up memory descriptors. There is a similar sequence for rxPacket. The details of the initialization sequences are in the specification document for the Ethernet controller.
THE SOLUTION WITH INFACT AND ISEQUENCESPEC
ISeqeunceSpec is used to create a library of sequences around the configurable aspect of the device. This forms the device’s hardware API for register and memory settings. These sequences are then “imported” into inFact as “action.”
Having a library of sequences available for creating the stimulus in inFact helps reduce the manual effort. It enables quick turn around and reduces the chance of errors in the tests themselves. The figure on the following page shows a graph created by inFact that creates the possible test scenarios with directed and random sequences.
Figure 1: Graph created by inFact with random and directed sequences
ISS generated sequences are “action” in inFact. For these actions, inFact generates virtual tasks, for example:
virtual task action_macInit();
// for macInit Sequence from ISS
virtual task action_mac(); virtual task action_macInit(); :
ISS generates the details of these tasks from the specification document. Now, all that is required to be done is “extend” the output sequence generated by inFact and include the ISS sequence library.
This article showed how to use directed and constrained random sequences to create a portable stimulus for an Ethernet controller. Using a combination of ISequenceSpec and inFact makes it possible to create a highly reusable, flexible and comprehensive verification environment.
Back to Top