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

Marq,
    My experience with hierarchical references is that they are
generally quite useful when building test benches and I would hate to
see them further restricted. It is bad enough that we cannot access
analog variables (perhaps that constraint can be loosened). Personally I
don't see the implementation issue with hierarchical signal references,
with the possible exception being that in a nodal analysis based
simulator it might be hard to get a current on a port or branch when
that current is not used within the model that contains the port or branch.

One of the expected uses of hierarchical references for signals would be
to support back annotation of parasitics (I believe Kevin proposed
this). You could back annotate a load capacitance into a block from
outside using something like
     I(I23.in) <+ c*ddt(V(I23.in));
This allows the addition of shunt parasitics. What is missing is the
ability to add series parasitics. It was originally envisioned that we
would allow contributions to port branches to handle this case.
     V(<I22.out>) <+ r*I(<I22.out>);
But some found that a bit odd and it was initially dropped with the
expectation that it would be revisited. That has yet to occur.

-Ken

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