Re: [Fwd: Re: Some merged_datatype.pdf feedback.]

From: Geoffrey.Coram <Geoffrey.Coram_at_.....>
Date: Fri Jun 02 2006 - 12:49:11 PDT
Forwarding bounced message (too long).
Document attached to original message has been saved as:
http://www.verilog.org/verilog-ams/htmlpages/public-docs/eqnform-full.pdf

-------- Original Message --------
Date: Fri, 02 Jun 2006 12:03:09 -0700
From: Ken Kundert <ken@de...>
To: verilog-ams@server.verilog.org
Subject: Re: [Fwd: Re: Some merged_datatype.pdf feedback.]

> section 3.4.2.1: With the change from:
> 
>        discipline current;
>           potential Current;
>        enddiscipline  
> to
>         discipline current;
>             flow Current;
>         enddiscipline
> 
> Implementations may vary, but my general understanding is that 
> simulators always require a potential nature binding for a net, but it 
> does not necessarily need a flow binding. Nets with potential nature 
> binding may have only one branch connection because the KCL  does not 
> have to be strictly followed when there is a potential nature present. 
> However nets with flow nature binding (no potential binding) either must 
> inherit a potential binding for a port connection or must have 2 or more 
> branch connections to comply with KCL. Is this generally correct? If it 
> is, then these constraints needs to be documented in the LRM.

Your assumptions are not correct. While it is true that today all
simulators convert signal flow ports to fully conservative ports,
meaning that they all end up with both a potential and a flow, they do
not need to do so. Neither is required. At a signal flow node where only
currents are present, the equations can be formulated to completely
eliminate the potential, and doing so results in an increase of efficiency.

Also it is wrong to say that KCL is not strictly followed at a
potential-only node. It is better to say that KCL is implicitly followed
or followed by assumption.

Furthermore, there is nothing that requires that there be two
connections to a flow only node. If there is only one connection, then
the flow through that connection must be zero and so this should
probably be flagged as a topology error if the connection is an output,
but not if the connection is an input. However, having two flow output
connections and no flow input connections would be just as problematic.
The requirements are a bit more general. Specifically, when signal flow
terminals connect to a node there are several situations that must be
avoided so as to eliminate obvious conflicts or ambiguities.
1. It is an error to connect more than one signal-flow potential
   output terminal to the same node.
2. It is an error to connect more than one signal-flow flow input
   terminal to the same node.
3. It is an error to connect a signal-flow potential output terminal
   and a signal-flow flow input terminal the same node.
4. It is an error to connect only signal-flow flow output terminals
   and/or signal-flow potential input terminals to a node.


> If the 'current' signal-flow discipline is to be changed to using a flow 
> nature binding instead of a potential nature binding, how can purely 
> current models be developed like like purely voltage models. Should 
> there be a new current discipline  to allow purely current  models to be 
> developed? For example:
> 
>         discipline current_value;
>              potential current;
>         enddiscipline
>

There is no need for such a discipline. In fact, creating such a
discipline should be discouraged as it undermines the compatibility
between signal flow and conservative disciplines that we are trying to
promote.

I have attached a document that goes into fairly great depth into the
rationale and implementation issues involved in the probe-source model
used in Verilog-AMS. It covers this issue of signal-flow current
disciplines. I don't expect that the document can be used directly when
modifying the LRM, but it does provide a lot of good background material.

-Ken
Received on Fri Jun 2 12:48:47 2006

This archive was generated by hypermail 2.1.8 : Fri Jun 02 2006 - 12:48:57 PDT