[sv-ac] RE: 1698 for review

<forwarding bounced email from Lisa Piper>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

attached mail follows:

Thanks Ed!  I'll try to get this updated late this afternoon.  I agree
with everything, especially the comment that we should allow always_ff.
I guess when I have read "always" I have always interpreted it
generically, but when it comes to clock inferencing I think it should be
limited to always and always_ff 

 

Lisa

 

________________________________

From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] 
Sent: Monday, January 21, 2008 9:52 AM
To: Lisa Piper; sv-ac@eda.org
Cc: Eduard Cerny
Subject: RE: 1698 for review

 

Hi Lisa,

 

Please see below my comments regarding the proposal.

 

Best regards,

ed

 

---------------------------

- introduction and then page 3: 

 

"Since synthesized code executes in the active region, use the
past_variable directly. Provided that the

model follows synthesis rules and is not race-free, the behavior should
be equivalent to that in the original

model using $past. The other functions, $rose, $fell and $stable
follow."

 

I think that it should say:

 

"Since synthesized code executes in the active region, the past_variable
directly in place of $past. Provided that the model follows synthesis
rules and is race-free, the behavior is equivalent to that in the
original model using $past. The other functions, $rose, $fell and
$stable follow."

 

- Alignment of bullets 3rd paragraph below the above text.

 

- I do not particularly like clock inference in action blocks... but I
am not sure we can change that.

 

- I was searching past proposals if there is anything that changes use
of concurrent assertions in always blocks to also allow always_ff. I did
not find anything. Strange... Did I miss something? Yet, you have an
example of inference from always_ff. Should we change the section of
assertions in procedures to allow always_ff?

 

- page 5, change (?) "In contrast, a clock cannot be inferred from the
following because more than one edge trigger exists:"

 

to

 

"In contrast, a clock cannot be inferred from the following because more
than one edge exists in the event control:" 

 

- page 6, change (?) "In the following example, a clock cannot be
inferred due to there being multiple event controls and delays."

 

to

 

"In the following example, a clock cannot be inferred due to multiple
event controls and delays in the always procedure."

 

 

change(?) 

 

"The existence of a second event control or a timing delay prevents
clock inferencing."

 

to

 

"The existence of a second event control and timing delays prevents
clock inferencing."

 

- Should these examples in 16.14.5 also include the use of sampled-value
functions in assignments? And/or, use always_ff for clock inference in
these functions in the examples in 16.8.3?

 

 

 

 

 

 

 

 

 

	
________________________________


	From: Lisa Piper [mailto:piper@cadence.com] 
	Sent: Tuesday, January 15, 2008 4:51 PM
	To: Eduard Cerny
	Cc: sv-ac@eda.org
	Subject: 1698 for review

	Hi Ed,

	Here is the 1698 proposal for review.  It is also on Mantis.

	Lisa

	<<1698_svf_080115.pdf>> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.