RE: [SPAM] - RE: [sv-ac] FW: P1800 AC issues - Email found in subject

From: Kulshrestha, Manisha <Manisha_Kulshrestha_at_.....>
Date: Mon Apr 04 2005 - 10:13:48 PDT
Hi Bassam,
 
This is definitely not a enhancement request. The purpose of raising
this
issue is to get some clarifications on how sampling works when clocking 
block signals are used in properties. 
 
Faisal, are we going to use same database to enter these issues. I would
like to enter the detailed proposal for this issue as XL spreadsheet did
not
have all the details from my proposal. I would like everyone to look at
the
examples in the proposal so that we can discuss different issues
involved.
 
Thanks.
Manisha
 
 
 
 

________________________________

From: Bassam Tabbara [mailto:bassam@novas.com] 
Sent: Monday, April 04, 2005 8:26 AM
To: Kulshrestha, Manisha; 'Eduard Cerny'; sv-ac@eda.org; 'Faisal Haque'
Cc: 'Surrendra Dudani'
Subject: RE: [SPAM] - RE: [sv-ac] FW: P1800 AC issues - Email found in
subject


Hi Manisha,
 
To be clear, my mention of "lives in" really means *associated with*
i.e. property uses the *clocking event* defined in a clocking block. I
just used "lives" in the previous context thinking that the "virtual
clocking block" would be easier to explain that way, but now I think
associated with is less confusing so we can say in the LRM that the
clocking event is associated with a default/virtual clocking block (if
one is not defined) with #1step default input skew.
 
As to the rest of the questions, I do think if you always reference the
clocking event and sampling based on that it should all be clear, and be
as intended in the LRM. 
 
We should not be reviewing enhancements or changes but rather clarifying
the intent. So the 2 issues sampling, and the order could use a simple
clarification. Any "sampled differently" cross issues would/should be
covered by the rules for "multiple clocks".
 
Thx.
-Bassam.
 
--
Dr. Bassam Tabbara
Architect, R&D
Novas Software, Inc.
(408) 467-7893
 

________________________________

From: Kulshrestha, Manisha [mailto:Manisha_Kulshrestha@mentorg.com] 
Sent: Monday, April 04, 2005 12:10 AM
To: bassam@novas.com; Eduard Cerny; sv-ac@eda.org; Faisal Haque
Cc: Surrendra Dudani
Subject: [SPAM] - RE: [sv-ac] FW: P1800 AC issues - Email found in
subject



Hi All,

I think the sampling rules should be based on the signal/variable being
referenced rather than where the property/sequence lives. So,
if a property/sequence is not in the clocking block but is refering
to a signal (hierarchically) which is in the clocking block, then
the sampling of that signal will happen based on the clocking block
and it will be independent of sampling of other signals in that
property/sequence.

Now, the issue is how to handle signals in a property/sequence
which are getting sampled differently ? Should it be allowed as it
might create undesirable results ?

Even if we make sampling based on location of
property/sequence/assertion,
the above question remains as all the variables used in the
property/squence
may not be inputs/outputs of the clocking block.

Another question is about #0 sampling in clocking block. In case of #0
sampling, the inputs are supposed to get sampled in Observe region and
properties also get evaluated in Observe region. So, which one happens
first or is it a race ? Currently LRM does not clarify it.


Thanks.
Manisha


#241: I think there is some "mixup" here by author about sampling and
scheduling (within timestep). The question is really about sampling and
I am
not sure what Ed/Surrendra are trying to say. Seems to me a
clarification in
the LRM here would be to say that the *default* input skew for
properties is
#1step same as clocking block default. If an assertion/property/sequence
lives in a clocking block it would follow whatever input skew sampling
is
defined there for the inputs (and default is #1step in a clocking
block).
Meaning if a property is not inside a clocking block it is inside a
"virtual" one with #1step. That's really it I think, no double
resampling
and what not.
Received on Mon Apr 4 10:13:53 2005

This archive was generated by hypermail 2.1.8 : Mon Apr 04 2005 - 10:13:59 PDT