RE: [sv-bc] illegal priority if

Indeed.  I believe I (as a designer) would either use the case statement with the default block and an assertion, or as Adam suggests, calculate the conditions up front, and assert $onehot over the concatenations of the conditional terms.

Leaving it up to the simulator to pick an order, and only require a complaint if that order was not onehot, gives (IMHO) too much freedom to the wrong party in the deal: again, from my perspective as the designer.  The new construct doesn't give me an assurance that I don't need to run a formal verification tool for this case.

Greg is right that it is only crazy cases where there is any order dependent effect in any case; but the corollary to that is the slow down would only be experienced in those crazy cases, and *gosh* those are the ones I want to spend simulation time on!

Anyway, where are we going with this? 

   Is there any consensus towards making a modification of the language? 

   Issuing an interpertation of the language that codifies Brad's understanding of the language as the committee's official view?

   Issuing an interpertation that does something codifies something different than Brad's view?

   Leaving this alone for now?



Michael McNamara
mcnamara@cadence.com
408-914-6808 work
408-348-7025 cell


-----Original Message-----
From: francoise martinolle [mailto:fm] 
Sent: Friday, January 13, 2006 9:52 AM
To: Michael (Mac) McNamara; 'Brad Pierce'; sv-bc@eda.org
Subject: RE: [sv-bc] illegal priority if

 
I am much more clear now on what this paragraph means. Thanks for the
interpretation,
but for the reason that there is not a strict enforcement for the simulator
to determine that this is an illegal if, I do not see the point in having
this construct.
The way it is now, it seems that the spec requires some formal checking done
by the simulator
but not too much and we do not know if the checking was abandoned early or
if it was indeed complete
or even if there is a combination of order which makes the "unique if" NOT a
"unique if".

Regarding the second sentence, as a user I would expect to see the warning
even if there is an order
of evaluation that is fine. The point of warning is that indicate that the
conditions are not 
written to be unique.
Wouldn't someone want to know that their Verilog code does not meet their
uniqueness requirement?

Francoise
    '

I do not know if this is a true unique if, I do not think I will be using
this construct.
-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Michael
(Mac) McNamara
Sent: Thursday, January 12, 2006 5:31 PM
To: Brad Pierce; sv-bc@eda.org
Subject: RE: [sv-bc] illegal priority if

I see where one might interpreter the words in the standard that way.  

However, it would be much better if your language was used rather than the
convoluted construction we have today!

Taking the spec to mean precisely they way you have clarified it, there are
still issues:

The first sentence: "A unique if shall be illegal if, for any such
interleaving of evaluation and use of the conditions, more than one
condition is true. " unequivocally defines a class of unique ifs which are
"illegal"

The second sentence : "For an illegal unique if, an implementation shall be
required to issue a warning, unless it can demonstrate a legal interleaving
so that no more than one condition is true." differentiates between those
illegal if's for which there is a discovered path that does not result in a
contradiction with the "unique", and those for which there is no such path
(at all, or such that happened to be discovered) and has the effect of the
later to be something that requires a warning, but the former do not require
a warning.  This is like the rule in Ice Hockey: If the umpire didn't see
it, there is no penalty.  [Must the simulator actually demonstrate the legal
order of evaluation, perhaps under a verbose switch??]

I am imagining that the committee worded it this way so as to create the
smallest burden on the simulator implementer: pick an order, evaluate the
terms, and if more than one are true, issue a warning. Don't bother
considering other orders of evaluation.

However, this does result in a disservice to the synthesis implementer:
there is no way for the synthesis programmer to know what order was chosen
by the simulator programmer, and hence to generate gates which match the
results simulated by the simulator. 

Moreover, this becomes yet another place where two simulators could give
different results for the same design & stimulus, and yet both be standard
compliant.



Michael McNamara
mcnamara@cadence.com
408-914-6808 work
408-348-7025 cell


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad
Pierce
Sent: Thursday, January 12, 2006 1:58 PM
To: sv-bc@eda.org
Subject: Re: [sv-bc] illegal priority if

No, the tool is required to try it one way.  If there is no uniqueness
violation, then it doesn't warn.  If there is a uniqueness violation, it
warns.

-- Brad

-----Original Message-----
From: Michael (Mac) McNamara [mailto:mcnamara@cadence.com]
Sent: Thursday, January 12, 2006 1:47 PM
To: Brad Pierce; sv-bc@eda.org
Subject: RE: [sv-bc] illegal priority if

But is this leniency useful?

Doesn't it imply the synthesis must also implement the leniency in gates
somehow?

Doesn't it require the simulator to evaluate as many possible orders of
evaluation until a order is discovered which results in a unique evaluation
is obtained, while doing so in a back tracking, non side-effect manner (the
condition functions can't call $display, any global variables must be
restored, no processes can be scheduled basd on these speculative
evaluations)

Bottom line: who wants this leniency? Do you want to put it in your design
tools? Do users want such logic in their silicon?

Michael McNamara
mcnamara@cadence.com
408-914-6808 work
408-348-7025 cell


-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Brad
Pierce
Sent: Thursday, January 12, 2006 1:14 PM
To: sv-bc@eda.org
Subject: Re: [sv-bc] illegal priority if

It means that if the tool finds such a sequence, then a warning is not
required.  So the tool is not required to prove whether the unique if is
legal, but the tool is required to do some due diligence.

-- Brad

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
francoise martinolle
Sent: Thursday, January 12, 2006 10:49 AM
To: 'Bresticker, Shalom'; sv-bc@eda.org
Subject: RE: [sv-bc] illegal priority if

 
I do not understand what it means "interleaving evaluation and *use* of the
conditions".
Also what is the meaning of the sentence "unless it can demonstrate a legal
interleaving so that no more than one condition is true"?
Does it mean that if I found 1 sequence of evaluation of each condition in
the branches that does not make more than one condition true, the unique if
is correct?

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Thursday, January 12, 2006 8:20 AM
To: sv-bc@eda.org
Subject: [sv-bc] illegal priority if

Question:

1800 10.4 says, 

"A unique if shall be illegal if, for any such interleaving of evaluation
and use of the conditions, more than one condition is true. For an illegal
unique if, an implementation shall be required to issue a warning, unless it
can demonstrate a legal interleaving so that no more than one condition is
true."

What is the meaning of this "illegality"?

Generally, "illegal" means a fatal compile-time error or something similar.
Is that really the meaning here? Or is the meaning simply that a warning (or
error, for strict people) message needs to be issued? 

I hope my question is clear.

Thanks,
Shalom


Shalom Bresticker
Intel Jerusalem LAD DA
+972 2 589-6852
+972 54 721-1033
I don't represent Intel