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

<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?>
Is that an issue? From 16.5 Concurrent assertions overview
*If a variable used in an assertion is a clocking block input variable, the
variable shall be sampled by the clocking*
*block with #1step sampling. Any other type of sampling for the clocking
block variable shall result in an*
*error. The assertion using the clocking block variable shall not do its own
sampling on the variable, but*
*rather use the sampled value produced by the clocking block. This is
explained in Clause 14.*

From 14.4 Input and output skews (in 14. Clocking blocks)
*Input (or inout) signals are sampled at the designated clock event. If an
input skew is specified, then the signal*
*is sampled at skew time units before the clock event. Similarly, output (or
inout) signals are driven skew*
*simulation time units after the corresponding clock event. ...*
*An input skew of 1step indicates that the signal is to be sampled at the
end of the previous time step. In*
*other words, the value sampled is always the signal’s last value
immediately before the corresponding clock*
*edge. I**nputs with explicit #0 skew shall be sampled at the same time as
their corresponding clocking event, but to*
*avoid races, they are sampled in the Observed region. Likewise, clocking
block outputs with no skew (or*
*explicit #0 skew) shall be driven at the same time as their specified
clocking event, in the Re-NBA region.*

[Ben] That looks OK to me to have that in a checker. I don't see any issue.

??
Ben

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.