RE: [sv-bc] RE: [sv-ac] RE: [sv-ec] Checkers & Formal

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Thu Mar 20 2008 - 08:29:10 PDT
Hi Gord,

Please, see my comments below.

Thanks,
Dmitry

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Thursday, March 20, 2008 4:35 PM
To: Korchemny, Dmitry
Cc: sv-bc@server.eda.org; sv-ec@server.eda.org; sv-ac@server.eda.org
Subject: Re: [sv-bc] RE: [sv-ac] RE: [sv-ec] Checkers & Formal



Korchemny, Dmitry wrote:
[...]

> Particularly for an unassigned freevar, it seems that
> there is no requirement for the freevar to ever change.
> How much simulator implementation variability is valid?
> 
> [Korchemny, Dmitry] This is correct, but if the variable changes,
there
> will be an event. If my suggestion is accepted, this problem becomes
> irrelevant.

But *when* does such an event occur?  If a simulator can decide
to change a freevar, is there a defined region during which
such a change must take place?  Assume for a moment that freevars
are "assigned" in the Observed region; if that is the case then
the next reactive region process set would see the change "before"
the normal active region processes.  Is that reasonable?
If a freevar "glitches" due to multiple evaluations of an
assertion, is it ever important to have observability of that
glitch?

[Korchemny, Dmitry] I think that the event on a free variable is not
different from event on a sequence as for the implementation is
concerned. But I agree that using free variables in regular assignments
should be explicitly made illegal.

> From what I think I've heard, it seems unlikely to me that
> inspecting or using a freevar value during simulation would
> be terribly useful, particularly given the lack of
> constraints on the implementation behavior in assigning to
> the unassigned freevars.  Is that the case?
> 
> [Korchemny, Dmitry] I agree.
> 
> If so, should all non-checker use of a freevar just be made illegal?
> 
> [Korchemny, Dmitry] Yes, it makes sense.


That certainly would reduce areas in which LRM specified behavior
could diverge.  There are still end-user expectations with respect
to non-HDL references to the freevars (ie. vpi access, "wave window"
viewing, etc).  For those cases, I think that either we need
to disallow any external visibility of freevars (which is likely
very unappealing due to vpi expression access), or we should be
deal with the scheduling issues related to the region in which
freevars may change.

[Korchemny, Dmitry] VPI could report an error when trying to address a
free variable, or to show always its default value.

Gord.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Mar 20 08:36:59 2008

This archive was generated by hypermail 2.1.8 : Thu Mar 20 2008 - 08:37:37 PDT