In reply to SidRaj:
Now in my Dut model which is FIFO model, there are 3 output port which are fifofull,fifoempty,dataout.
Now there can be corner case where if push and pop occurs simultaneously dut will show errors.
You have to go back to the requirements. Do they say that it is illegal to do simultaneously do a read and a write? Depending on the RTL design it may be legal to do that.
Now should I include this case in the RTL design coding of FIFO and make one another output port which becomes high when this type of corner cases occurs and display error message in dut model itself ?
I FIFO as an IP unit that can be reused in many systems needs an error output for several reasons. At the system level, it may take corrective actions. It is also useful for debug.
The requirements should specify what happens when you do error conditions, as these states can be entered with the input smiluli. For example, on a read and write, what is provided as read-data, and what is written, if any into the FIFO. Same question on a push on full, or pop on empty.
Or should I predicts this corner cases only in scoreboard and display error there in Scoreboard ?
I defined above what is a scoreboard; it keeps the score as to what the DUT (FIFO here) should behave to the stiluli in accordance with the detailed requirements. If you have weak requirements, it’s the GBGO. The scoreboard is not a monitor, it does not record what is happening, but what should happen.
Also, the scoreboard is not a verifier. The verification logic will use the scoreboard along with the monitor (or active monitoring) of the DUT. The the code i presented in my previous reply, the queue and its requirement rules models the scorebooard. The assertions do the verification.
There is no “prediction of corner cases”. The testcases should cover all the aspects of the requirements. Sounds like you do not have a requirement document.
The following book demonstrates how to write chip specs. I used VHDL as a model, and the verification methodology in that book is not something i recommend today because the technology has significantly changed since then. However, the spec writing has not really changed; requirements and specs are just that, specs.
FREE BOOK: Component Design by Example
… A Step-by-Step Process Using VHDL with UART as Vehicle
Or should I make another output port for corner cases in dut coding and pass this signal to scoreboard and compare this output with the scoreboard prediction and display message in Scoreboard accordingly if predicted and actual results matches or not?
I don’t understand this concept of another port. You have a DUT and a verification environment that drives the DUT and checks it in accordance with the requirements.
The requirements have normal cases and define the behavior under corner cases.
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
- SVA Alternative for Complex Assertions
https://verificationacademy.com/news/verification-horizons-march-2018-issue - SVA: Package for dynamic and range delays and repeats - SystemVerilog - Verification Academy
- SVA in a UVM Class-based Environment
https://verificationacademy.com/verification-horizons/february-2013-volume-9-issue-1/SVA-in-a-UVM-Class-based-Environment