Re: Verilog-AMS Committee Call - 12th May 2011

I'm aware there's no SV-AMS/1800.1 committee, that's what's bothering me. If Accellera creates a draft 1800.1 document I was under the impression that there will be some vote to accept it at the IEEE. Given the reluctance to incorporate Verilg-AMS features in SV-DC (e.g. disciplines), I find it hard to believe the votes are there for absorbing Verilog-AMS in it's entirety. Is the creation of the 1800.1 guaranteed, and what's the current time-line on that?

Can someone put up the details of the merger process on the Wiki?

I'm not seeing how doing this work under Accellera speeds up the process, it'll be pretty much the same people working on the stuff whether it's under Accellera or the IEEE, and since the IEEE committees work on fairly fixed cycles you want to get in there as early as possible to synchronize with the rest of 1800.

Kev.

On 05/15/2011 02:26 AM, Bresticker, Shalom wrote:
>
> An Accellera committee can work much faster and flexibly than an IEEE committee.
>
> There is not going to be an 1800.1 committee at this time.
>
> Shalom
>
> *From:*Kevin Cameron [mailto:edaorg@v-ms.com]
> *Sent:* Sunday, May 15, 2011 12:23 PM
> *To:* Bresticker, Shalom
> *Cc:* Verilog-AMS LRM Committee
> *Subject:* Re: Verilog-AMS Committee Call - 12th May 2011
>
>
> I'm not seeing the point of doing all this alignment of BNF etc. in the Accellera committee. Why not just donate whatever it is that's current, and work with it as 1800.1? Presumably any official 1800.1 release would align with corresponding 1800 and not some prior release?
>
> Kev.
>
>
> On 05/15/2011 01:04 AM, Bresticker, Shalom wrote:
>
> 1800 is not doing SV-AMS integration at this time.
>
> The agreement was for this committee to make something that would be donated to IEEE and become a "dot standard", 1800.1.
>
> Shalom
>
> *From:*owner-verilog-ams@eda.org <mailto:owner-verilog-ams@eda.org> [mailto:owner-verilog-ams@eda.org] *On Behalf Of *Kevin Cameron
> *Sent:* Sunday, May 15, 2011 11:01 AM
> *To:* Verilog-AMS LRM Committee
> *Subject:* Re: Verilog-AMS Committee Call - 12th May 2011
>
>
> [resend to reflector]
>
> Integrating Verilog-AMS isn't in the SV-DC's remit, is the SV-EC responsible or should there be a SV-AMS committee?
>
> I would suggest forming an SV-AMS committee under 1800 with the sole purpose of doing the integration, and push all the work over there. Doing this work under the Accellera banner seems likely to result in nothing being integrated to me.
>
> Kev.
>
> On 05/13/2011 09:04 AM, Cary R. wrote:
>
> Hi Shalom,
>
> I think we need to discuss possible changes here first, but I agree the relevant changes should be pushed to SV. I'm assuming our representative will do that at the appropriate time. The reason I think this needs to be discussed here first is that we need to make sure the discrete real to continuous time real interface makes sense. I also think we as a group have much more experience modeling analog blocks/functionality then the SV group so we likely understand the subtleties better.
>
> Regards,
>
> Cary
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> *From:*"Bresticker, Shalom" <shalom.bresticker@intel.com> <mailto:shalom.bresticker@intel.com>
> *To:* Sri Chandra <sri.chandra@freescale.com> <mailto:sri.chandra@freescale.com>; Dave Miller <David.L.Miller@freescale.com> <mailto:David.L.Miller@freescale.com>
> *Cc:* Verilog-AMS LRM Committee <verilog-ams@eda.org> <mailto:verilog-ams@eda.org>
> *Sent:* Wed, May 11, 2011 10:33:21 PM
> *Subject:* RE: Verilog-AMS Committee Call - 12th May 2011
>
>
>
> Hi, Sri.
>
> I'll accept whatever the committee decides.
>
> But I don't see what you have described as being consistent with what Dave and Cary have described.
>
> You wrote, "we will just create an extensions document using the base framework (stylesheets etc) from P1800 document. The advantages of doing this is, we do not have P1800 (digital-only) living in 2 different documents - one the P1800 standard and the other one being the "SV-AMS" standard, and also avoids unnecessary updates/releases to SV-AMS document if there are changes in P1800"
>
> I don't think that is consistent with a self-contained standard.
>
> I'm also not sure that Dave and Cary's concept is what the 1800 working group had in mind when an 'extensions document' was discussed.
>
> I don't ignore the advantages of a self-contained document, but it is more difficult to keep consistent with 1800 and more work also. You also get into questions like, if there is a difference between what is written in the two, which takes precedence? If something appears in 1800 but not in the SV-AMS LRM, is it part of SV-AMS or not?
>
> Regarding Cary's specific questions, I think the guiding principle should be that unless you are intending to differ from 1800 in a particular place, you should just copy the 1800 text as it is, even if it could be improved. Suggestions for improvement should be sent to 1800.
>
> Regards,
> Shalom
>
> *From:*owner-verilog-ams@eda.org <mailto:owner-verilog-ams@eda.org> [mailto:owner-verilog-ams@eda.org] *On Behalf Of *Sri Chandra
> *Sent:* Thursday, May 12, 2011 7:27 AM
> *To:* Dave Miller
> *Cc:* Verilog-AMS LRM Committee
> *Subject:* Re: Verilog-AMS Committee Call - 12th May 2011
>
> Dave,
>
> Your thought in how we are planning to do the merger of SV with Verilog-AMS is consistent in what was discussed in the committee. I have attached the relevant minutes.
>
> Based on discussions within the technical Verilog-AMS committee and also with the P1800 committee it was decided that we will just create an extensions document using the base framework (stylesheets etc) from P1800 document. The advantages of doing this is, we do not have P1800 (digital-only) living in 2 different documents - one the P1800 standard and the other one being the "SV-AMS" standard, and also avoids unnecessary updates/releases to SV-AMS document if there are changes in P1800; also the release timelines will be different for P1800 and SV-AMS. Of course, as discussed earlier, we need to be aware of any changes that might potentially affect or conflict with what we have in Verilog-AMS.
>
> Regards,
> Sri
>
> On 5/12/2011 2:30 AM, Dave Miller wrote:
>
> Thank you all for the feedback.
> Marq - item 2266 was closed because the final resolution was to just change the section 3.6.2.1 which was done for 2.3.1. However this never addressed the other issues that we held off on due to potential backward compatibility problems.
> I have reopened this ticket.
>
> Shalom - yes, should be String literal. I will go through carefully and correct the ones I missed.
>
> With regards to referring to SV doc. My thinking on the matter was that regardless of what we call the standard whether it be Verilog-AMS or SystemVerilog-AMS, a very large percentage of users refer only to the analog subset (Verilog-A). My idea was to ensure that the standard is a self contained reference for the analog modeling community, there should be no reason an analog device model developer should have to refer to a digital standard if implementing the analog subset of this language. So if a feature is pure digital, then yes, we should just refer to 1800, but for items that affect the analog subset, or extend the digital, or are mixed signal, then we should detail it in this doc.
> At least that was how I was looking at it.
>
> Cary - I will try to address the items you list below tonight and update the doc before tomorrow's call.
>
> Cheers...
> Dave
>
>
> On 05/11/2011 01:40 PM, Cary R. wrote:
>
> Here is a list of issues I found while reading the draft, but first.
>
> Regarding Shalom's suggestion to use 1800-2009 as the base for this
> specification like was done for 1800-2005; I believe that would be a poor
> choice. 1800-2005 was an extension to the functionality in 1364-2005 that was
> intended to eventually be merged anyway, so it made complete sense that it used
> the other as a reference (base). This specification or at least the Verilog-A
> portion is completely independent so I don't see the linkage. My understanding
> is that this revision is trying to make the Verilog-A definition compatible with
> 1800-2009 (Verilog-D). To me, that requires that the common descriptions be
> updated to match what is in 1800-2009 not repalced with references to 1800-2009.
> I would agree that the digital descriptions belong in 1800-2009, but the analog
> definitions and the Verilog-A/Verilog-D interface should be fully specified in
> this document not split between this document and 1800-2009. If someone is only
> interested in Verilog-A they should not also need 1800-2009 to understand the
> specification.
>
> I'm new to the discussion so I may be misunderstanding the purpose of this
> revision. I'm sure any misunderstanding will be corrected shortly ;-).
>
>
> Section two errata.
>
> Page 10, section 2.3:
> spaces, tabs, newlines, and formfeeds are used to define
> white space, but in the last paragraph blanks and tabs are
> used when describing string literals. What is the definition
> of blanks (should this be spaces).
>
> Page 10, syntax 2-1:
> I believe the \n should be in red.
>
> Page 11, syntax 2-1:
> Should \n be excluded from the comment_text definition? Should
> all non-printing characters be excluded?
>
> Page 12, section 2.6.3, 1st sentence:
> This should be user-defined "system" tasks and functions.
> Normal user-defined tasks and functions use a different syntax.
>
> Page 12, syntax 2-2:
> Remove the task_enable syntax since this is describing system
> tasks/function. Add that an analog_system_task_identifier is
> defined to be a system_task_identifier. Also add a definition
> for the analog_system_function_identifier.
>
> Page 13, syntax 2-3:
> The non_zero_unsigned_number should have footnote 2 and the
> "_" character should be in red.
>
> Page 14, section 2.7.1, 6th paragraph:
> The text describes that the number should immediately follow
> the format, but then contradicts this by saying a space is
> allowed between the format and the number. I believe that the
> word "immediately" should be removed.
>
> Page 15, example 2, second line:
> There needs to be a 5 before the `D to make this a 5-bit value.
>
> Page 16, section 2.7.1, last sentence:
> Which X/Z is this sentence referring to?
>
> Page 16, section 2.7.2, 2nd paragraph:
> Add that an underscore cannot be the first character of the
> exponent.
>
> Page 17, section 2.7.3:
> I've always found this section significantly under specified.
> For example:
>
> How should X/Z be handled when converting to real?
>
> For large positive/negative real values there are no LSBs
> so should we really use zero for the bit based value?
>
> In discrete real modeling generating +-inf or NaN is a
> possibility how should these be converted?
>
> I have some personal opinions on what should be done, but I'll
> save them for future a discussion since this email is focusing
> on errata. Maybe this section should be marked "Needs more
> discussion before release."
>
>
>
>
> ----- Original Message ----
> From: Dave Miller<David.L.Miller@freescale.com> <mailto:David.L.Miller@freescale.com>
> To: Verilog-AMS LRM Committee<verilog-ams@eda.org> <mailto:verilog-ams@eda.org>
> Sent: Tue, May 10, 2011 7:10:04 PM
> Subject: Verilog-AMS Committee Call - 12th May 2011
>
> Hello all,
> We have a call scheduled for Thursday 12th May 2011.
>
> Agenda:
> * Review of Chapter 2 - Lexical conventions. Document can be found at:
> http://www.eda.org/twiki/bin/view.cgi/VerilogAMS/SVAMSSectionWork#2_Lexical_conventions
>
>
> * Update on Verilog-AMS representation in the SV-DC.
>
>
> Call Time: (Thursday 01.00pm UTC):
>
> San Francisco, Thurs 06.00a
> Austin, 08.00a
> Boston, 09.00a
> Amsterdam, 03.00p
> Tel Aviv, 04.00p
> New Delhi, 06:30p
> Adelaide, 10:30p
>
> Call-In Details:
> USA Toll Free : 8008671147
> Australia Toll Free: 1800009128
> India Toll Free : 0008006501482
> Netherlands : 08002658223
> Passcode: 0970751#
>
> Cheers...
> Dave
>
>
>
> ---------------------------------------------------------------------
> 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.