RE: Verilog-AMS v2.3/draft4a

Jim,

So far as I can see, my inputs have not yet been recorded in Mantis.

I'm not familiar with the differences between IEEE and Accellera
procedures. 

I would hope other Board members would not just approve the LRM blindly,
but would agree that the errors we have found are serious enough to
require correction first.

The usual IEEE procedure would be for the WG to review the ballot
comments, revise the draft appropriately (the WG can decide not to
implement a specific comment), and then submit the revised draft for a
revote. Usually it passes on the revote. On a revote, a balloter cannot
raise new objections to text that was already there on the first vote. 

That extends the process a few months, but not a year. IEEE WGs don't
assume that draft will pass on the first vote. The IEEE Standards Board
requires that WGs respond to ballot comments seriously.

That's a simplication of the IEEE process also, but it gives a rough
idea of what usually occurs. Karen Pieper is much more familiar with the
procedures.

Regards,
Shalom

> -----Original Message-----
> From: Wilmore, Jim 
> Sent: Monday, July 07, 2008 9:53 AM
> To: Sri Chandra; Bresticker, Shalom
> Cc: Verilog-AMS LRM Committee; Stuart Sutherland
> Subject: RE: Verilog-AMS v2.3/draft4a
> 
> Sri,
> 
> Well, as the Accellera Board member, I am going to check once 
> more with Intel reviewers (mainly Shalom, as the committee 
> has certainly noticed by now), but I suspect a "Conditional" 
> vote is the most likely choice, even though all of his input 
> has been recorded in Mantis for consideration in the next 
> revision of the LRM.
> 
> It seems like it might be worth breaking out the Mantis 
> entries into a few separate items, one for the typo level 
> problems that can be fixed anytime (either sooner because 
> they are "low hanging fruit" or later since any reader will 
> know what is really meant), a second Mantis entry for those 
> errors that Shalom regards as critical for this version of 
> the LRM (these would be the ones that my "Conditional" vote 
> would be referring to), and a third Mantis entry for the 
> remainder - serious by could wait until the next revision.
> 
> Shalom,
> 
> Perhaps almost all the errors you've reported are critical, 
> but if Sri thinks that some errors might be fixed in this 
> version, I think it might be helpful to prioritize them and 
> then identify those you regard as "most important" on the 
> chance that there would be an opportunity to correct some 
> items in this version, as Sri mentioned below.
> 
> Even if Intel votes "Conditional" my guess is most companies 
> will simply vote "Yes" which is why it might help to press 
> for "the top ten" (or maybe only the "top three"), and maybe 
> other member companies might agree that a few highest 
> priority fixes should be made to approve this revision.
> 
> Maybe it's not worth your trouble at this point.  I 
> appreciate all the careful review you've made thus far!  It 
> may also not be worth the trouble changing the Mantis 
> entries.  In any case, there seems to be general inclination 
> to have a V-AMS specification, and I am confident that the 
> Mantis entries will be attended to going forward.
> 
> Sri,
> 
> Do you know when the actual Board vote will occur, or should 
> I check with Accellera folks?
> 
> Thanks,
> 
>  -jim-
> 
> -----Original Message-----
> From: Sri Chandra [mailto:sri.chandra@freescale.com]
> Sent: Sunday, June 01, 2008 5:29 AM
> To: Bresticker, Shalom
> Cc: Verilog-AMS LRM Committee; Stuart Sutherland; Wilmore, Jim
> Subject: Re: Verilog-AMS v2.3/draft4a
> 
> Shalom,
> 
> Sure. I guess there might be some more 
> recommendations/feedback from the various board members. 
> Hopefully there will be an opportunity to get these corrected 
> (at least the critical ones) in this version. Once we hear 
> from the board we will go ahead and do the needful to get the 
> issues addressed.
> 
> Regards,
> Sri
> 
> 
> 
> 
> Bresticker, Shalom wrote:
> > Thanks.
> > 
> > Please understand that I will recommend to my employer 
> entity to make 
> > its vote of approval conditional on correction of certain of these 
> > errors.
> > 
> > Regards,
> > Shalom
> > 
> >> -----Original Message-----
> >> From: Sri Chandra [mailto:sri.chandra@freescale.com]
> >> Sent: Sunday, June 01, 2008 3:03 PM
> >> To: Bresticker, Shalom
> >> Cc: Verilog-AMS LRM Committee; Stuart Sutherland; Wilmore, Jim
> >> Subject: Re: Verilog-AMS v2.3/draft4a
> >>
> >> Shalom,
> >>
> >> Thanks for your comments and the review points on the LRM 
> >> v2.3/draft4a.
> >> I will collate the 3 emails that you have sent with the errata and 
> >> record them on Mantis which the committee can take up and 
> fix in the 
> >> next revision of the LRM. The current standard has been 
> sent to the 
> >> board for consideration at this point.
> >>
> >> I will send you the Mantis reference to you once i have done the 
> >> same, so that you can ensure all points are covered. At 
> this point i 
> >> plan to put these items under one ticket.
> >>
> >> Regards,
> >> Sri
> >>
> >> Bresticker, Shalom wrote:
> >>> Hi,
> >>>
> >>> Clause 3 starts,
> >>>
> >>> "Verilog-AMS HDL supports integer, genvar, real, and 
> parameter data 
> >>> types as found in IEEE std 1364-2005 Verilog HDL. It includes the 
> >>> string data type defined by IEEE std 1800-2005
> >> SystemVerilog. It also
> >>> modifies the parameter data types and introduces array of
> >> real as an
> >>> extension of the real data type."
> >>>
> >>> Comments:
> >>>
> >>> 1. 1364-2005's genvar is not a data type.
> >>> Neither are parameters.
> >>>
> >>>
> >>> 2. Arrays of real already exist in 1364-2005.
> >>> Perhaps the intent was arrays of parameters.
> >>>
> >>>
> >>> 3. 3.3 has the example, two lines before Table 3-3, "r =
> >> {"H",""}; //
> >>> yields "H\0". "" is converted to 8'b0l".
> >>>
> >>> That should be 8'b0, not 8'b01.
> >>>
> >>>
> >>> 4. The BNF non-terminal constant_concatenation is used for array 
> >>> initialization, as in real_type and variable_type in Syntax 3-1, 
> >>> param_assignment in Syntax 3-2, net_assignment in Syntax 3-6, for 
> >>> example.
> >>>
> >>> That non-terminal is missing the apostrophe preceding the curly 
> >>> brackets that 3.4 says is needed: "For parameters defined
> >> as arrays,
> >>> the initializer shall be a constant_param_arrayinit
> >> expression which
> >>> is a list of constant expressions containing only constant
> >> numbers and
> >>> previously defined parameters within '{ and } delimiters."
> >>>
> >>> And the "constant_param_arrayinit" mentioned there does 
> not appear 
> >>> anywhere.
> >>>
> >>>
> >>> 5. In 3.4.2, "The use of brackets, [ and ], indicate
> >> inclusion of the
> >>> end points in the valid range. The use of parenthesis, ( and ), 
> >>> indicate exclusion of the end points from the valid range. It is 
> >>> possible to include one end point and not the other using [
> >> ) and ( ]."
> >>> "parenthesis" should be plural, "parentheses".
> >>> "indicate" should be "indicates", twice.
> >>>
> >>> Regards,
> >>> Shalom
> >>>
> >> 
> ---------------------------------------------------------------------
> >>> Intel Israel (74) Limited
> >>>
> >>> This e-mail and any attachments may contain confidential
> >> material for
> >>> the sole use of the intended recipient(s). Any review or
> >> distribution
> >>> by others is strictly prohibited. If you are not the intended 
> >>> recipient, please contact the sender and delete all copies.
> >>>
> >>>
> >> --
> >> Srikanth Chandrasekaran
> >> Design Technology (Tools Development) Freescale Semiconductor Inc.
> >> T:+91-120-439 5000 p:x3824 f: x5199
> >>
> > 
> ---------------------------------------------------------------------
> > Intel Israel (74) Limited
> > 
> > This e-mail and any attachments may contain confidential 
> material for 
> > the sole use of the intended recipient(s). Any review or 
> distribution 
> > by others is strictly prohibited. If you are not the intended 
> > recipient, please contact the sender and delete all copies.
> > 
> > 
> 
> --
> Srikanth Chandrasekaran
> Design Technology (Tools Development)
> Freescale Semiconductor Inc.
> T:+91-120-439 5000 p:x3824 f: x5199
> 
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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