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

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

-- 
==============================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
==============================================
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.