Hi Jim, Thanks for your email and also suggested approach. We are planning to review the comments posted by Shalom (and any others that we might receive before that from the board members). I was thinking of classifying them on a per-chapter basis based on the email sent by Shalom before the committee meeting so that its easy for the meeting. Once the meeting is done, any serious errors or typos that are not planned for fixing we can open separate items to close them in future revisions. We will also try & document why its not planned for fix as part of current version, if any, so that it can be referred by the original authors who raised the problem. Hopefully we can arrive at consensus within the committee and the members and move forward on release of this version. Regards, Sri Wilmore, Jim wrote: > 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 > -- Srikanth Chandrasekaran Design Technology (Tools Development) Freescale Semiconductor Inc. T:+91-120-439 5000 p:x3824 f: x5199 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Jul 7 00:50:08 2008
This archive was generated by hypermail 2.1.8 : Mon Jul 07 2008 - 00:50:12 PDT