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();
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(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(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>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] *On Behalf Of *ben
> cohen
> *Sent:* Saturday, August 28, 2010 12:29 AM
> *To:* 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.
This archive was generated by hypermail 2.1.8 : Sat Aug 28 2010 - 10:17:35 PDT