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

Actually that is a good question because i have D4 only, it is not the last
I believe. Perhaps Faisal or Karen can help.

ed
 

> -----Original Message-----
> From: John Havlicek [mailto:john.havlicek@freescale.com] 
> Sent: Friday, April 01, 2005 11:13 AM
> To: Eduard.Cerny@synopsys.COM
> Cc: sv-ac@eda.org; fhaque@cisco.com; 
> Surrendra.Dudani@synopsys.COM; Eduard.Cerny@synopsys.COM
> Subject: 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?
> > 
> > ----------------
> > 
> > 
>