28-10-2016, 04:15 PM
[attachment=74134]
Abstract: Verification is the most important aspect of a design. An effective approach that requires less time is the need of the hour. There is a need to facilitate re use and randomize tests to save time and increase quality of testing. The Ethernet physical layer devices deal with the raw hardware and the higher level layers like MAC through Physical media attachment and media independent interface. Hence, there is a need for a robust automated verification process that can help in all kinds of traffic that the device can handle in all possible random ways. This paper describes the use of SystemVerilog as a language and UVM on top of it to facilitate a comprehensive verification supporting re use of code and the use of golden IP models. The entire test environment is created in UVM to achieve the above set goals.
Introduction:
This paper covers general aspects of verifying Ethernet protocol.
The paper is organized as follows,
• SystemVerilog
• Verification environment
• Design protocols being verified
The second section covers the significance of SystemVerilog as a verification language. The Third section describes the Verification Environment in general.
The Fourth section covers the design protocols being tested with the above environment and conclusions.
Initially, digital designs were verified by writing direct test benches and observing the waveforms as manual checks. As the complexities of the designs have increased, there is a need to automate this process. SystemVerilog language aids in automated verification. UVM (universal verification methodology) provides a standard & global format of achieving the same. Verification components are created such that they can be used from one project to another project and can be easily extended and improved without modifying the original code. The loose coupling between the design and the test enables Verification engineer to reuse tests and easily modify the components to their needs. These are possible with the various features of the language, like classes, cover groups and constraints, which aids in multiple aspects of verifying a digital design.
Issues with traditional verification:
• Tight bonding between the test bench and design.
• Complex test bench for complex designs.
• Lots of manual work in updating the test bench with updates in design
• Lack of automation & reusability for functional verification.
• Generation of all possible scenarios in directed tests is difficult and time consuming.
• Inefficiency in tracking the progress of verification for large designs.
• Manual process of checking results and debugging by waveforms.
• No reusability and requires time to analyze and eliminate duplicate tests.
• Coverage for all possible corner cases is impossible.
Verification Environment:
The stimulus is generated with the help of sequences to verify the DUT functionality. The block on which these sequences are started is called sequencer.
Sequencers are unaware of the communication bus, they are responsible for generating generic sequences of data and they pass that data to another block that takes care of the communication with the DUT called driver. This block feeds the high level Class details into another block called interface which converts the same into lower pin level details.
While the driver maintains activity with the DUT by feeding it the data generated from the sequencers, it doesn’t do any validation of the responses to the stimuli. We need another block that listens to the communication between the driver and the DUT and evaluates the responses from the DUT. This block is the monitor.
Monitors sample the inputs and the outputs of the DUT. A predictor predicts the expected result. Monitor and predictor send their output to another block called the scoreboard, where it is compared and validated.
All these components together form the UVM environment. Sequencers, drivers and monitors compose an agent. Agent and a scoreboard compose an environment. The test block controls all the blocks and sub blocks of the testbench. This means that just by changing a few lines of code, we could add, remove and override blocks in our testbench and build different test without rewriting a whole new test. This is possible with the OOPs support from SV.
Ethernet layers:
Ethernet technology is currently the most deployed technology for high-performance network environments. It is the most widely installed local area network (LAN) technology. It is a link protocol in the TCP/IP stack, describing how networked devices can format data for transmission to other network devices on the same network segment, and how to put that data out on the network connection. It touches both Layer 1 (the physical layer) and Layer 2 (the data link layer) on the OSI network protocol model.
Verification strategy:
The design has two sides, system and network with each of them having a transmit and receive block. Each side of the design has the chain of PMA PCS MAC blocks in TX & the reverse chain in RX. The chain joins the other side in the same pattern PMA PCS MAC – MAC PCS PMA. The same behavior is mimicked in the verification IP chain at both TX & RX ends. The DUT RX is connected to the VIP TX & vice versa.
Fig.2 Verification Environment
The VIP is an industry proven design of a similar chain and hence provides a reliable support in verifying the given design. Each block within the VIP has a separate driver and monitor which notifies in case of any error within the same. Before the normal operation of the DUT, all the blocks need to attain sync for which an idle set of data is sent along with the protocol headers. Both the DUT and the VIP need to acquire sync between their blocks before being scoreboarded for verification. The active monitor is the one that reads the data that is being driven into the DUT while the passive monitor reads the data coming out of the DUT. Once, they are in sync, the data out of these two blocks are scoreboard and validated.
When the DUT is transmitting data, it can be on all the four directions between the system and network side. Hence, the above set up is replicated in all the four directions. For example, when data traffic is in s2n direction, VIP on system side transmits corresponding to active monitor and DUT SYS side receives. DUT NW side transmits and VIP on network side receives corresponding to passive monitor.
The design supports multiple rates and paths. Hence, based on UVM phases, a separate base test is written for each of them where the basic verifications are done. The specific scenario to be tested is generated by a separate test which derives the above and performs the additional functions required to generate the scenario and check the result. The concept of UVM phases ensures the interdependencies of the blocks are taken care. Thus, without disturbing the base structure, the same can be used to generate any number of new tests by using the concept of inheritance. All the basic configurations are made in the base tests and hence are visible to all the tests deriving the same.
Alarm: There are scenarios which intend to drive defective data into the design that cannot be corrected by the FEC block. In such cases, the design generates alarm signals and propagates the same to the opposite side. The alarm signals are received by the VIP at the receiver which are verified by the event driven messages from the monitor. When the error scenario is active, all the corresponding monitors and scoreboards are switched off to avoid errors.
Force: The design has lots of internal registers, whose status get updated based on the scenario being generated. To verify the comprehensive combination of the same, the test signals are forced directly to the required value and after the requisite delay, the status registers are validated for the expected value.
Loopback: The design provides a debugging option called loopback. As the name suggests, it refers to the process of sending back the data to the source side. Looping the data back and score boarding the same, helps in identifying which part of the design is defective.
Conclusion:
This work presents an overview of the Universal Verification Methodology and SystemVerilog used for verifying the Ethernet protocol. By using this approach, we were able to meet all our stringent requirements for the verification of this complex protocol. This verification environment can be reused for the projects.
Abstract: Verification is the most important aspect of a design. An effective approach that requires less time is the need of the hour. There is a need to facilitate re use and randomize tests to save time and increase quality of testing. The Ethernet physical layer devices deal with the raw hardware and the higher level layers like MAC through Physical media attachment and media independent interface. Hence, there is a need for a robust automated verification process that can help in all kinds of traffic that the device can handle in all possible random ways. This paper describes the use of SystemVerilog as a language and UVM on top of it to facilitate a comprehensive verification supporting re use of code and the use of golden IP models. The entire test environment is created in UVM to achieve the above set goals.
Introduction:
This paper covers general aspects of verifying Ethernet protocol.
The paper is organized as follows,
• SystemVerilog
• Verification environment
• Design protocols being verified
The second section covers the significance of SystemVerilog as a verification language. The Third section describes the Verification Environment in general.
The Fourth section covers the design protocols being tested with the above environment and conclusions.
Initially, digital designs were verified by writing direct test benches and observing the waveforms as manual checks. As the complexities of the designs have increased, there is a need to automate this process. SystemVerilog language aids in automated verification. UVM (universal verification methodology) provides a standard & global format of achieving the same. Verification components are created such that they can be used from one project to another project and can be easily extended and improved without modifying the original code. The loose coupling between the design and the test enables Verification engineer to reuse tests and easily modify the components to their needs. These are possible with the various features of the language, like classes, cover groups and constraints, which aids in multiple aspects of verifying a digital design.
Issues with traditional verification:
• Tight bonding between the test bench and design.
• Complex test bench for complex designs.
• Lots of manual work in updating the test bench with updates in design
• Lack of automation & reusability for functional verification.
• Generation of all possible scenarios in directed tests is difficult and time consuming.
• Inefficiency in tracking the progress of verification for large designs.
• Manual process of checking results and debugging by waveforms.
• No reusability and requires time to analyze and eliminate duplicate tests.
• Coverage for all possible corner cases is impossible.
Verification Environment:
The stimulus is generated with the help of sequences to verify the DUT functionality. The block on which these sequences are started is called sequencer.
Sequencers are unaware of the communication bus, they are responsible for generating generic sequences of data and they pass that data to another block that takes care of the communication with the DUT called driver. This block feeds the high level Class details into another block called interface which converts the same into lower pin level details.
While the driver maintains activity with the DUT by feeding it the data generated from the sequencers, it doesn’t do any validation of the responses to the stimuli. We need another block that listens to the communication between the driver and the DUT and evaluates the responses from the DUT. This block is the monitor.
Monitors sample the inputs and the outputs of the DUT. A predictor predicts the expected result. Monitor and predictor send their output to another block called the scoreboard, where it is compared and validated.
All these components together form the UVM environment. Sequencers, drivers and monitors compose an agent. Agent and a scoreboard compose an environment. The test block controls all the blocks and sub blocks of the testbench. This means that just by changing a few lines of code, we could add, remove and override blocks in our testbench and build different test without rewriting a whole new test. This is possible with the OOPs support from SV.
Ethernet layers:
Ethernet technology is currently the most deployed technology for high-performance network environments. It is the most widely installed local area network (LAN) technology. It is a link protocol in the TCP/IP stack, describing how networked devices can format data for transmission to other network devices on the same network segment, and how to put that data out on the network connection. It touches both Layer 1 (the physical layer) and Layer 2 (the data link layer) on the OSI network protocol model.
Verification strategy:
The design has two sides, system and network with each of them having a transmit and receive block. Each side of the design has the chain of PMA PCS MAC blocks in TX & the reverse chain in RX. The chain joins the other side in the same pattern PMA PCS MAC – MAC PCS PMA. The same behavior is mimicked in the verification IP chain at both TX & RX ends. The DUT RX is connected to the VIP TX & vice versa.
Fig.2 Verification Environment
The VIP is an industry proven design of a similar chain and hence provides a reliable support in verifying the given design. Each block within the VIP has a separate driver and monitor which notifies in case of any error within the same. Before the normal operation of the DUT, all the blocks need to attain sync for which an idle set of data is sent along with the protocol headers. Both the DUT and the VIP need to acquire sync between their blocks before being scoreboarded for verification. The active monitor is the one that reads the data that is being driven into the DUT while the passive monitor reads the data coming out of the DUT. Once, they are in sync, the data out of these two blocks are scoreboard and validated.
When the DUT is transmitting data, it can be on all the four directions between the system and network side. Hence, the above set up is replicated in all the four directions. For example, when data traffic is in s2n direction, VIP on system side transmits corresponding to active monitor and DUT SYS side receives. DUT NW side transmits and VIP on network side receives corresponding to passive monitor.
The design supports multiple rates and paths. Hence, based on UVM phases, a separate base test is written for each of them where the basic verifications are done. The specific scenario to be tested is generated by a separate test which derives the above and performs the additional functions required to generate the scenario and check the result. The concept of UVM phases ensures the interdependencies of the blocks are taken care. Thus, without disturbing the base structure, the same can be used to generate any number of new tests by using the concept of inheritance. All the basic configurations are made in the base tests and hence are visible to all the tests deriving the same.
Alarm: There are scenarios which intend to drive defective data into the design that cannot be corrected by the FEC block. In such cases, the design generates alarm signals and propagates the same to the opposite side. The alarm signals are received by the VIP at the receiver which are verified by the event driven messages from the monitor. When the error scenario is active, all the corresponding monitors and scoreboards are switched off to avoid errors.
Force: The design has lots of internal registers, whose status get updated based on the scenario being generated. To verify the comprehensive combination of the same, the test signals are forced directly to the required value and after the requisite delay, the status registers are validated for the expected value.
Loopback: The design provides a debugging option called loopback. As the name suggests, it refers to the process of sending back the data to the source side. Looping the data back and score boarding the same, helps in identifying which part of the design is defective.
Conclusion:
This work presents an overview of the Universal Verification Methodology and SystemVerilog used for verifying the Ethernet protocol. By using this approach, we were able to meet all our stringent requirements for the verification of this complex protocol. This verification environment can be reused for the projects.