Re: [sv-ac] FW: P1800 AC issues

Ed:

Where is the latest draft of the LRM?  I will look at #217 and #128
when I know where to find the draft.

Best regards,

John H.

> X-Authentication-Warning: server.eda.org: majordom set sender to owner-sv-ac@eda.org using -f
> From: "Eduard Cerny" <Eduard.Cerny@synopsys.com>
> Cc: "Surrendra Dudani" <Surrendra.Dudani@synopsys.com>,
>         "'Eduard Cerny'" <Eduard.Cerny@synopsys.com>
> Date: Thu, 31 Mar 2005 17:40:26 -0500
> Thread-Index: AcU2Gov2KmZwKktfQaGDFkDRAa+C8AAJlyzA
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441
> X-Virus-Status: Clean
> X-Virus-Status: Clean
> Sender: owner-sv-ac@eda.org
> 
> Hello Faisal and all,
> 
> We went (Surrendra and I) through the issues listed under AC on the spread
> sheet. Please find below an initial analysis.
> 
> Best regards,
> 
> ed
> 
> ----------------
> #20: The return value should be defined as a single bit unsigned bit type
> with
> the value 0 as false and 1 as true.
> True and false are defined in the first paragraph of 18.4 for other
> purposes. 
> Also, 'define true 1 is defined on pp. 215.
> 
> #92: There seems to be no issue here. Please see mantis item 508.
> 
> #209: Change the example to use "assert property" instead of "assert" only.
> 
> #217: Since it deals with formal semantics, perhaps John could look at
> this... :-)
> 
> #218: I think that the author has a confusion in how properties are used.
> The property in itself does not imply either always or once only, it is only
> when placed in an assert and then in either initial or optionally always
> where it gets its evaluation quantifier.  
> I am not convinced that these additional verification statements are needed.
> 
> #220: This is a syntactic sugar which could be added. But, the user has the
> option to define p_imply(p1, p2) as (not p1) or p2, and use that as a
> primitive. Since it is an enhancement, it should be done in the future.
> 
> #221:  @(1'b1) would never trigger. Also, to refer to the context clock can 
> be achieved by passing the external clock name as the actual argument 
> to a property instance. It seems that this enhancement is not needed.
> 
> #222: This is already allowed. tf_port_list includes this.
> 
> #284: The value of the number of clock ticks should be non-negative.
> Correction is needed.
> 
> #241: It seems that any other sampling than #1step (the default) should
> produce an error. Resampling a sampled value could lead to confusion of what
> exactly the value is.
> 
> #128: I could not find what the problem is in 8.4.1. Please refer to mantis
> item 408. Perhaps John could look at it...
> 
> #210: This is already corrected in D4.
> 
> #211: Already corrected in D4
> 
> #212: Corrected in D4, also the proposed correction is actually incorrect.
> 
> #213: I do not think that the ; is missing because pass_stat could be begin
> ... end with no ;. Perhaps define that pass_stat and fail_stat are general
> statements? Or add the ; ?
> 
> #214: Should be corrected.
> 
> #219: Editorial correction?
> 
> #266: Editorial correction?
> 
> ----------------
> 
>