Re: Verilog-AMS Committee Meeting Minutes - Nov 02 2006
From: Marq Kole <marq.kole_at_.....>
Date: Thu Nov 16 2006 - 00:14:21 PST
Dave,
As a guiding principle I was trying
to make an analog_construct do as always_construct and initial_construct
do in 1364. Is that too much a leap of faith? If we choose to support this
parallel then the analog_sequential_block comes as a consequence of supporting
the analog_construct inside a generate_region.
In the BNF in syntax 7-2, p. 127 of
the latest document I see that I already moved the analog_construct from
the non-port_module_item to the module_or_generate_item: I guess we missed
that during review. Do you think this move has other consequences as well?
With respect to your last remark: that
is obviously an oversight from my part -- I'll mark it in my copy for change.
Cheers,
Marq
Marq Kole
Competence Leader Robust Design
Research
NXP Semiconductors
Dave Miller <David.L.Miller@freescale.com>
Sent by:
owner-verilog-ams@server.eda.org
15-11-2006 15:52
To
Marq Kole <marq.kole@nxp.com>
cc
verilog-ams <verilog-ams@server.eda-stds.org>
Subject
Re: Verilog-AMS Committee Meeting Minutes
- Nov 02 2006
Classification
Hi Marq,
so going through the latest BNF we have I have found a couple of things.
It looks like declaring the electrical n_int inside the generate
for-loop is okay.
Here is my path through the BNF maze:
module_item -> non_port_module_item -> module_or_generate_item ->
loop_generate_construct -> generate_block ->module_or_generate_item
->
module_or_generate_item_declaration -> net_declaration -> electrical
n_int;
But while looking at this I see that we can't have an analog sequential
block inside a generate construct.
The analog_construct (which is what is used to create the analog blocks)
is not part of the module_or_generate_item.
So the adc and the rcline2 examples don't work based on the BNF today.
Also in the latest document (merged_hier.pdf) in the examples for the
rcline and rcline2, the potential contributions V(n1,n[0]) <+ 0.0; and
V(n2,n[N]) <+ 0.0; need to be enclosed within an analog seq block.
Cheers...
Dave
Marq Kole wrote:
>
> All,
>
> One item that I forgot in the minutes and that is relevant to the
> upcoming review as well:
>
> In the example rcline2 on page 151 of the merged_hier_v1.0.pdf (so
the
> one used during the first review of section 7) inside a generate
> sequential block a local node is begin declared. During the call there
> were doubts on whether this would be allowed by the current syntax
> description.
>
> The reason for including this is that there is an exact analogy in
> 1364-2005 (example 4 on page 185, in section 12.4.1). If you are going
> to generate an array (one or multi-dimensional) of compound structures
> from basic elements then the ability to declare internal nodes for
> each compound structure makes modelling such array structures much
> easier and understandable. In the analog/mixed-signal world there
are
> numerous examples of such structures: delay line models, memories,
> CMOS imagers, multiphase PLL/DLL, flash ADCs, etc.
>
> Cheers,
> Marq
>
>
> Marq Kole
> Competence Leader Robust Design
>
> Research
> NXP Semiconductors
>
>
>
>
>
>
>
>
> *Marq Kole <marq.kole@nxp.com>*
>
> Sent by:
> owner-verilog-ams@server.eda.org
>
> 03-11-2006 14:39
>
>
> To
> "verilog-ams"
<verilog-ams@server.eda.org>
> cc
>
> Subject
> Verilog-AMS
Committee Meeting Mi
>
> nutes - Nov 02 2006
> Classification
>
>
>
>
>
>
>
>
>
>
>
> Marq Kole - NXP Semiconductor
> David Miller - Freescale Semiconductor
> Geoffrey Coram - Analog Devices
> Jim Barby - University of Waterloo
>
>
> Reviewed Section 7 - Hierarchical Structures.
> In Syntax 7-2 the aliasparam_declaration and
> analog_function_declaration need to be moved from
> module_or_generate_item_declaration to non_port_module_item.
>
> We had a discussion on top-level modules as the text here as well
as
> in section 7.5 (generate constructs) disallow a recursive module from
> being a top-level module. What is the meaning of a top-level module
in
> an analog/mixed-signal context? The text here (as well as in
> 1364-2005) allows a top-level module to have ports. No decision was
> made on this.
>
> Action: Marq to ask for the meaning of top-level modules in the
> digital community.
>
> For module instantiation, the last paragraph on page 128 has been
> copied from 1364-2005. Here it should explicitly mention that the
> expression for supplying a value to a module input port is purely
> digital -- this is not allowed for an analog input port.
>
> Where needed, the examples in section 7 have been reformatted for
a
> more consistent indentation -- it was noted that the 1364-2005
> examples aren't that consistent either.
>
> Action: Marq to post formatting guidelines for Verilog-AMS code examples.
>
> In the example on page 129 the ground declaration in the module
> comparator should actually move to the module sigmadelta where it
is
> used.
>
> In the example on page 131 the order of terminals for the MOS modules
> will be made more consistent with SPICE.
>
> According to the new 1364-2005 compliant syntax, modules without ports
> need to have an empty pair of braces following the module name in
its
> definition. This applies to the exmplaes on page 132.
>
> Action: Geoffrey recalled having seen some comments on the section
on
> paramsets regarding the chaining on paramsets. He will try to provide
> more information on this item.
>
> The section 7.5 on generate constructs was added, copying nearly all
> of the text from section 12.4 in the 1364-2005 standard. Syntax 7-10
> has a few missing newlines that need to be corrected.
>
> The examples rcline and rcline2 on page 151 had headings that drew
> some questions. It was decided to adopt a more conservative style
for
> these examples, not using the port connections by name. Upon detailed
> inspection the current proposal was not according to the 1364-2005
> standard, although section 12.3.3 had a couple of quite confusing
> examples. We need to decide how this will impact analog/mixed-signal,
> still.
>
> Next week the review will continue with section 7.5.2 - conditional
> generate constructs.
>
> We momentarily spoke about a new time slot for the weekly telephone
> conference. Although we had few people on the call, it was proposed
to
> move back to the old time next week, and to try to find a good common
> time by then. So the call time for next week will be:
>
> 03:00 PM Pacific (Thursday)
> 06:00 PM Eastern (Thursday)
> 03:30 AM India (Friday)
> 09:30 AM Adelaide (Friday)
> 12:00 PM Amsterdam (Thursday)
> 01:00 AM Athens (Friday)
>
> LRM Sections in the pipeline:
> * section 8 - David Miller - weeks to submission = 2 (11/16/06)
> * section 10 (no table model) - Martin O'Leary - weeks to submission
= 3
> (11/30/06)
> * section 10 (table model) - Patrick O'Halloran - weeks to sumission
=
> ????
> * annex E - Marq Kole - weeks away from submission = ???
>
> Thanks,
> Marq
>
--
=====================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
=====================================
Received on Thu Nov 16 00:14:40 2006
This archive was generated by hypermail 2.1.8
: Thu Nov 16 2006 - 00:14:53 PST