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>
>> To: Verilog-AMS LRM Committee<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
>

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

attached mail follows:

attached mail follows: