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

Marq, Dave,

I would agree with that comment of disallowing contributing to a analog 
net hierarchically. If we are talking implementing, from my 
understanding having hierarchical flow probes may not also be very 
trivial. Can be done but not easy.

Also it will be interesting to know how we are going to refer to 
"unnamed" branches hierarchical? I am not sure whether the syntax would 
allow that now or should it always refer to a branch already declared?

On a side note, I am guessing we will not allow any hierarchical 
references to a parameter, variable inside a named block. I think this 
is what we decided recently in one of the discussions of the committee 
meeting, just wanting to clarify that point.

Regards,
Sri

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

-- 
Srikanth Chandrasekaran
DTO Tools Development
Freescale Semiconductor Inc.
Ph: +91-120-439 7021 F: x5199