Is binding only the option for connecting the assertions to a model?

SystemVerilog
, ,
1

Hi,
If we have written some assertions for a model, we can connect them to it by binding. Is there any other way to connect them?

Thanks,
Tarun

2

In reply to perumallatarun:

Binding is not the only option, but it is one of the best in terms of portability and re-use.

Instead of binding a module with an assertion into a design, you can always instantiate the module in a separate testbench, and put hierarchical pathnames as port connections. Of course, the worst option would be to put hierarchical pathnames directly in your assertions.

Probably one of the best and least used options is to embed the assertions directly inside your model. But “ownership” of source code seems to prevent that.

3

In reply to dave_59:

Sir, My doubt is we can also use inline assertion or is it not recommended?

4

You can use a SystemVerilog checker that can be instantiated inline or procedurally. I explain the application of checkers in my SVA Handbook. Consider the following examples:


checker chk(event ev, ..); 
  ap1: assert property( @ev a |=> b); 
  a1: assert #0 (a && !c);
endchecker 

module m(...);
  always_ff @ (posedge clk)
   if(w)
     case (addr)
        // checker instantiation 
        0 : chk chk_procedural( posedge clk, ..); // <--***
        default : ...;
     endcase
endmodule

Above with the checker is equivalent to:


//Assertion queued after all preconditions in module procedure are met.
module m(..);
  always @ (posedge clk)
   if(w)
     case (addr)
       0 : begin 
             ap1: assert property( // <-- ** Equivalent 
                @(posedge clk) a |=> b); 
             a1: assert #0 (a && !c);
           end
       default : ...;
      endcase
endmodule

BTW, checkers can be defined in many environments: 1) as a separate compilable unit, 2) inside a package, 3) inside a module, 4) inside a checker, 5) inside an interface, or 6) inside a program. This allows the checkers to be either instanced in modules/interfaces/programs or be bound via the bind construct.
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
5

*In reply to varunkdave:*Inlining(embedding) assertions or checkers is recommended, but as I mentioned earlier, rarely done because usually two different people are involved and difficult to mange the source code.

6

In reply to dave_59:

But form a verification perspective, it is better that two different people are involved.

7

In reply to ben@SystemVerilog.us:

Inline assertions are good choice for the Design engineers.
But for the verification engineers defining checkers in a separate unit and instantiate it in the target design I think is a good option and a good practice as well. For the big design the checkers are written based on the specs in parallel with the design implementation. In this case the embedded checkers are not so efficient in term of time management (Verification side).