Hi All,
How to check or increase the testbench correctness without DUT code ?
Should i write the behaviour model of DUT
In reply to peter:
You testbench is essentially a behavioral model of your DUT. If the same person writes the testbench and behavioral DUT, they will have the same bugs.
The key to improving the quality of your tests is having a clear set of requirements that are used to write the RTL and the tests, and have a test plan that maps out how you will test each requirement. Then using a combination of functional and formal coverage to track your progress.
In reply to dave_59:
A few points to add to Dave’s reply:
- Assertions: Use assertions in the interfaces that characterize the stimulus environment. For example, if the testbench wants to send, according to the transaction kind a normal WRITE of 8 words, with the 1st word being 00000 and the last word being FF00, and using a specific protocol, then that information can be passed (i.e., copied) to the interfaces. Assertions can then be used to check that this transaction is properly emitted by the testbench.
- For complex requirements, use tasks. See my paper:
PAPER: Understanding the SVA Engine + Simple alternate solutions | Verification Academy
Abstract: Understanding the engine behind SVA provides not only a better appreciation and limitations of SVA, but in some situations provide features that cannot be simply implemented with the current definition of SVA. This paper first explains, by example, how a relatively simple assertion example can be written without SVA with the use of SystemVerilog tasks; this provides the basis for understanding the concepts of multithreading and exit of threads upon a condition, such as an error in the assertion. The paper then provides examples that uses computational variables within threads; those variables can cause, in some cases, errors in SVA. The strictly emulation model with tasks solves this issue. - On using the interfaces tied to the class-type testbenches, see my White paper: “Using SVA for scoreboarding and TB designs”
http://systemverilog.us/papers/sva4scoreboarding.pdf
and a related issue at the Verification Academy the following paper
“Assertions Instead of FSMs/logic for Scoreboarding and Verification”
available in the verification-horizons October-2013-volume-9-issue-3
October 2013 | Volume 9, Issue 3 | Verification Academy
and SVA in a UVM Class-based Environment
SVA in a UVM Class-based Environment | Verification Horizons | Verification Academy - For transactions that are interactive, a high-level model of the DUT is needed.
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
For training, consulting, services: contact Home - My cvcblr
- SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
- A Pragmatic Approach to VMM Adoption 2006 ISBN 0-9705394-9-5
- Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004, ISBN 0-9705394-6-0
- Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 978-1539769712
- Component Design by Example ", 2001 ISBN 0-9705394-0-1
- VHDL Coding Styles and Methodologies, 2nd Edition, 1999 ISBN 0-7923-8474-1
- VHDL Answers to Frequently Asked Questions, 2nd Edition ISBN 0-7923-8115
I once wrote testbench to verify nvme controller , but we didn’t had the actual dut. So I verified it using nvme controller vip.
I am not sure what infra is available to you, but If possible u may try verifying your test bench against golden reference model of ur dut.
Thanks for your reply
In reply to absingh:
I once wrote testbench to verify nvme controller , but we didn’t had the actual dut. So I verified it using nvme controller vip.
I am not sure what infra is available to you, but If possible u may try verifying your test bench against golden reference model of ur dut.
can you explain what golden reference model is?