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

Hi Ben,
 
The clocking block outputs can not be read even if there is no modport. A checker which is only checking should only read clocking block inputs. Similarly a checker which is acting as constraints creater would only write to outputs. If a checker is doing both, it can read inputs and write to outputs or read/write to inouts. For a checker to act as constraint, it should be able to assign non-checker variables.
 
So, I do not see a reason to put any restrictions on the modports. It will depend on the functionality in the checker what all it can read/write. But with the current functionality in checkers only input or inout can be used.
 
Manisha

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of ben cohen
Sent: Saturday, August 28, 2010 10:46 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();
  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 <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.