I’ve got a VHDL DUT, with an interface which talks to a chip on the PLB. In order to simulate my DUT in a UVM environment, I’ll need a model of this external chip. Should I write a new VHDL component which mimics the behavior of the chip?
Also, I developed a transaction based SV model of the DUT (my golden model); do I also need to create a SV model of the chip for the golden model to talk to, or do they somehow share the one model. #Confused
In reply to bmorris:
I’ve got a VHDL DUT, with an interface which talks to a chip on the PLB. In order to simulate my DUT in a UVM environment, I’ll need a model of this external chip. Should I write a new VHDL component which mimics the behavior of the chip?
Also, I developed a transaction based SV model of the DUT (my golden model); do I also need to create a SV model of the chip for the golden model to talk to, or do they somehow share the one model. #Confused
I drew a couple of diagrams to better understand the issues. The way you describe the verification environment, it seems that you are using a phantom model of the DUT and chip as the “golden copy”, and then do a compare between the the DUT/CHIP set and the golden SV/CHIP set. I show this here
Another approach would be to just use the VHDL DUT in a UVM environment, and let in the UVM environment, a checker that may (not sure if this is really needed, but maybe) emulate the main characteristics of the chip. I show this here
I prefer this 2nd solution because it put all the emphasis on verifying the DUT. I also recommend, in either approach, the ddition of SystemVerilog assertions.
However, you reall need to evaluate the complexity of each of those solutions, but my vote in on the 2nd one. Others, please put your 2 cents in.
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
In reply to ben@SystemVerilog.us:
Just now go to your reply. I didn’t know you could put pictures on here. Awesome; I’ll draw up what I’ve got tomorrow. I’m still digesting how to implement your 2nd option, but it might be promising.
In reply to bmorris:
In reply to ben@SystemVerilog.us:
Just now go to your reply. I didn’t know you could put pictures on here. Awesome; I’ll draw up what I’ve got tomorrow. I’m still digesting how to implement your 2nd option, but it might be promising.
For photos, I found that you need to add a link to where the images are. Use the icon just to the right of the “B I U” options on top of the message window, Example
Which is from photos.google.com/
In may case, I hosted the images at my site; but there are other sites where you can host your images.
In reply to ben@SystemVerilog.us:
Just to be clear, in your suggested approach, the DUT TLM is captured in SV (not VHDL), in the UVM environment. There is a pin-wiggle to transaction barrier now; therefore, the model must be awaiting for sometimes partial bus transactions to occur (like a read), and must then complete the bus activity (like how a responder sequence works), directly through an interface call.
Is this an accurate description?
In reply to bmorris:
[quote]In reply to ben@SystemVerilog.us:
Just to be clear, in your suggested approach, the DUT TLM is captured in SV (not VHDL), in the UVM environment. /quote]
If it is easier for you to build and integrate the DUT_TLM in VHDL then do so.
In the world of design and verification, I started with VHDL and wrote 6 books about the use of VHDL for design and verification. However, when I got involved with SystemVerilog and assertions, and looking at the current progress and features of SystemVerilog compared to VHDL, I see far, far more strengths in SystemVerilog, and I abandoned VHDL. In fact, if I were to start a new design and verification project, I would not even consider VHDL, but may consider C++ as an addendum. Anyway, this is why I picked that DUT TLM in SystemVerilog, but you should do what is right for you.
I would say YES. The UVM verification model may ncorporate 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?
Again, and just for the record, are you using assertions in your design and in your interfaces? They can save you a lot of time! I have said this before, and I’ll say it again : An assertion is a statement that the property is true. Everytime you do a verification model (UVM or other), you are indeed writing assertions. Assertions can be written with code and with an assertion language like SVA. There is nothing magical about SVA; the only exception is that SVA assertions are concice, and can quickly be written, and tools help in the fast detection of errors and in the application of coverage (that certain sequences or properties were covered).
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
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.
" 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.
"I would say YES. The UVM verification model may ncorporate 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?
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!)
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!)
[Ben] I strongly recommend that assertions be used at the RTL design phases for the following reasons:
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
[/quote]
In reply to ben@SystemVerilog.us:
Ok my coworker and I are scratching our heads on a subject related to this.
What we’ve done in the past is have “phantom models” that are highly coupled with the RTL state machine. E.g. The RTL got a command, and performed:
Read 0x1, Read 0x2, Write 0x1, Write 0x2.
our “model/predictor” would do the exact same thing.
Now, if the RTL changes at all, adds an extra write, or changes the order, the model is wrong.
I think our paradigm of performing checking, and building models is incorrect. It’s coupled too tightly to the implementation details. Agree?
I’m guessing the model needs to care more about FUNCTION, and less about IMPLEMENTATION.
Thoughts so far?
In reply to bmorris:
Regarding a reference model you cannot give clear advice to use a SV or any other model. What you are using depends on 2 things. Firstly, what is available. Do system architects have C++ models or is a behavioral model in VHDL or SV available. Or do we have any other reference like a Matlab model. Secondly it has to be a model which represents exactly the function of the DUT. Exactly means in terms of FUNCTION and not of clock cycles (cycle-accurate). Both models can be integrated directly in a UVM testbench using the DPI interface.
In reply to chr_sue:
We are using a functional, untimed model. We were trying to figure out how to avoid such a close dependency between decisions made by the RTL designer, and the behavioral model. My accellera forum has a good example of what I mean.
In reply to chr_sue:
In reply to bmorris:
Regarding a reference model you cannot give clear advice to use a SV or any other model. What you are using depends on 2 things. Firstly, what is available. Do system architects have C++ models or is a behavioral model in VHDL or SV available. Or do we have any other reference like a Matlab model. Secondly it has to be a model which represents exactly the function of the DUT. Exactly means in terms of FUNCTION and not of clock cycles (cycle-accurate). Both models can be integrated directly in a UVM testbench using the DPI interface.
In reply to bmorris:
I’m guessing the model needs to care more about FUNCTION, and less about IMPLEMENTATION.
I like bhunter1972’s reply ( predictor / TLM model paradigm - UVM SystemVerilog Discussions - Accellera Systems Initiative Forums ). My only other comment is that aside from using scoreboard one could, in many cases, use assertions.
This is because we’re eventually testing the requirements, and in many cases, assertions with SVA can do that in a mroe readable and executable manner.
I make this point in the following papers:
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
http://verificationacademy.com/verification-horizons/october-2013-volume-9-issue-3
and “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
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us
In reply to ben@SystemVerilog.us:
I don’t like the term checker, because it is not specific enough. There are different kinds of checkers, one type is the scoreboard and the other one are assertion checkers. Both types are used to check different things. In most applications you will not be able to replace a work without a scoraboard, having only assertions-. The scoreboard provides you more or less an automaetd waveform compare. Properties are used to model design content and they are checking if this content was executed, including correct timing. The scoreboard checks different things.
A typical application for assertions/properties is the checking of bus protocols or FSM, searching for interrupts etc.
In reply to ben@SystemVerilog.us:
I don’t like the term checker, because it is not specific enough. There are different kinds of checkers, one type is the scoreboard and the other one are assertion checkers. Both types are used to check different things. In most applications you will not be able to replace a work without a scoraboard, having only assertions-. The scoreboard provides you more or less an automaetd waveform compare. Properties are used to model design content and they are checking if this content was executed, including correct timing. The scoreboard checks different things.
A typical application for assertions/properties is the checking of bus protocols or FSM, searching for interrupts etc.
In reply to chr_sue:
I don’t disagree. However, methodologies like UVM stresses the use of scoreboards with monitors whereas assertions would have been a lot easier in many cases. For example, I used scoreboards as examples for simple designs like counters (with some weird requirements) and a UART. In both of these cases, assertions with some trivial support logic would have been easier.
Ben Cohen
SystemVerilog.us
In reply to ben@SystemVerilog.us:
This is what I said, there are areas where you should use assertion checkers. These FSM - a counter is a simple FSM - and interfaces like UARTs.
To give you an example from my professional life: We had to verify an image processing chip to verify with a lot of algorithmic stuff inside. There was C++ model available (several thousands lines of code). We used this as reference model in a scoreboard. You’ll never have a chance to verify this behavior with assertions only.
Christoph Suehnel
In reply to chr_sue:
No disagreement with you. My only point is that UVM, along with books, training, and presentations on the topic show/encourage the use of scoreboards and monitors as the verification vehicle. It’s as if it is the ONLY solution.
Ben
http://SystemVerilog.us
In reply to ben@SystemVerilog.us:
I agree with you and can confirm your reception. But there are also exceptions.
In reply to ben@SystemVerilog.us:
Ben,
I am going through your papers. First, my methodology question…
From what is dissolving into my understanding, it appears that assertions are good at targeting lower-level/temporal level requirements. Generally, our “requirements” are higher level. Example “The DUT shall support transmission of IGMP Query”. In my testbench, I use a packet monitor connected to a coverage collector, and simply sample the queries that come out. I’m not sure how I would parse, and detect these packets using assertions (probably because I’ve not tried!) These requirements don’t appear to easily map to assertions. Agree/Disagree/thoughts?
I could see a list of derived requirements, I.e. requirements generated because of the designers chosen implementation of the higher level requirements being perfect for assertions. Basically all the nuts and bolts of the design, and the interface protocols. Agree/Disagree/thoughts?
We don’t write down any implementation specific requirements. Should we, and then generate assertions to target those? Alternatively, should we NOT write them down, and let the assertions BE the documentation?
In addition, can/should the assertions also target higher level requirements (which are of more importance in the grand scheme of things)? E.g. I just to know queries were produced, but I do not care how the designer does it)
In reply to bmorris:
*In reply to ben@SystemVerilog.us:*Ben,
I am going through your papers. First, my methodology question…
[Ben] Yes, they do best over here.
Below is a link from my SVA 4th Edition book that addresses this topic of SystemVerilog Assertions in the design process http://SystemVerilog.us/svabk4_process.pdf
My main point are:
SystemVerilog properties can be used to capture system/subsystem level requirements, and those properties can then be reused in a testbench environment, later in the design cycle. System-level requirements can have the following classifications:
Functional: This represents the purpose of the design.
Performance: That consists of items such as baud-rate, frequency, capacity, speed, throughput, and latencies.
Interface: Since the design under consideration may interface to existing busses, and connections to other subsystems, the requirements document needs to include software, hardware, and communications interfaces. That should also include expected modes of operations and restrictions (e.g., parity type, frame size, master, slave).
Safety: Many designs are subject to security and safety issues to insure safe operations under certain conditions or failures (e.g., during reset, power down, power-up, hot plugging, bus or unit failure).
Operational: Some designs are subject to user interfaces for commands, configurations, or maintenance.
Resource: Resources are requirements that are critical to a design, and include items such as power, memory, form-fit factor (i.e., size), etc.
The performance, interface, and safety classifications can be expressed in SystemVerilog Assertions using libraries defined in checkers or in modules. It is important to note that requirements are independent of the architecture and implementation. However, the architecture and implementations are a result of the requirements.
Generally, our “requirements” are higher level. Example “The DUT shall support transmission of IGMP Query”. In my testbench, I use a packet monitor connected to a coverage collector, and simply sample the queries that come out. I’m not sure how I would parse, and detect these packets using assertions (probably because I’ve not tried!) These requirements don’t appear to easily map to assertions. Agree/Disagree/thoughts?
[Ben] There are many cases where SVA needs to be supported by auxiliary code. Looking at Internet Group Management Protocol - Wikipedia
You have GMPv2 messages
IGMPv2 packet structure[8]
+ Bits 0–7 8–15 16–31
0 Type Max Resp Time Checksum
32 Group Address
My point is that one could use supporting logic to parse these fields, and then use assertions to determine if the correct path was taken by the RTL. Note that an “assertion” is a “a confident and forceful statement of fact”, and that can be checked in a variety of ways:
- I could see a list of derived requirements, I.e. requirements generated because of the designers chosen implementation of the higher level requirements being perfect for assertions. Basically all the nuts and bolts of the design, and the interface protocols. Agree/Disagree/thoughts?
[Ben] It is important to note that requirements are independent of the architecture and implementation. However, the architecture and implementations are a result of the requirements.
We don’t write down any implementation specific requirements. Should we, and then generate assertions to target those? Alternatively, should we NOT write them down, and let the assertions BE the documentation?
[Ben] See my above answer. Implementation specific requirements, but may be needed in some cases when a specific technology or reuse is a requirement; a fact of practical life!
Should the assertions BE the documentation? Good question.
I have not been in a real working environment for many years now; however, I keep in touch with some colleagues, and my son is a sw guru. Not all projects write down requirements, and in any form! Many create them on the fly, using just very high level requirements. In our hardware design world, not many people can read SVA, and intermixing SVA with English requirements can be confusing. In my books, I recommend the intermixing of English with SVA.
Here is a link to a sample requirement doc http://SystemVerilog.us/svabk4_req.pdf
In addition, can/should the assertions also target higher level requirements (which are of more importance in the grand scheme of things)? E.g. I just to know queries were produced, but I do not care how the designer does it)
[Ben] Yes. Keep in mind what an Assertion IS: It is not necessarily an SVA assertion, but more a verification that the statements or requirements of your design are met. If SVA is easier, do that. SVA is really a shorter notation that IMHO, is much easier to read, and can be used for coverage.
Ben Cohen
http://www.systemverilog.us/ ben@systemverilog.us