I want to get a clear picture about black box vs white box assertions. How are they different? I am told that verification engineers write black box assertions. Does it mean that the verification engineers are only refering to the specification sheet and the waveforms to write the assertions? Are they not looking at the DUT?
I’m Sorry if my question is vaugue. I am confused about these two names.
Thank You.
In reply to Ramakrishna Melgiri:
I want to get a clear picture about black box vs white box assertions. How are they different? I am told that verification engineers write black box assertions. Does it mean that the verification engineers are only refering to the specification sheet and the waveforms to write the assertions? Are they not looking at the DUT?
I’m Sorry if my question is vage. I am confused about these two names.
Thank You.
You are correct:
- **Black box:**Here, the verification is based on the requirements of the design. Thus, anything external to the design and the performance of the design in terms of requirements must be verified. In terms of assertions, that would mean the interfaces and responses. They can also include assumptions if the configurations are fixed. They may also include coverage about important test cases with reference to the requirements. The implementation of the design is not considered. These assertions are typically written by a verification engr, and not by the designer. They can, and should be done prior to the actual design tasks.
- White box: That deals with the actual implementation. Typically, a designer may add information about assumptions, and assertions about expected results particular about the design. For example, if the design uses a FIFO, it would be good to add assertions about the FIFO never reading a value when it’s empty, or push data when full. If the design has an EDAC, assertions should be added that the EDAC is indeed performing its duties. These assertions are typically written by the design engr, and they are important.
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
- SVA Handbook 4th Edition, 2016 ISBN 978-1518681448
// For 10% discount, use code 45KJT5GN @ https://www.createspace.com/5810350 - 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 0-9705394-2-8
- 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
In reply to ben@SystemVerilog.us:
What happens with the inputs and outputs when we black box a module?
In reply to ankit1312:
What happens with the inputs and outputs when we black box a module?
Not quite sure what you mean. If module A is black-boxed into module B.
White-boxing B allows you access to the input/outputs of A.
If you black-box module B, which incorporates A, then there is no access to A’s input/outputs.
You are now dealing with the requirements of B.