RE: [sv-ac] checker formal arguments may not be connected to interfaces // Updates

Hi Ben,

I think that this is fine. You would lhave one modport for assertions, i.e., all are of the same direction. Another modport would be for assume and there state and driven variables would have a different direction.

ed

From: ben cohen [mailto:hdlcohen@gmail.com]
Sent: Saturday, August 28, 2010 1:16 PM
To: Eduard Cerny
Cc: sv-ac@eda.org; Korchemny, Dmitry
Subject: Re: [sv-ac] checker formal arguments may not be connected to interfaces // Updates

Ed,
- It might be better to restrict modport directions to either input or output, but not inout. I that way, when the checker is used as constraints, the direction would define what is read (state variable) and what is driven by the constraint.
The issue is that if the modport is output in a clocking block then those clocking block outputs can't be "read",
Attached is that model. Thus, with this definition in the interface:
clocking mstr_cb @ (posedge clk);
    default input #2ps output #2ps;
    output a, b, f, g; // clocking block outputs can't be "read", must use inout
    input c;
  endclocking : mstr_cb
  modport master_mp (clocking mstr_cb);

module chk_m(input event e, t_if.master_mp k_if); // replace "module" with "checker"
  logic a=0, b=0, c;
  always @ (e) k_if.mstr_cb.a <= a; // line 41
  always @ (e) k_if.mstr_cb.b <= b;
  // always @ (e) k_if.mstr_cb.b <= k_if.g;
  always @ (e) begin : always1
    ap_rdnmz: assert(randomize(a, b));
          // k_if.tk<http://k_if.tk>();
  end : always1
  ap_abc_INCORRECT: assert property(@e a && b |=> k_if.mstr_cb.c);
  ap_abc_OK: assert property(@e k_if.mstr_cb.a && k_if.mstr_cb.b |=> k_if.mstr_cb.c);
endmodule : chk_m

From the simulator:
# ** Warning: ifchecker_output.sv<http://ifchecker_output.sv>(41): Clocking block output k_if.mstr_cb.a is not legal in this or another expression.
# Region: /top/chk_m1
# ** Warning: ifchecker_output.sv<http://ifchecker_output.sv>(42): Clocking block output k_if.mstr_cb.b is not legal in this or another expression.
# Region: /top/chk_m1
On Sat, Aug 28, 2010 at 7:55 AM, Eduard Cerny <Eduard.Cerny@synopsys.com<mailto:Eduard.Cerny@synopsys.com>> wrote:
Hi Ben,

Just a couple oc subjective comments:

- It might be better to restrict modport directions to either input or output, but not inout. I that way, when the checker is used as constraints, the direction would define what is read (state variable) and what is driven by the constraint.

- Sampling in clocking blocks for assertions is restricted (as far as I recall) to #1step. Do you really want to relax it? How will it interfere with the current implicit #1step sampling in assertions?
Best regards,
ed

From: owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org> [mailto:owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org>] On Behalf Of ben cohen
Sent: Saturday, August 28, 2010 12:29 AM
To: sv-ac@eda.org<mailto:sv-ac@eda.org>; Korchemny, Dmitry
Subject: [sv-ac] checker formal arguments may not be connected to interfaces // Updates

http://www.eda-stds.org/svdb/view.php?id=2751

File mantis2751.pdf /.docx present models of a checker with interfaces and addresses the following ISSUES
1. interfaces with or without clocking blocks
 a. Impact of using clocking blocks in interfaces? issues?
2. Checkers may be used as monitors or as drivers
  a. Interpretation of directions of modports
     i. As drivers, do we need a separate modport dedicated to the checker?
     ii. Can we reuse a modport defined for a DUT, but having a reverse interpretation of the port directions than those for the DUT?
3. Use of tasks defined in interfaces
The SystemVerilog models are also provided.

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.