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

From: Eduard Cerny <Eduard.Cerny@synopsys.com>
Date: Sat Aug 28 2010 - 07:55:06 PDT

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.
Received on Sat Aug 28 07:55:29 2010

This archive was generated by hypermail 2.1.8 : Sat Aug 28 2010 - 07:55:45 PDT