Mantis Item 879 - $nodeCollapse()

From: Helwig Graham-A11558 <Graham.Helwig_at_.....>
Date: Wed Sep 14 2005 - 18:22:38 PDT
Hello,
 
Currently there is no interest in having an explicit $nodeCollapse() task. However after the merger of the 1362-2005 and Verilog-AMS LRM the ability to conditional declare nets will be automatically available. So the capacitor example (used in the Mantis item 879) can be modified in the following way to conditionally declare the 'int' net instead of conditionally collapsing it (assuming multiple analog blocks within a module declaration is supported).
 
	module capacitor(p,n);
		inout p; electrical p;
		inout n; electrical n;

		parameter real C = 0.0 from(0:inf);
		parameter real rs = 0.0 from[0.0:inf);

		generate 
			if (rs) begin
				electrical int;
				branch (int,n) cap;
				branch (p,int) res;
				analog I(res) <+ V(res)/rs;
			end
			else begin
				branch (p,n) cap;
			end
		endgenerate
		analog I(cap) <+ ddt(C*V(cap));
	endmodule

The language restriction of only allowing one analog block in a module declaration has been around for a long time now, what was the rationale for this restriction?  

Regards
Graham

> -----Original Message-----
> From: owner-verilog-ams@eda.org 
> [mailto:owner-verilog-ams@eda.org] On Behalf Of 
> Chandrasekaran Srikanth-A12788
> Sent: Wednesday, September 14, 2005 6:44 PM
> To: Verilog-AMS LRM Committee
> Subject: Minutes of LRM Committee Meeting - Sept 13/14th 2005
> 
> 
> Attendees:
> Marq Kole (Philips)
> Jim Barby (Uni. of Waterloo)
> Geoffrey Coram (Analog Devices)
> Ilya Yusim (Cadence)
> Prasanna Tamhankar (Freescale)
> Martin O'leary (Cadence)
> Sri Chandra (Freescale)
> Kevin Cameron (Sonics Inc)
> Graham Helwig (Freescale)
> 
> Recent Updates
>   * Accellera received approval from IEEE for using 2005 for 
> AMS LRM 2.3 edit purposes. Johny has sent a version.
>   * Graham will try to do the same updates for Chapter 10 (as 
> was done with one of the earlier draft versions with the 
> latest std which can be used as the starting point)
> 
> Verilog-AMS/Spice translation and testbench for Verilog-AMS
>   * These items were discussed at last meeting. The 
> resolution was to look at both of these efforts outside the 
> current scope of the AMS committee.
>   * It was agreed that the testbench for Verilog-AMS will 
> prove very useful in verifying adherence to standards and 
> interoperability.
> 
> 
> Mantis database tickets:
> 
>   * 867: Error in section 6.6.2 will be addressed. This is 
> just a minor correction on specifying the width that is 
> syntactically correct (left of identifier) and will be 
> addressed as part of LRM2.3
> 
>   * 868: Parameter declaration inside analog function. This 
> is allowed as per BNF, Marq felt might be good to clarify 
> with example.
>     - LRM makes a reference in analog function section saying 
> UDF will reference only local variables defined in that scope.
>     - Not very clear whether this refers to just "variable 
> identifiers" 
> defined inside UDF or also parameters
>     - There is a school of thought where parameters are seen 
> as global to module scope and hence UDF can reference 
> parameters at module scope. 
> If parameter with same name exists in UDF scope, then the 
> local scope will be taken
>     - This needs to be clarified in LRM2.3
> 
>   * 869: Array arguments for UDF
>     - This is defined in BNF but was felt to be useful to 
> give example and clarify in the section
> 
>   * 870: BNF for analog UDF port declarations in section 
> 4.6.1 refers digital
>     - This is accepted and will be resolved as part of LRM2.3
> 
>   * 874: Usage of vsource. Table E.2 describes set of 
> parameters, and it is implicitly assumed to be for vsrc
>     - The consensus for the committee will be to drop Table 
> E.2 from the Annex and merge this with Table E.1 (details of 
> parameter names etc)
>     - There is no need for vsrc as the individual vX are 
> already present
> - vsine, vpwl, vexp etc
>     - Also the way the syntax is currently defined for vsrc 
> this doesnt fit the AMS syntax description.
> 
>   * Conflict in array range between inout declaration and 
> electrical declaration.
>     - If they are differing width it will be an error.
>     - With regards to same width but LSB/MSB swapped - after 
> some discussion (just to honour inout of port connectivity) 
> it was agreed to flag this as an error.
>     - With regards to string match vs expression match (ie. 
> inout [0:P] neta; electrical [0:3] neta; where P=3) it was 
> felt that compiler can error out based on string match 
> results instead of requiring elaboration to resolve value of 
> P. Nobody felt that there was a need why one of them would be 
> a constant expression and other parameter tho' they resolved 
> to the same value.
>  
>   * Discussion on param arrays support in AMS
>     - [Joined in bit late into the call, hence unable to minute it]
>  
>   * $node_collapse
>     - This was discussed as part of Device Modeling committee 
> and was dropped as a required feature at language level as 
> the simulator can handle this internally.
>     - This is often done in compact models through a short (0 voltage
> source) if the nodes can be collapsed.
>     - It was felt adding the feature may result in more work 
> for simulator as it had to still check for the validity of 
> collapsing the nodes (and) hence may also be error prone.
>     - Lead to discussions about supporting if-else blocks at 
> the structural level and instantiating different modules & 
> different structural net declarations based on conditional 
> statements outside the analog block scope. This will be 
> available as part of inheriting 1364-2005, but also may 
> require support for multiple analog blocks.
>     - Graham will send out an example detailing this to the 
> committee reflector.
>  
> 
> Next week:
>   * Any new tickets that are raised in Mantis to make sure 
> recent issues are discussed
>   * Also will go through where we left off in resolving 
> critical/high/low prioritization on existing tickets
>   * It will also be good to start discussing proposals that 
> are available for any of the tickets that have already been 
> accepted as critical for LRM2.3 instead of waiting for all 
> tickets to be prioritized.
> 
> cheers,
> Sri
> 
> --
> Srikanth Chandrasekaran
> Design Technology (Adelaide)
> Freescale Semiconductor
> Ph: +61-(0)8-8168 3592 Fax: x3201
> 
Received on Wed Sep 14 18:23:02 2005

This archive was generated by hypermail 2.1.8 : Wed Sep 14 2005 - 18:23:48 PDT