Re: Clarification question on port direction

All,
    It seems the basic value of having the port direction declarations
is to communicate the basic intent of the pin to tools that support the
design process, such as schematic capture programs, and as a sanity
check (does the implemented functionality match the clearly stated
intent of the modeler). So given this observation, there seem to be two
possible sets of restrictions that one can put on the pins that are
accessed in the analog module. The choice between these two sets is
mutually exclusive.

1. Within an analog block one may only probe (use in an expression)
input pins and drive (contribute to) output pins. One may not drive
input pins or probe output pins.

This works well for signal-flow pins, but is probably too restrictive
for conservative pins because it does not allow for the loading effects
(input impedance of inputs and output impedance of outputs).

2. Within an analog block one may either probe or drive an input pin,
but if you drive an input pin the drive may only depend on the input pin
itself. You may also either probe or drive and output pin, but if you
probe an output pin the value may only be used to drive the same pin.
Thus, if 'in' is an input pin, and 'out' is an output pin, then
   V(out) <+ f(V(in));
   I(in) <+ Cin*ddt(V(in));
   V(out) <+ Rout*I(out);
would be legal, but
   I(in) <+ Gmu*V(in,out);
would not as it violates both constraints.

We may want to add constraints that input pins must be probed (used in
an expression) and output pins must be driven (target of a contribution).

Currently the restriction is that potentials may not be contributed to
inputs (page 7 of LRM). That is somewhat orthogonal to the desired
intent, and it violates the long standing goal that voltage and current
be handled symmetrically.

-Ken

Geoffrey.Coram wrote:
> The underlying standard (1364-????) *requires* the declarations
> (I have a vague sense there are other things that can go inside
> the parentheses, and thus it's important to declare which ones
> are ports and which are the other things).
> 
> The other tools don't ignore the declarations, they only ignore
> the specifics, ie, whether it is input/output/inout.  And probably,
> a rigorous AMS simulator may actually enforce the directionality;
> almost all analog electrical ports should be inout.  Any that aren't
> may end up being caught by some simulator in the future.
> 
> I say "almost" because "input" and "output" might actually make sense
> for a controlled source.
> 
> The order of declarations is not prescribed by the LRM; it is a 
> bug in one AMS simulator and hence the analog simulator from the
> same vendor issues a warning.  I mentioned this just in case 
> people trip over it.
> 
> -Geoffrey
> 
> 
> "Muranyi, Arpad" wrote:
>> Geoffrey,
>>
>> I am not sure that I know what "signal-flow models really are, but
>> if I understand it correctly from the replies I got so far, the
>> direction makes only sense for digital ports, and not for
>> analog electrical ports.  If this is true, could we put something
>> into the LRM to state that for analog ports (if they exist) we do
>> not need to (or should not) use the direction declarations?  After
>> all, if tools ignore it, and if it is meaningless, why require them?
>>
>> Also, if the order of the declarations is important, we should
>> perhaps mention that too in the LRM.  One of the two tools we
>> tried will take them in any order, but another one would give
>> errors.  Which one is correct?
>>
>> Thanks,
>>
>> Arpad