Re: Draft3 review comments/feedback

From: Sri Chandra <sri.chandra_at_.....>
Date: Tue Apr 15 2008 - 09:04:19 PDT
Stu,

I have attached the relevant emails. Sorry for spamming you (and others) 
with the old emails.

With regards to draft4 please make any corrections that are clear from 
an editing point of view from the emails and the minutes.

If you are able to document things that are being discussed but unclear 
from editing or how should proceed (from the list of these emails) that 
will be great. We will also look at the messages that i have attached in 
the upcoming call and see whether there are anything that needs to be 
clarified.

Regards,
Sri


Stuart Sutherland wrote:
> Sri,
> 
> In a quick comparison to your list, it appears that I am missing one of
> Geoffrey's messages, but I cannot tell for sure which one.  I also do not
> have a message from Ken Kundert or from Dave miller in my folder.
> 
> More importantly, many of comments in the messages that I have are either
> comments or questions to the committee.  They are not specific directions on
> editorial corrections that need to be made.
> 
> I think the committee, or someone from the committee, needs to go through
> these e-mails and make two lists: 1) EXACT changes the editor needs to make,
> and 2) subjects the committee needs to resolve.
> 
> Based on a cursory scan, the notes in the two sets of minutes are explicit
> enough for me to work with for editorial changes.  It is the comments and
> questions in the various e-mails that need to be collected and made more
> specific.
> 
> When would you like to see draft 4?
> 
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Stuart Sutherland
> stuart@sutherland-hdl.com
> +1-503-692-0898
> 
>> -----Original Message-----
>> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
>> Behalf Of Sri Chandra
>> Sent: Tuesday, April 15, 2008 4:25 AM
>> To: Verilog-AMS LRM Committee; Stuart Sutherland
>> Subject: Draft3 review comments/feedback
>>
>>
>> Stu,
>>
>> I just wanted to understand from your end whether you have all the
>> comments/feedback on draft3. I understand there were minutes, but some
>> of the other comments came as just emails. I am not sure how exactly to
>> track these to make these updates in draft4 of the LRM. Its not easy to
>> skim through the additional emails, unless there is Mantis raised for
>> each, but some of them are bit trivial fixes. What do you suggest on
>> how
>> to proceed.
>>
>> I have recorded the following minutes and emails that have been sent
>> across that needs to go into draft4 of the LRM.
>>
>>
>> Minutes of Meetings:
>> ====================
>> * Meeting minutes - 27th March 2008 (with follow up email from Shalom
>> Bresticker on the apostrophe for concatenation). We can correct the
>> example as he has specified to be consistent with IEEE P1800.
>> * Meeting minutes - 3rd April 2008
>>
>> Additional messages from members:
>> =================================
>> Some of the below items were captured in the minutes, but probably not
>> all.
>> * enable argument missing in BNF for cross - email from Dave miller on
>> 3rd April (Dave - can you raise a mantis with a small proposal on this
>> please)
>> * Mantis on V(n1,n1): http://www.verilog.org/mantis/view.php?id=2345
>> * Email from Ken Kundert, 28th March 2008 (Comments on Version 2.3
>> draft 3)
>> * Email from Geoffrey Coram, 28th March 2008 (Re: Comments on Version
>> 2.3 draft 3)
>> * Email from Xavier Bestel, 28th March 2008 (Re: Comments on Version
>> 2.3
>> draft 3)
>> * Email from Geoffrey Coram, 28th March 2008 (Re: Comments on Version
>> 2.3 draft 3): regarding _ missing in the BNF
>> * Email from Geoffrey Coram, 28th March 2008 (Re: Comments on Version
>> 2.3 draft 3): Starts with comments from Page 152 (169 of PDF)
>> * Email from Geoffrey Coram, 28th March 2008 (Re: Comments on Version
>> 2.3 draft 3): talks about `define and `undef
>>
>> Regards,
>> Sri
>> --
>> 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.
> 
> 
> 

-- 
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.


attached mail follows:


10.4 `define and `undef

The editor asks about `undef and __VAMS_


To avoid conflicts with predefined Verilog-AMS macros (10.5),
the ‘define compiler directive’s macro text shall not begin
with __VAMS_. The ‘undef compiler directive shall have no
effect and can issue a warning.


This paragraph has a couple problems: the "macro text" can
begin with __VAMS_, it's the text_macro_identifier (1364-2005,
clause 19.3)

I believe the last sentence should read

The `undef compiler directive shall have no effect on
predefined Verilog-AMS macros; the simulator may
issue a warning for an attempt to undefine one
of these macros.


-Geoffrey

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




attached mail follows:


Page 152 (169 of PDF): the contribution statement still says
   V(anet) <+ var;

where all other "var" instances were changed to "AnalogVar"


Page 188 (205 of PDF): "will schedule it’s wake-up"
s/it's/its

This appears a second time in the same paragraph; it might
be worth a global search for "it's" to make sure the contraction
is wanted, else replace with the possessive.


Page 190 (207 of PDF): ddiscreteo; looks like a space is needed,
may just be a font kerning problem.


Page 220 (237 of PDF): we need to remove the non-variable
options for the seed argument for consistency with 1364.
I'd go ahead and remove the type_string, also, and make this
just a copy of the 1364 function.

The AMS-only $rdist functions can keep their type_string
and integer_parameter_identifier.

-Geoffrey

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




attached mail follows:


Ah, well, then the second underscore is missing; there's
a space between analog_function and statement.

-Geoffrey


David Miller wrote:
> No it was deliberate.
> analog initial blocks can only contain the same subset of statements / 
> expressions that are allowed in Analog UDFs. i.e. they can't contain 
> contributions, analog filter functions (ddt,idt, etc.)
> 
> So that is why analog_function statement is used in this context- but 
> yes it is a little confusing. Maybe the analog_function_statement could 
> be renamed to something more meaningful to both analog UDF's and initial 
> blocks, but I can't think of anything - perhaps 
> analog_independent_statement ?
> 
> Dave
> 
> Geoffrey.Coram wrote:
>> Page 89 (106 of PDF):
>>
>> analog initial analog_function statement
>>
>> I think "analog_function" was accidentally copied.
>>
>> -Geoffrey
>>
> 

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



attached mail follows:


So definitely an underscore is missing from that statement:

analog initial analog_function_statement

The same is true for the BNF on page 345 (362 of the PDF).

I have no problem with the name of the analog_function_statement syntax
rule.

Cheers,
Marq


owner-verilog-ams@server.eda.org wrote on 28-03-2008 16:58:22:
> No it was deliberate.
> analog initial blocks can only contain the same subset of statements /
> expressions that are allowed in Analog UDFs. i.e. they can't contain
> contributions, analog filter functions (ddt,idt, etc.)
>
> So that is why analog_function statement is used in this context-
> but yes it is
> a little confusing. Maybe the analog_function_statement could be renamed
to
> something more meaningful to both analog UDF's and initial blocks,
> but I can't
> think of anything - perhaps analog_independent_statement ?
>
> Dave
>
> Geoffrey.Coram wrote:
> > Page 89 (106 of PDF):
> >
> > analog initial analog_function statement
> >
> > I think "analog_function" was accidentally copied.
> >
> > -Geoffrey
> >
>
> --
> =====================================
> -- 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.
>
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.





attached mail follows:


Ken Kundert wrote:
> Turn on generation of hyperlinks, so it is easy to navigate PDF file.
> 
> Page v:
> Ken Kundert, Designers Guide LLC --> Ken Kundert, Designer's Guide 
> Consulting
> Xpedion Design Systems --> Agilent
> (c) 2007 --> (c) 2008


There are a lot of 2007's in the document:
page 1, Copyright 1999-2007
footer on all pages

On page v, affiliations:
There's an extra ) after Waterloo.
I think Kevin Cameron recently moved from Sonics to ?
There's no affiliation listed for Paul Floyd.


The roman-numeral numbering restarts on page 7 of the PDF file
with the table of contents.

On the second iii, 9 of the PDF, "analog initial block"
should start with a capital A.


Page 30 (47 of the PDF) has a cross-ref to 3.2.1, but this
section has now been eviscerated; the cross-ref should
probably be to 4.2.1.1 or 4.2.1.2

Page 30 (47 of the PDF) has an editor's note asking if ' is
necessary for the list of values for a string parameter:
   parameter string gatetype = "nmos" from {"nmos", "pmos"};

I don't have an answer to that, but I do note that the braces {}
need to be red (required syntax item) in Syntax 3-2 and in
A.2.5 for value_range.


I'm OK with "gatetype" on page 31 (48 of the PDF) for mos,
but that doesn't work for the ebersmoll (a BJT model) on
page 32 (49 of PDF).  Please use "bjttype" (though type is
in common use in many existing Verilog-A compact models --
I guess we'll need some sort of `begin_keywords to prevent
trouble with the SV keyword "type").


Page 38 (55 of PDF): I have no idea what "multi-disciplinaries"
are; I'd suggest rewording to "multi-disciplinary systems."


I'm a little puzzled about 4.2.1.2:
   Individual bits that are x or z in the net or the variable
   shall be treated as zero upon conversion.

Is this applicable for AMS?  I'm not sure we deal with bits.


Page 67 (84 of the PDF): several of the items in Syntax 4-2
are not "analog_filter_functions": ddx, ac_stim, white_noise,
flicker_noise, noise_table -- and they should not be subject
to the same restrictions as the true analog operators that
require state information.

For the true analog operators, idt, idtmod, etc.: why don't
sections 4.5.4 and 4.5.5 (etc.) refer to Syntax 4-2?  Since
ddx() is not an analog filter, it's not a good idea to put
this syntax in 4.5.6.

Page 88 (105 of the PDF): arrayinit should probably be
arrayadd, which is defined in 4.7.1 -- this wasn't in 2.2,
who added it?


I'll start a new e-mail for Section 5 and following.

-Geoffrey

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



attached mail follows:


Turn on generation of hyperlinks, so it is easy to navigate PDF file.

Page v:
Ken Kundert, Designers Guide LLC --> Ken Kundert, Designer's Guide 
Consulting
Xpedion Design Systems --> Agilent
(c) 2007 --> (c) 2008

Page 61:
in Table 4-15, the "excluding x = y = 0" comment for hypot should be
removed. It was intended for atan2 rather than hypot, but it should not be
present for atan2 either.

Page 64:
Table 4-18. Description of idt(expr) should not be italicised.

Page 66:
Table 4-19: Description of idtmod(expr) should not be italicised.

Page 74-79:
In sections 4.5.11 and 4.5.12 the equation spacing is messed up
(some equations have too little space, some way too much).

page 350:
assert_severity_task - BNF defined but never used.

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




attached mail follows:


The syntax needs to be updated to allow for the new 'enable' argument to 
cross/above/timer.


analog_event_functions ::= // from A.6.5
cross ( analog_expression [ , analog_expression
[ , constant_expression [ , constant_expression [ , analog_expression ] ] ] ] )


We are going to allow the user to use NULL arguments for the options they want 
to leave as default.
So:
cross(V(a) - 5, , , ,enable) ....

Here detect crossings in both +ve and -ve direction using simulator default 
expressio and time tolerances.

But the NULL arg is not handled in the analog_expression or constant_expression 
type.
Instead of adding extra [] to the syntax would be better to create a new token:

analog_expression_or_null ::=
     analog_expression
   | null

constant_expression_or_null ::=
     analog_expression
   | null

Cross then becomes:

cross ( analog_expression [ , analog_expression_or_null
[ , constant_expression_or_null [ , constant_expression_or_null [ , 
analog_expression ] ] ] ] )

Not quite sure what the convention is in BNF to specify NULL (nill or prehaps "").

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.



Received on Tue Apr 15 09:05:43 2008

This archive was generated by hypermail 2.1.8 : Tue Apr 15 2008 - 09:05:45 PDT