Re: Verilog-AMS Committee Meeting Minutes - Nov 16 2006

G'day Marq,
Yes, the only use I am seeing for hierarchical contributions is within 
testbenches. I guess the fact that I am seeing them means that some 
implementations support it. If we wish to explicitly disallow it, that 
is absolutely fine by me, I just need to know one way or the other.

Cheers...
Dave

Marq Kole wrote:
>
> Dave,
>
> The only use that I can think of for hierarchical references to analog 
> quantities is to set initial values for such quantities. Read access 
> to such quantities has no issue, but contributing to a hierachical 
> branch may have some issues that would make it hard to implement - 
> making it an obstacle to the deployment of Verilog-AMS 2.3.
>
> Unless we had a specific use case for contribution to hierarchical 
> analog branches, my choice would be to disallow it.
>
> 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
>
> 17-11-2006 16:37
>
> 	
> To
> 	Marq Kole <marq.kole@nxp.com>
> cc
> 	verilog-ams <verilog-ams@server.eda-stds.org>
> Subject
> 	Re: Verilog-AMS Committee Meeting Minutes - Nov 16 2006
> Classification
> 	
>
>
>
> 	
>
>
>
>
>
> One thing I forgot to ask last night, which I guess was relevant to this
> section. What was the resolution on allowing hierarchical references to
> analog quantities? In particular contributing to hierarchical analog
> branches and variables? I remember there was some discussion on this
> previously but I am not sure on what the outcome was. Are we going to
> explicitly disallow contributing to a hierarchical analog branch?
>
> Dave
>
> Marq Kole wrote:
> >
> >
> >
> > Marq Kole - NXP Semiconductor
> > David Miller - Freescale Semiconductor
> > Geoffrey Coram - Analog Devices
> > Jim Barby - University of Waterloo
> > Patrick O'Halloran - Tiburon
> > Martin O'Leary - Cadence
> > Arpad Muranyi - Intel
> > Graham Helwig - ASTC
> >
> > Continued review of Section 7 - Hierarchical Structures.
> > The review uses the merged_hier.pdf document that includes rework from
> > the review two weeks ago.
> >
> > An item skipped during the previous review: in Syntax 7-2 the
> > analog_construct has been moved from non_port_module_item to
> > module_or_generate_item_declaration so it can be part of a generate
> > region.
> >
> > The review continued with section 7.5.2 on conditional generate
> > constructs.
> >
> > On page 154, below the pipeline_adc example there is a reference to
> > section 7.3. More explanation is needed here on especially what
> > conditional generate functionality can also be achieved using paramsets.
> >
> > For the example of the pipeline_adc the question came up on how to
> > handle parameters that are used in the generate constructs in a
> > parameter sweep (dcsweep-like) analysis. In the Mantis database there
> > is an item 0000814 that addresses a similar problem and proposes to
> > use specific dynamic parameters. By not allowing such dynamic
> > parameters to be used in the conditional part of a conditional
> > generate statement or the loop definition of the loop generate
> > statement, implicit changes to the design structure (and hence the
> > need for re-elaboration) are not allowed. However, this particular use
> > of dynamic parameters has not been discussed yet and has not been
> > taken into account in the LRM 2.3 syntax or any of the new sections.
> > At least the issue should be addressed in the section 7.5.2 text.
> >
> > At the end of section 7 a new subsection 7.6 on Elaboration has been
> > added. This was needed when introducing the generate regions in
> > Verilog-AMS. Now such a specific section is here there are two other
> > items that probably should be mentioned here in separate subsections
> > under 7.6:
> > 1) elaboration and connectmodules
> > 2) concatenation of analog blocks (as described on page 125, 2nd
> > paragraph of section 7.1)
> >
> > In the previous call Geoffrey recalled having seen some comments on
> > the section on paramsets regarding the chaining on paramsets. However,
> > he did not find anything: it might have been from the original
> > paramset proposal and not the LRM.
> >
> > Next week there will be no conference call as it will be Thanksgiving
> > in the US and Canada, the next conference call will be on November 30,
> > at 9 PM Pacific.
> >
> > Midnight Eastern = 5AM GMT
> > Adelaide:      3:30 PM
> > India:        10:30 AM
> > Eindhoven:     6 AM
> > Eastern:      midnight
> > Central:      11 PM
> > Pacific:       9 PM
> >
> > Action: ask Sri to create an overview of the work that is now finished
> > for LRM 2.3 and what still needs to be done.
> >
> > LRM Sections in the pipeline:
> > * section 8 - David Miller - weeks to submission = ?
> > * section 10 (no table model) - Martin O'Leary - weeks to submission = 2
> > (11/30/06)
> > * section 10 (table model) - Patrick O'Halloran - weeks to sumission = ?
> > * annex E - Marq Kole - weeks away from submission = ?
> >
> > Open actions:
> > * Marq to ask for the meaning of top-level modules in the digital
> > community.
> > * Marq to post formatting guidelines for Verilog-AMS code examples.
> >
> >
> > Thanks,
> > Marq
>
>
> -- 
> =====================================
> -- David Miller
> -- Design Technology (Austin)
> -- Freescale Semiconductor
> -- Ph : 512 996-7377 Fax: x7755
> =====================================
>
>


-- 
=====================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
=====================================