In reply to bmorris:
In reply to ben@SystemVerilog.us:
“If it is easier for you to build and integrate the DUT_TLM in VHDL then do so.”
Agreed. I would prefer SV for my models, if starting from scratch ( for several reasons ). We haven’t used SV for design before; perhaps we should consider it.
[Ben] SystemVerilog RTL design coding style rules are very very similar to VHDL.
I prefer SystemVerilog for RTL design over VHDL, as it offers things like always_comb, always_ff, always_latch, better choices in the case statement. You have to be careful about arithmetic in SystemVerilog. In my book “Real Chip Design”, i explain those rules and caution that must used. I provide this section at
Though written quite a few years ago, it is still valid today.
" I would not even consider VHDL, but may consider C++ as an addendum"
Do you mean SV for design AND C++, or, designing in purely C++ and have some translation tool (to HDL)? I’ve heard those tools can produce unwieldy results, but I have no experience with them.
[Ben] I personally have never used C++. However, I know people who have, and have told me the good part of C++ verification is the nearly 10,000x simulation speed increase. Usually assertion testing is already fast. The faster C based behavioral simulation does help when running long scenarios operating as done in tactical system. Once behavioral is proven, the same C++ testbench is run using same tool on RTL as final proof to make sure the synthesis correct by construction rules are not broken. In addition, they are doing a good percentage of development in C/C++ for FPGAs,
"I would say YES. The UVM verification model may incorporate a scoreboard with a buffer memory (or an associative array or a queue) to sync up transactions and checkers. Does tis make sense to you? "
If you just mean a scoreboard with say, FIFOs for expected & actual transactions, then yes.
“a checker that may (not sure if this is really needed, but maybe) emulate the main characteristics of the chip.”
What is your thinking behind this; that emulating the characteristics of the chip may NOT be required?
[Ben] The key here is the need to really understand the chip to which the DUT ties in. There are PROs and CONs in emulating that chip.
PROs: If the chip model is correct, then you have a higher level of assurance that the DUT does indeed correctly interfaces with that chip. In addition, you have less to worry about that interface.
**CONs:**One can get trapped in trusting that emulating model. An experience I had is the emulation of an Intel CPU that had a front-side user interface and a backside memory interface. I was doing a DUT that tied to the front-side, so we emulated that Intel interface. To make a long story short, it turned out that the CPU had an internal timing quirk between the front and backside interfaces, and though our model worked, the real CPU caused (under some weird and obscure circumstances) a latch-up that locked out the front-side from further interactions.
KEY There is a need to have a good understanding of the interfaces to the DUT. The verification environment is really concerned about the DUT/ If that environment ignores the CHIP interface because it relies on the emulated model, it may miss something.
Finally, about assertions. I am not currently at the experience level with assertions that I want to be. The only place I use them is in the interface, to monitor the protocol is obeyed. Beyond that, where are the primary places they offer the most benefit? (I havent gotten time to read your book yet!)
- design (bound in, because our design is VHDL)
- protocol checkers
… ?
[Ben] I strongly recommend that assertions be used at the RTL design phases for the following reasons:
- Clarifies understanding of the requirements
- Clarifies the assumptions
- Defines expected results, even if internal. See my post at
How to include internal state of FSM in SV Assertion? - SystemVerilog - Verification Academy
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
- 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 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
[/quote]