Resources Highlights

Introduction

Verification methodologies have evolved over the years from a simple HDL task-based methodology to a complete verification automation system. With designs today reaching a few million gates, verification automation systems are now required to maximize productivity of the verification process. “e” provides dynamic inheritance that allows the environment to be built in an object oriented manner. e has constructs for constraint-driven generation, temporal language, and functional coverage. These constructs help the engineer quickly build various components in the environment. e automates the generation of stimuli.

e allows the drivers in a verification environment to be created in an object oriented manner. This allows maximum reusability.

Interface with the simulator (Verilog, HDL simulator).Coordinate all procedural code that drives the DUT. Conform to input protocol for DUT. Convert abstract data structures into a list of bits. Drive the bits onto the DUT.

Wireless USB Verification methodology using Spec man, provides various test scenarios in verifying the functionalities of DUT as well as the WUSB protocol, ECMA 369 standards, AES-128 Standard protocols.

Verification Plan

A verification plan is required to describe what is to be verified and how it will be verified. It should address the three aspects of verification: coverage measurement, stimulus generation, and response checking. The verification environment will be developed in e.

Data Object (Stimulus Generation)

The generation component of verification uses data objects for stimulus generation. These data objects are structs that represent the abstract form of input stimulus. This struct is the basic form of stimulus.

Driver Object (Stimulus Driver)

The driver object performs the function of taking the stimulus data objects one at a time and applying them to the DUT until all stimuli has been applied. Typically, the driver object is similar to an HDL bus functional model.

Receiver Object (Output Receiver)

The receiver object is responsible for collecting the data at output of the DUT. The receiver object performs the function of taking the raw output data from the DUT based on the output protocol and converting the data to an abstract object for comparison. Typically, the receiver object is similar to an HDL bus functional model.

Data Checker Object (Expected Value Comparison)

The data_checker object stores expected values for each input data object injected into the DUT. When the receiver object receives one data object, it passes it to the data_checker for comparison against the expected values.

Monitor Object (Protocol Checker)

A monitor object checks the input and output timing protocol. Various protocol checks are included in this unit.

Coverage Object (DUT and e Coverage)

A coverage object sets up coverage tracking on key items in the e code and in the DUT. Some coverage objects can also be embedded in the extension to a driver or receiver object.

WUSB Device Controller Verification Test Plan:

 

  • Generator
    • Test vectors are generated based on the constraints provided.
    • Stimulus generator is defined as a struct.
    • Consists of methods & data fields together known as struct members.
    • The fields within struct can be further divided into Physical & Virtual fields.
    • The generation component of verification uses data objects for stimulus generation. These data objects are structs that represent the abstract form of input stimulus.
    • Fields which are having specific significance in DUT are Physical Fields.
    • Fields which are used for the controllability and debugging are Virtual fields.
    • Some Physical fields are soft constrained and some are directed constrained.
    • Where as frame data payload is a random generator constrained as per frame length either in generator or test cases.
    • In general output of generator is Object Oriented data.
  • Examples of such Physical fields defined in the Generator block:
    • 15 bytes MAC-PHY header.
    • 1 byte Header Error.
    • 12 bytes Security header.
    • 2 bytes WUSB header.
    • 8 bytes MIC.
    • 4 byte FCS.
    • 3 byte RSSI + LQI + Rx Error.
  • Driver
    • The driver object performs the function of taking the stimulus data objects one at a time and applying them to the DUT.
    • Interface with the simulator (NC-Verilog).
    • Coordinate all procedural code that drives the DUT.
    • Conform to input protocol for DUT.
    • Convert abstract data structures into a list of bits.
    • Drive the bits onto the DUT.
  • DUT
  • Coverage
    • A unit may be defined to represent a coverage object.
    • A coverage object defines a set of basic, transition, and cross coverage items to monitor upon specific events in the simulation.
    • Coverage statistics are gathered in the coverage object during simulation.
  • Protocol Checker
    • A unit may be defined to represent a protocol checker object.
    • Protocol checkers are monitors built using temporal assertions.
    • The protocol checker object normally contains a set of rules that monitor the protocol at all important input and output interfaces.
    • If the protocol is violated, the protocol checker issues a warning or an error.
    • The declarative syntax of e makes it really simple to write these protocol checkers.
  • Data Checker
    • A unit is defined to represent a data checker object.
    • The data checker object gets an output data object from the receiver and compares it against the expected data.
    • The data checker has a procedure to generate and store the expected data object.

Wireless USB Verification Goals

  • Verify WUSB, ECMA 369, ECMA 368 Standard protocol.
  • Verify Device Enumeration process.
  • Verify all control, bulk, isochronous and interrupt transfers.
  • Verify Timing Synchronization between Host and Device.
  • Verify Data burst Synchronization between Host and Device.

Implemented Verification Methodology

GeneratorGenerator wusb_device_gen.e comprises following structs for the following:

  • PHY Header.
  • MAC Header.
  • Header Error.
  • Security Header.
  • WUSB Header.
  • Application Payload.
  • MIC.
  • FCS.
  • PHY related 3 bytes.

All struct members are the WUSB spec derivatives and are virtual in nature. Also comprises of various MMC scenarios, data payloads.

Driver
Driver wusb_device_driver.e comprises Time Consuming Methods for generation of various frame scenarios suggested by WUSB protocol.

Test Case
Test case comprises all the extended Structs of Generator where in all the virtual fields will be fed by the Test Engineer to verify DUT in either of positive and negative scenarios of protocol.

Summary

Existing Wireless USB verification environment using Spec man provides the test engineer fullest possibility in verifying the WUSB end device functionalities, WUSB protocol rules, ECMA 369 and AES 128 standards, device enumeration process comprising four way handshaking, device authentication, Data transfers like (Control, Bulk OUT, Bulk IN). Also ramping advancements will occur there after in the entire environment for highly automated system giving the user or the test engineer to verify the look and corner test cases.

Feedback
If you have any suggestion/feedback please email it to [email protected]