ABSTRACT of this Paper To develop a reusable and

ABSTRACTAs the complexityand size of SoC design develop, an efficient and structured verificationenvironment is becoming more important than ever before.

It is because manyengineers with different knowledge and skills are involved in SoC verification,and they have to deal with different aspects of verification. This paper looksover the diversity of SoC verification and suggests a practical applicationmethod of UVM (Universal Verification Methodology) to build an efficient andstructured verification environment which meets various requirements of SoCverification. This paper shows standardized and well-organized testbencharchitecture that includes directory structure of testbench files, andmechanism such as interface and handles across the components.

The proposed UVMapplication method helps testbench developers maintain consistency oftestbenches and reduce the quality gap among verification works that are doneby multiple verification engineers, by using standardized testbench. It ensuresthat IP verification engineers do their job independently and the testbenchescan be reused in top level verification environment. In addition, it provides agood infrastructure to hardware designers, who have little knowledge aboutverification languages and methodologies, and who want to write directed testcases only.

The proposed method has been validated with a set of referencetestbenches developed for an application processor SoC. Keywords:Test bench, DUV, Efficient, Verification,Reuse1.        INTRODUCTIONMainobjectives of this PaperTodevelop a  reusable and efficientverification IP for gigabit Ethernet. Constrained random stimulus generation.

Coveragedriven verification with features of Reusability, Modularity and Scalability.Clocking Blocks are Changed from Previous Testbench to this testbench. MAC andPHY can verify using single efficient testbench so that no need to develop aseparate test  bench for each.2.     EFFICIENT VERIFICATION TESTBENCHFOR MAC AND PHY2.

1    Test bench Verification EnvironmentETHERNET MAC consists of verification components like agent, driver, monitor, scoreboard,Virtual Sequencer / Sequence, Environment, Test, Top etc. Data item: Represents the input to the device under Verification(DUV). Ethernet protocol specification gives clarity on valid attributes andvalues for Ethernet data packet. Generally data items are transmitted andgenerated to the DUV in a typical test. A large number of meaningful tests canbe created by randomizing data item fields using SystemVerilog constraints thusmaximizing coverage.Driver: is an active component that mimics logic that drives theDUV.

It Fetches data repeatedly from sequencer, drives the DUT based on theprotocol using the virtual interface.The items that are provided for execution to the driver iscontrolled by the advanced stimulus generator called sequencer. The sequencescannot directly access testbench resources, which are available in thecomponent hierarchy. Using a sequencer, sequences can access testbenchresources as a key into the component hierarchy.

Upon the request from thedriver, random data will be generated by the sequencer which controls thedistribution of randomized values by allowing us to add constraints in the dataitem class.Monitor: extracts signal information from the bus and translates itinto transactions. Monitor is connected to other components via standard TLMinterfaces like Analysis port and export.Agent: there are three specific components viz: sequencer, driver,and monitor. They can be reused independently.

 The driver, sequencer, and monitor are encapsulated by the agent.Verification environment can contain multiple number of agents.  ETHERNET MAC has two agents: transmit andreceive agent.Scoreboard: is an analysis component that checks whether the DUT isbehaving properly or not. Its function is to verify the proper action of thedesign at functional level by comparing the predicted output from referencemodel with the actual output from receiver.Environment: acts as the top-level component for all theverification components. Environment, in addition to the agents, consists ofscoreboard, coverage collectors and other analysis components Interface: is a static component that encapsulates communicationbetween the hardware blocks. It provides a mechanism to group together multiplesignals into a single unit that can be passed around the design hierarchy thusreducing the amount of code and promotes reuse.

It is easy to maintain sincesignals can be added or removed easily. Interface ports work exactly like themodule ports. When the interface is instantiated, the connection of the portlist can be done externally either by using order based or name based mapping8. In the port list, only those signals are mentioned whose directionis same for both DUT and testbench like clock signal. But for the rest of thesignals, instead of port list we need to specify the directions with the helpof a modport. Based on the declared directions, Modport restricts the interfaceaccess within a module.The function of the clocking block is to identify the clock signalsand to capture the synchronization and timing requirements of the modeledblocks. Signals synchronous to a particular clock are assembled by a clockingblock thus making their timing explicit and avoiding race around condition.

With the help of the clocking block, testbench drives the signals on time.Interface can contain more than one clocking block depending on theenvironment. Set up and hold time of the DUV can also be modeled 9. Since Interface is static in nature and TB environment is dynamic,it is not possible to instantiate static interface in dynamic class objects.Virtual interface instance is created by using keyword “virtual”. By means ofvirtual interface drivers and monitors can be created and deleted dynamicallyduring run time.

Figure 1: A uniqueTest Bench for SoC 2.2    Test Cases To check the functionality of the ETHERNETaccording to the specification the scenarios which have been covered are as follows-Receive Enable, Receive available, Valid data (Tx and Rx), Start of packet (Txand Rx), End of packet (Tx and Rx), Modulus length (Tx and Rx), Packets data(Txand Rx), Receive error and Transmit full.2.

3    Test reuse componentsAn environmentblock-level can be reused at the integration of block-level environments 2. Somevirtual sequences of block-level can be reused at block-level as integrationtests. The sequences can be reusable using efficient verification test bench.

3.      DESCRIPTION OF MAC and PHY BLOCKS: The two basicbuilding blocks in Ethernet are MAC (controller) and PHY (transceiver). TheMAC-PHY interface comprises of two signal groups; a data bus and a managementbus and is known as XGMII (Ten Gigabit Media Independent Interface). The XGMIIis specified in clause 49 of the IEEE 802 .

3 standard. This interface isindependent of processor and physical media (copper or fibre), providing bothsimplicity and interoperability.Ten Gigabitmedia-independent interface (XGMII) is a standard which is defined in IEEE802.3 for connecting full duplex Ten Gigabit Ethernet (10GbE) ports with eachother and for other electronic devices on printed circuit board (PCB). Figure 3: BlockDiagram of 10GEMAC10GEMAChas three major modules: Transmit engine, Receive engine and XGMII.The TX EnqueueEngine receives the frames and stores them in the transmit FIFO in addition tosome additional flags like Start of Packet and End of Packet indicators. FIFOfill status is provided to the core by this Tx engine.In the RX EnqueueEngine, the Reconciliation layer monitors the XGMII interface for faultcondition detection and passes the status for checking.

XGMII Tx Control:On 64-bit interface, each bit corresponds to a byte. High status signifies thatthe byte is a control character and low status indicates that data is carriedout by the byte.XGMII Tx Data:While interfacing with 32-bit devices, xgmii_txd31:0 is mapped to thepositive edge of the clock and xgmii_txd63:32 is mapped to the negative edge.

XGMII Rx Control:On 64-bit interface, each bit corresponds to a byte. High Status Signifies thatthe byte is a control character and low status indicates that data is carriedout by the byte.XGMII Rx Data:While interfaced with 32-bit devices, xgmii_rxd31:0 is mapped to the positiveedge of the clock and xgmii_rxd63:32 is mapped to the nagative edge. Figure showsloopback module provides a mechanism to verify the functionality of the MAC andPHY during simulation. When local loopback is enabled, the Ethernet loopbackmodule takes the transmit frame from the MAC XGMII TX and loops it back to theMAC XGMII RX data path 6.In accordance withthe IEEE 802.3 Clause 46 Ethernet standard, transmitting frames on SDR XGMIIinterface, MAC Tx ensures the followingAligns the firstbyte of the frame to either lane 0 or lane 4 of the interface.

Performs endianconversion. Client Transmit the frames to the interface are in big endianformat. Frames transmitted on SDR XGMII are in the form of little endian. TheMAC Tx transmits frame on this interface from LSB (least significant byte). The MAC RXreceives Ethernet frame from SDR XGMII Interface and forwards the payload withrelevant frame information to the client after checking and filtering invalidframes in Rx data path.

Data lanes coming through the SDR XGMII are decoded byMAC RX. First byte of the receive frame should received either in lane 0 (mostsignificant byte) or lane 4, as expected by MAC Rx. The Rx frame should bepreceded by a column of idle bytes or by an ordered set. Rx frame which doesnot satisfy this condition is invalid and the corresponding frame is dropped byMAC Rx. After this, the sequence of the frame is checked by MAC Rx. The framebegins with 1-byte START, 6-byte preamble data and 1-byte Start Frame Delimiter(SFD). Otherwise, MAC RX considers the frame as invalid and drops iteventually.

For all valid frames, MAC RX removes the START, preamble data,Start Frame Delimiter (SFD) and End Frame Delimiter (EFD) bytes ensuring thatthe first byte of the frame is aligned to byte 0. End Frame Delimiter isremoved by MAC Rx for all valid frames ensuring that the first byte of theframe is aligned to byte 0.The PCS block isresponsible for implementing all functions of the Physical Coding Sublayer asdefined in the IEEE802.3ae. It is divided into two major sub-blocks namelyxgxs_pcs_tx and xgxs_pcs_rx. The PCSsits between the PMA and the XGMII (RS or PHY).

In order to verifyand evaluate the performance of the MAC and PHY RTL and the gate-level netlist, UVM verification environment has been set up. Apart from the traditionalverification methods such as timing check by assertions, a reusable frameworkto obtain functional and code coverage and constrained random data generationhas been implemented here.Transferring largeamounts of data across a network quickly: All the variables in the transactionclass are randomized in generator class. The Generator generates the randomizeddata to be send to the driver through mailbox.

From the driver, data has to bedriven to DUV via interface as well as to the reference model with the help ofthe mailbox. Again monitor receives data from DUV via interface and it sendsdata to scoreboard through mailbox. In the entire testbench environment, largeamount of data have been transferred continuously through transactors with thehelp of mailboxes.Constrained randomstimulus generation: Random values generated by the simulator have been used inthe code. But, we have added constraints for some variables to preventsimulator to generate any meaningless values. Thus, making the stimulus arelevant one.constraint a{   mod inside {0:7};   }          constraint b {foreach (datai)  datai inside {0:512};  }Coverage drivenverification: We have made a separate class for coverage. In which we havedeclared one covergroup model which includes various coverpoints and binsrelated to the variables declared in the transaction class.

The coverage reportis automatically generated by the simulator when we executed the code.Reusability andModularity:  Four testcases have beenexecuted on the developed  test-bench environment, thus making the codereusable. These test cases can be executed just by running commands from makefile without making any changes  in the test bench.Scalability:  TB Modules have been developed using UVMmethodology to achieve sufficient scalability so that those can be used throughmultiple levels and across various projects. 4.

     COVERAGE REPORTS ANDSIMULATION RESULTS  Figures.Represents the simulation result as viewed by usingmentor graphics Questa tool. It displays transmitted data from the transmitengine to the XGMII receiver then it retransmit to the MAC through receiverengine while it receives the data from the XGMII transmitter.  From Simulation waveform we can observe thattransmitted packets have been    received in the receiver side as per our expectation following thespecification. Fromthe above figure. Represents the simulation result viewed by using mentorgraphics Questa tool. It displays transmitted data from the XGMII through thePCS to the PMA receiver then it retransmit to the XGMII through PCS. FromSimulation waveform we can observe that transmitted packets have been receivedin the receiver side as per our expectation following the specification.

ConclusionThespecifications of System on Chip (SoC) are verified successfully usingEfficient methodology on Cadence simulator. The verification methodology helpedin performance improvement and simulation time reduction in SoC verificationtime from previous methodology (i.e 4.68 sec to 1.08sec).

Verification is verycrucial to find bugs which only appear with random stimulus. The constrainedrandom approach is more time-efficient for reaching coverage goal compared todirected test method.