RE: [sv-ac] Ballot item 241 proposal

Hi All,
 
I am fine with making 2 clock case illegal. I was simply explaining how
I 
interpret it based on the current proposal. Should we enhace the
proposal's
first paragraph as follows:
 
The values of the variables used in assertions are .....Observe region.
If a variable used
in an assertion is a clocking block input variable, the variable must be
sampled by the 
clocking block with #1step sampling and clocking block must sample the
input 
variable at the same clocking event which is used for the variable in
the assertion.
 Any other  sampling for the clocking block variable
shall result in an error. .....
 
I'll also add Ed's last example to say that it is illegal to use
different clocking 
events in the property and clocking block. Please note that the above
statements
allow using clocking block variables in multiply clocked assertions even
though 
they should be used in a context so that their sampling clocking events
match.
 
I'll also add the example of illegal property and send the updated
proposal if
everyone agrees on new text. Please let me know ASAP so that I can make
appropriate modifications.
 
Thanks.
Manisha
 
 
 From: Bassam Tabbara [mailto:Bassam@novas.com] 
Sent: Monday, April 18, 2005 8:46 AM
To: Eduard Cerny; Kulshrestha, Manisha; Surrendra.Dudani@synopsys.com;
sv-ac@eda.org
Subject: RE: [sv-ac] Ballot item 241 proposal


Ed/Manisha/all,
 
I believe (agree with both Ed/Manisha about this) that all cases *are*
clear except the 2 clocks case. The proposal language "particulars" are
more directed at input sampling and skew. Its spirit can be interpreted
to also mean clocks since different clocks would mean some kind of
"double sampling" i.e. illegal. A friendly amendment to the proposal to
cover the clocking aspect being illegal would be good in order to avoid
confusion/misinterpretation.
 
Ed did you have a language fixup in mind that you can propose ? May be
also add the example you wrote and say it's illegal.
 
Thx.
-Bassam.
 
--
Dr. Bassam Tabbara
Architect, R&D
Novas Software Inc.
(408) 467-7893
 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Eduard Cerny
Sent: Monday, April 18, 2005 4:16 AM
To: 'Kulshrestha, Manisha'; 'Eduard Cerny';
Surrendra.Dudani@synopsys.com; sv-ac@eda.org
Subject: RE: [sv-ac] Ballot item 241 proposal


Hi Manisha,
 
I agree with you that there may be not enough time to include some (all)
of the examples. 
 
Nevertheles, I think that the text does not quite cover these cases.
 
Please see my comments below.
 
ed


________________________________

	From: Kulshrestha, Manisha
[mailto:Manisha_Kulshrestha@mentor.com] 
	Sent: Monday, April 18, 2005 2:04 AM
	To: Eduard Cerny; Surrendra.Dudani@synopsys.COM; sv-ac@eda.org
	Subject: RE: [sv-ac] Ballot item 241 proposal
	
	

	Hi Ed,
	
	Please see my inlined comments. I am not sure if we have time to
include some of your suggestions in this proposal.

	 
	Thanks.
	Manisha
	
	I wonder if the examples in Mantis #626 (issue 241) should also
include the following situation:
	
	clocking ck @(posedge clk);
	  input a;
	endclocking
	
	property p3;
	  @ck ck.a;
	endproperty
	
	a5: assert property(p3);
	
	This would be the case of possible double sampling too and it
should state again that the results is the same as in the other cases
a1-a4. Or is this illegal?
	
	I think "a3" is exactly same example in the proposal. The
proposal does not include clocking event of this type (@ck) though. I am
assuming that you are asking about hierarchical reference to a signal
which is clocking block input. The example in the proposal is as
follows: 
	 

Yes, the issue is the hierarchical ref. to a. I agree that it may be
considered equivalent to your example, except it is not explicit and
people may ask. But, let's leave it aside.

	
	
	clocking cb_with_input @(posedge clk);
	  input a;
	 
	  property p1;
	    a;
	  endproperty
	
	endclocking
	
	property p2;
	  @(posedge clk) cb_with_input.a;
	endproperty
	
	a3: assert property (p2);
	
	And an example of the illegal case:
	
	clocking ck @(posedge clk);
	  input #1 a;
	endclocking
	
	property illegal_sampling;
	  @ck ck.a;
	endproperty
	
	a5: assert property(illegal_sampling);
	I am open to adding this example but I am not sure if we have
time for that as Monday is the last day for the ballot approval. I think
the first paragraph in the proposal clearly says that it is illegal. 
	 

OK, if others think that way too.

	 

	-----------
	And what about the following case? Is it legal? If we go by the
timing diagram in the proposal, this would mean resampling the sampled
value by posedge clk by the posedge of clk2:
	
	clocking ck @(posedge clk);
	  input a;
	endclocking
	
	property p4;
	  @(posedge clk2) ck.a;
	endproperty
	
	a5: assert property(p4);

	I think based on the statements in the proposal, it means that
property will read the value sampled by the clocking block and will not
do double sampling at clk2. I think this should be the case to avoid
confusion about which value is being used by the property in case
(posedge clk) and (posedge clk2) occur at the same time. 

Are you saying that this case is legal? Even though the clocks are
different? Either this is illegal or the sampled value by clk is then
resampled by clk2.

	 

	I am not sure how you are interpretting the timing diagrams to
say that this means double sampling. I created timing diagrams to show
that there is no double sampling.  

My statement is because your show the sampled value as a signal waveform
which can again be sampled. 
I think that the case above should be illegal (given that we do not want
to allow resampling in other cases.)

	
	
	----------
	
	ed
	
	
	
	> -----Original Message-----
	> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
Behalf Of
	> Surrendra Dudani
	> Sent: Thursday, April 14, 2005 8:58 PM
	> To: sv-ac@eda.org
	> Subject: [sv-ac] Ballot item 241 proposal
	>
	>
	> Please review ballot issue 241 with Manisha's proposal in
mantis item
	> #626.
	> If I don't hear anything by tomorrow, I'll assume it's ok to
change
	> the status to resolve.
	> Surrendra
	> ****************************************
	> Surrendra A. Dudani
	> Synopsys, Inc.
	> 377 Simarano Drive, Suite 300
	> Marlboro, MA 01752
	>
	> Tel:   508-263-8072
	> Fax:   508-263-8123
	> email: Surrendra.Dudani@synopsys.com
	> ****************************************
	>
	>
	>