After reviewing your reply, Let me know if the following statements are accurate…
An assertion can be made at several levels, and described with little to no wiggle-room for misunderstanding, using SVA (as one method).
There can be assertions based on requirements; these assertions are independent of architecture or implementation.
There can ALSO be assertions placed on low-level design constructs as the designer sees fit (writing a full-FIFO is not allowed). It has zip to do with the DUT requirements, but it enforces healthy RTL behavior according to the implementer. These assertions are tightly coupled / dependent on architecture or implementation. Do these have a special name?
In reply to ben@SystemVerilog.us:
After reviewing your reply, Let me know if the following statements are accurate…
An assertion can be made at several levels, and described with little to no wiggle-room for misunderstanding, using SVA (as one method).
[Ben] Agreed. Complex assertions should be verified on their own merit. Code reviews and simulation with constrained-random tests is another way.
There can be assertions based on requirements; these assertions are independent of architecture or implementation.
[Ben] Yes, absolutely. In SVA, use “SV checkers” bound to the DUT and/or SV interfaces.
There can ALSO be assertions placed on low-level design constructs as the designer sees fit (writing a full-FIFO is not allowed). It has zip to do with the DUT requirements, but it enforces healthy RTL behavior according to the implementer. These assertions are tightly coupled / dependent on architecture or implementation. Do these have a special name?
[Ben] They are often referred to as RTL assertions, as they affect the design. They also define/clarify the designer’s assumptions (SVA assume directive). These include things that the designer may take advantage of, of knows of because of other partition interfaces, and thus can take advantage of. They are useful in code reviews too.
// Never a request when ready is false.
m pRequestReady : assume property (@ (posedge clk) not(request && !ready));
am1: assume property (req |=> !req) else $error(“req for more than 1 cycle”);
ap_min_load: assume property(
ld |-> not(data_in<MIN_COUNT));
Thanks. We are going to start trying to work these in, in bits and pieces. Starting… with a couple of serial transmitters. About your paper, Assertions Instead of FSMs/logic for Scoreboarding and Verification, a couple of questions.
I’ve drawn up how I interpreted the paper into a picture. When you explain the steps, you write “For the next 8 cycles, serial data is collected and verified on a bit-by-bit basis against expected data. That expected data is the sent_data from the driver, which is a synchronous copy of item_h.data, where item_h is the handle in the DUT interface, and data is the data word written to the DUT that gets serialized and sent by the DUT. That handle is updated from the driver.”
In application, the driver is on the other side of the DUT, in the parallel loading interface writing the Tx buffer. How is this driver updating the other (tx serial) interface’s transaction handle (which contains the data loaded into the Tx Buffer). Aka does this driver have VIF to a different interface? That seems like an unwanted dependency.
My “host If” is just like the “APB” interface from the UART example in the mentor coverage cookbook on pg 52. With your setup, you don’t need the scoreboard, or the passive agent. Anyway.
With your setup, you don’t need the scoreboard, or the passive agent
[Ben] In that paper, I was demonstrating the concept that verification with UVM can be done using SVA (in some cases), and avoid the use of monitors and scoreboards.
In application, the driver is on the other side of the DUT, in the parallel loading interface writing the Tx buffer. How is this driver updating the other (tx serial) interface’s transaction handle (which contains the data loaded into the Tx Buffer). Aka does this driver have VIF to a different interface? That seems like an unwanted dependency.
[Ben] One could add a dedicated test SV interface that can be updated by the driver. One can also use static class properties that can be read from anywhere to get the 8-bit value driven by driver. Note that the static class properties can be used without creating an object of that type.
My “host If” is just like the “APB” interface from the UART example in the mentor coverage cookbook on pg 52.
Again, my purpose of writing this paper is that SVA can be used do do verification by moving the assertions into a SV interface (dedicated for that sole purpose , or some existing SV interface) and providing into that interface all the needed information to do the verification; that would include the IOs and information about expected results. As with any other assertion, supporting logic may be needed (e.g., functionc, always_ff, etc). Note that an SV checker can used to write these assertions; the checker can be bound to SV interfaces.
Ben Cohen http://www.systemverilog.us/ben@systemverilog.us
