RE: disallow distributed switch branches

Folks,

I have been following this discussion (argument?) for
some time now and it seems that is not making any
progress.  I don't know if my comments will help or
not to make a decision, but it seems that this may be
a good time for me to vent out some of my feelings and
impressions on this aspect of the language, hopefully
to influence the decision making process in the right
direction.

When I started to learn Verilog-A and AMS I was shocked
to find out that the "<+" operator adds to an already
existing value (contributes) instead of just making an
assignment.  Why was I so surprised and shocked?

1)  Every single language I have learnt so far uses 
assignment operators, not contribution operators.  The
value of Vout will have the value of "B" in Vout after
the second assignment:

   Vout = A;
   Vout = B;

not A+B as in Verilog-A.  From a hardware point of view,
the Verilog-A approach is like having two (unnamed) voltage
sources in series inside a branch (assuming that Vout is
declared as a branch) which are referred to by the name
of the branch.  Very confusing to say the least, and very
incompatible with the coding concepts of any other
programming language.

2)  Having a contribution operator ONLY in Verilog-A limits
the capabilities of the language, because I can ONLY have
the option of summing.  There is no option for replacing.
On the other hand, if the operator would be an assignment
operator, I would have both options.

3)  If I want a sum, I would find it a lot safer to write:

  Vout = A+B;

than having to remember some (rather unintuitive) language
rules and write:

   Vout <+ A;
   Vout <+ B;

especially if these two lines are miles apart in a model,
or if they happen to be in different modules (to be in
sync with the topic of this thread).

4)  This concept of "contribution" is contradictory in
itself, because between the iterations (or time steps)
it is really an assignment, not contribution.  For
example, after the second iteration Vout will be A
and not 2*A:

time step (iteration) #1:
   Vout <+ A;

time step (iteration) #2:
   Vout <+ A;

5)  None of the other languages that I am familiar seem
to be doing this.  When we write equations in programs,
they all do assignments.  Yes, most languages have an
"increment" or "decrement" operator

   j = j + 1  can be shorthanded as j += 1

but these are SHORTHANDs, not the normal routine for making
assignments.  In Verilog-A it seems that this shorthand is
the NORM, and the ONLY thing, since there is no equivalent
for a normal assignment (as far as I know).

6)  The "competitor" language, VHDL-AMS has several form
of assignment operators (<= and ==) but these do assignments.
But to my knowledge, it does not have a contribution operator
(nor does it have increment, decrement operators).  There
is really no need for it, since the "+" operator can take
care of the same functionality in a much safer way.  I think
we should make every attempt to be compatible with VHDL-AMS
because there are cases when we need to convert from one to
the other.  Why does Verilog-A have to be so different from
all other languages by not having assignment operators, and
doing this weird accumulative contribution operation only?

7)  Add to this already confusing situation the current
discussion topic of the possibilities of changing behavior
when the "<+" operator is inside the same block or not.  This
is becoming a nightmare...

8)  A similar (and maybe related) situation is the switch
branch issue.  In VHDL-AMS I can write my simultaneous
equations using the voltage or current form and mix or
interchange them in IF statements or the like, the
compiler doesn't care as long as the equations have
the correct number of knowns and unknowns.  This is a
lot easier and safer than having to remember the (again,
some rather unintuitive language rules) switch branches
and contributions...

9)  In short, I would do away with the contribution
operator (<+) all together and provide an assignment
operator instead!


Finally, whatever you decide, please remember that we
are trying to get our modeling jobs done when we learn
these languages.  The language should be helping us,
electronic engineers.  We do not want to have to deal
with computer science problems, we want to be able to
write our models and run our simulations.  Consider why
is Matlab so popular these days among physicists and
engineers.  It is an extremely powerful tool (language),
yet easy and intuitive.  The computer science problems
are hidden from the user and it comes with a huge amount
of ready to go powerful functions.  I think we are far
behind Matlab with both *-AMS languages, and we are
getting bogged down with way too many unnecessary
technical issues, limitations.

I know that we are a volunteer organization, and I don't
want to take this too far, but it seems that by the time
we figure out how to get over the hurdles of combining
Verilog-AMS and System-Verilog-AMS, etc... Matlab may
become the choice of behavioral modeling.  Look what is
happening in the high speed SERDES world.  No one uses
any of the *-AMS languages...

Who knows, by then Mathworks may even come out with a
SPICE-like circuit simulator (considering their recent
addition of the RF2 toolbox, simulink, and so many tool
vendors adding Matlab hooks).  Some have already written
circuit simulators in Matlab.  OK, OK, I will stop now...

Thanks for reading this far...

Arpad
============================================================


-----Original Message-----
From: owner-verilog-ams@server.eda.org [mailto:owner-verilog-ams@server.eda.org] On Behalf Of Kevin Cameron
Sent: Thursday, April 19, 2007 5:39 PM
To: Ken Kundert
Cc: verilog-ams
Subject: Re: disallow distributed switch branches

Ken Kundert wrote:
> Kevin,
>     This conversation is beginning to seem familiar. I think we have had
> it before. And I remember pointing out that you simply cannot have two
> or more voltage sources in parallel. Nor is there any value in doing so
> as anything in parallel with a voltage source has no effect on the rest
> of the circuit.
>   
Yes we are repeating the discussion, and I said it was perfectly OK to 
have multiple voltage sources of the same potential - and it appears 
that that is supported in the simulators.

Also, for non-constant voltages in parallel the solver will balance the 
currents so that the voltages match. The only failing case is more than 
one constant voltage source of a different value.

> The reason for having OOMR voltage contributions being in series is
> consistency with the rest of the language. Why should the rules be
> different for out-of-module-references than for in-module-references?
>   
I think you are just avoiding my question on justifying the behavior 
being different depending on how you wire things up. I'd ask the 
question: why should in-module behavior be different from multi-module 
behavior, and hence why should OOMR behavior be different from that.

> There is also a nice application of this, originally suggested by you.
> Imagine that you have a module that has an output driven by a voltage
> source. And say that you want to more accurately model the delay caused
> by a load capacitance, but you don't want to explicitly go in and modify
> the module. With OOMRs you can effectively add a series resistance if
> the language stays as currently defined, but you could not do it if the
> language were modified so that all OOMRs combined in parallel.
>   
I don't remember suggesting that. However, I do remember proposing a 
back-annotation scheme that would allow you to do the same thing.

--

If I you have the module:

    module batt (pos,neg)
      electrical pos, neg, lcl;
      parameter real res = 1.0e-3;
      parameter real vb  = 1.0;
      analog
         V(pos,neg) <+ vb -  res * I(pos,neg);
    endmodule

That's a non-ideal battery, I should be able to put a bunch in parallel. 
Should instantiating it with res = 0.0 change the behavior significantly?


NB: I have nothing against providing a summing behavior if people think 
they need it, I just don't think it should be the default anywhere 
outside an individual analog block.

Kev.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.