|HOME |ABOUT |ARTICLES |ACK |FEEDBACK |TOC |LINKS |BLOG |JOBS |


Tutorials



CHECKER


Protocol Checker



Protocol checking is the mechanism we use to verify IO buses functionality. Protocol checkers are created to validate whether or not the DUT is compliant with the bus protocol. It does this by checking the clock-by-clock state of the bus interface, verifying that the DUT drives the bus in accordance to the rules and specifications of the bus protocol. Protocol checker verifies that DUT adheres to the interface protocol and also verifies that the assumptions about the temporal behavior of your inputs is correct.

The Protocol checker is responsible for extracting signal information from the DUT and translating it into meaningful events and status information. This information is available to other components. It also supplies information needed for functional coverage. The Protocol checker should never rely on information collected by other components such as the BFM.

Typically, the buses that are checked are external buses and may be industry standard buses such as PCI, DDR, I2C or proprietary buses . Protocol checking may occur at a transaction or wire level. Protocol checker does not considered the data, as data has nothing to do with interface. The data processing protocol checking is done in data checker which is generally in scoreboard( or tracker) .

Protocol checks can be divided mainly into 3 categories:
1) Duration checks
2) Condition checks
3) Temporal or Sequence Checks.


Duration checks are the simplest since they involve a single signal. For example, the "req signal should be high for at least 3 clocks".

Data_checker



Data checker verifies the correctness of the device output. Data checking is based on comparing the output with the input. The data processing protocol checking is done in data checker which is generally in scoreboard( or tracker) . To do that you must:

--Collect the output data from the DUT and parse it.
--Match the output to its corresponding input.
--Forecast the DUT output by calculating the expected output.
--Compare the output to the input and to the expected results.



Modularization



One of the ways to reduce the amount of work is the ability to leverage components from one environment to the next. The concept of modularization is to break up a complex problem into manageable pieces, which has many benefits including increasing the quality, maintainability, and reusability of the environment.

In order to reuse components of one environment to another, it is important to separate functionality into specific entities. This separation allows the work to be distributed to multiple people. Task separation is very similar to and goes hand in hand with modularization. Another benefit of task separation is having different people understanding the functionality.




Index
Introduction
Linear Tb
File Io Tb
State Machine Based Tb
Task Based Tb
Self Checking Testbench
Verification Flow
Clock Generator
Simulation
Incremental Compilation
Store And Restore
Event Cycle Simulation
Time Scale And Precision
Stimulus Generation
System Function Random A Myth
Race Condition
Checker
Task And Function
Process Control
Disableing The Block
Watchdog
Compilation N Simulation Switchs
Debugging
About Code Coverage
Testing Stratigies
File Handling
Verilog Semaphore
Finding Testsenarious
Handling Testcase Files
Terimination
Error Injuction
Register Verification
Parameterised Macros
White Gray Black Box
Regression
Tips

Report a Bug or Comment on This section - Your input is what keeps Testbench.in improving with time!





<< PREVIOUS PAGE

TOP

NEXT PAGE >>

copyright © 2007-2017 :: all rights reserved www.testbench.in::Disclaimer