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

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>
To: Sri Chandra <sri.chandra@freescale.com>; Dave Miller
<David.L.Miller@freescale.com>
Cc: Verilog-AMS LRM Committee <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] 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>
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. 
---------------------------------------------------------------------
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. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.