RE: [sv-ac] RE: [sv-bc] Email ballot: Respond by Friday, Februrary 29, 8am PST

From: Eduard Cerny <Eduard.Cerny_at_.....>
Date: Tue Mar 04 2008 - 14:57:01 PST
Doug,

Glad to hear that.... :-)

Best regards,
ed

> -----Original Message-----
> From: Warmke, Doug [mailto:doug_warmke@mentor.com]
> Sent: Tuesday, March 04, 2008 5:53 PM
> To: Eduard Cerny; sv-bc@eda.org; Sv-ac@eda.org
> Subject: RE: [sv-ac] RE: [sv-bc] Email ballot: Respond by Friday,
> Februrary 29, 8am PST
> 
> Ed,
> 
> This looks good.
> 
> Thanks!
> Doug
> 
> -----Original Message-----
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> Sent: Tuesday, March 04, 2008 10:01 AM
> To: Warmke, Doug; sv-bc@eda.org; Sv-ac@eda.org
> Subject: RE: [sv-ac] RE: [sv-bc] Email ballot: Respond by Friday,
> Februrary 29, 8am PST
> 
> Hello,
> 
> Please find attached a modified proposal for 1769. Hopefully it
> addresses all the outstanding issues.
> 
> Regards,
> ed
> 
> 
> > -----Original Message-----
> > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> > Warmke, Doug
> > Sent: Monday, March 03, 2008 1:29 PM
> > To: sv-bc@eda.org; Sv-ac@eda.org
> > Subject: [sv-ac] RE: [sv-bc] Email ballot: Respond by Friday,
> Februrary
> > 29, 8am PST
> >
> > Hello SV-AC,
> >
> > As discussed in the meeting of March 3rd, some of the comments
> > on 1769 were correctly incorporated, but others were not.
> >
> > This email should be considered the response from SV-BC on this
issue.
> >
> > The remaining issues that should be addressed:
> >
> > 2. Change "severity task" to "severity system task".
> >    This is necessary for consistency and clarity.
> >    Also, in the first paragraph where the term
> >    "severity system task" is first introduced,
> >    a cross-reference to 19.9 "Severity System Tasks"
> >    is required.
> > 3. The phrase "...their activation may be controlled..."
> >    in the first paragraph should be changed to
> >    "...their activation can be controlled..."
> > 4. The term "generate block" should be replaced with
> >    "generate construct" throughout the proposal.
> > 5. Two usages of "will" are still in the proposal.
> >
> >    To be specific, the following usage of "will" should
> >    be changed to "shall".
> >
> >       "If $fatal is executed then after outputting the message the
> > elaboration may be aborted, and in no case simulation will be
> executed."
> >
> >    The following sentence should be changed as follows:
> >    OLD:
> >       "Elaboration system tasks are used to indicate if the vector
is
> just
> > a 1-bit vector, otherwise it will issue information messages
> indicating
> > which conditional branches were generated."
> >
> >    NEW:
> >       "Elaboration system tasks are used to indicate if the vector
is
> only
> > a 1-bit vector, otherwise informational messages are issued that
> indicate
> > which conditional branches were generated."
> >
> > Regards,
> > Doug Warmke
> >
> >
> >
> >
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On
> > Behalf Of Warmke, Doug
> > Sent: Saturday, February 23, 2008 6:17 AM
> > To: sv-bc@server.eda.org
> > Subject: RE: [sv-bc] Email ballot: Respond by Friday, Februrary 29,
> 8am
> > PST
> >
> > Doug's Votes:
> >
> > SVDB 1526 _X_Yes   ___No
> > http://www.eda.org/svdb/view.php?id=1526
> > Proposal:
> > Covered by resolution of SVDB 1707
> > http://www.eda.org/svdb/view.php?id=1707
> >
> > SVDB 1709 _X_Yes   ___No
> > http://www.eda.org/svdb/view.php?id=1709
> > Proposal:
> > Covered by resolution of SVDB 1707
> > http://www.eda.org/svdb/view.php?id=1707
> >
> > SVDB 1769 ___Yes   _X_No
> > http://www.eda.org/svdb/view.php?id=1769
> >
> > Will change vote to Yes once the following have been resolved.
> > (Some are very minor)
> > 1. The $warning task in the intro area has an extra space after the
> '$'.
> > 2. The term "error task" is used in several places in this proposal.
> >    It should be "severity system task", in light of approved Mantis
> 1641.
> >    A cross-reference to "19.9 Severity System Tasks" should be made,
> too.
> > 3. In terms of generate constructs, why only conditional generates?
> >    These would be useful in case and loop generates as well.
> >    In fact, your 2nd example contains a usage inside loop generate.
> > 4. s/generate block/generate construct/g
> > 5. Various "will" should be "shall", as per IEEE convention
> > 6. In the first example, there is a module with a
parameter_port_list
> >    that contains an assignment to the illegal value of 12.  In light
> >    of Mantis 907, I think you should simply leave off that "= 12".
> >    That would indicate that the user of the module is expected to
> >    provide a parameter value, and that the parameter value better
> >    be legal.  One more minor suggestion would be to change the user
> >    error message in this case to indicate the legal range of values.
> >    Was:
> >      $error("Parameter N has an invalid value of %0d", N);
> >    Could be:
> >      $error("Parameter N has an invalid value of %0d. Legal values
are
> 2
> > through 7, inclusive.", N);
> > 7. The generate/endgenerate in the 2nd example is not necessary.
> >    But it could be kept for the clarity of the example.
> >
> > SVDB 2089 ___Yes   ___No   _X_ Abstain
> > http://www.eda.org/svdb/view.php?id=2089
> >
> > Checkers is a huge topic.
> > I haven't had time to digest it fully, thus my abstention on this.
> > In general this addition to 1900 seems reasonable to me, though,
> > in terms of the incremental additions.
> >
> > Regards,
> > Doug
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Mar 4 14:58:31 2008

This archive was generated by hypermail 2.1.8 : Tue Mar 04 2008 - 14:58:45 PST