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

Hi All,

I've seen this thread on sv-ac and as it's becoming an issue, I decided to 
send a clarification note to all.

First, I'd like to provide some background to this: A note titled "
SystemVerilog (P1800) and Verilog (P1364) Draft Documents Available" was 
sent on 1/17 to all technical committees to notify that documents for 
SystemVerilog and Verilog were available for download and review under 
eda.org. It explained that in order to keep w/ IEEE-SA staff directives to 
protect the IP rights of the IEEE, these draft documents are password  and 
a password was sent to the WG DR. It also mentioned that if an entity is 
not an IEEE-SA Corporate member that has membership credentials in the 
SystemVerilog Working Group, it will need to make a request to the chair 
(myself), so that I can check a possible exemption for this policy.

At this stage of the process, I must also check w/ IEEE on exceptions that 
I decide to make (i.e. after I am convinced an exception should be made).

In this case, as Freescale and Novas are part of the issues resolution 
committee (and both have been active contributing members of sv-ac for a 
long time), I see a good reason why John and Bassam need to have access to 
the draft. Having said that, I still need to check w/ IEEE and get 
clearance for this. 

I'll get back to you on this.

Regards,

--- Johny.






"Bassam Tabbara" <bassam@novas.com> 
Sent by: owner-sv-ac@eda.org
04/01/2005 12:43 PM
Please respond to
bassam


To
"'Eduard Cerny'" <Eduard.Cerny@synopsys.com>, 
<john.havlicek@freescale.com>
cc
<sv-ac@eda.org>, <fhaque@cisco.com>, <Surrendra.Dudani@synopsys.com>, 
"'Karen Pieper'" <Karen.Pieper@synopsys.com>
Subject
RE: [sv-ac] FW: P1800 AC issues






Ed, FYI, I (suspect also John) don't even have D4, D3 was the last
"distributed" LRM as far as I know. 

I don't want to make a big deal out of this (so please no far-reaching
emails), but just in case anyone is in the same boat as I, there seems to 
be
an issue with getting the LRM if you're not on IEEE-SA. I've put a tracer 
on
this (request to Johny/Karen), also Novas is trying to get the LRM through
Accellera (itself an IEEE-SA entity, Dennis working on this I believe), 
but
apparently we can purchase a copy from IEEE (tracking this...). 

** I promise to share the info with all if you're not a member (individual
or company) of IEEE-SA. If you are then no prob just get in touch with 
your
DR.

Thx.
-Bassam. 


--
Dr. Bassam Tabbara
Architect, R&D
Novas Software, Inc.
(408) 467-7893

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Eduard
Cerny
Sent: Friday, April 01, 2005 10:29 AM
To: john.havlicek@freescale.com; Eduard.Cerny@synopsys.com
Cc: sv-ac@eda.org; fhaque@cisco.com; Surrendra.Dudani@synopsys.com; 'Karen
Pieper'
Subject: 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?
> > 
> > ----------------
> > 
> > 
>