From: Marq Kole <marq.kole_at_.....>
Date: Fri Dec 15 2006 - 07:07:36 PST
Geoffrey, Kev,
When we wanted to allow multiple analog
blocks in the analog context the only way to handle this in a consistent
way that would not overburden the implementation was by concatenating them
into a single larger analog block. That is definitely different than the
@always block in digital Verilog which as far as I can tell should be considered
to operate concurrently. One of the problems with concurrent execution
of separate analog blocks is that you will immediately open up the possibility
of race conditions in the handling of the statements that work with module-level
variables in the sequential blocks, and hence ambiguity.
By *defining* that multiple analog blocks
will be concatenated the race conditions and therefore the ambiguity will
not be present anymore. The way analog contributions are handled is essentially
concurrent, because the continuous-time solver is handling all contributions
together. But analog blocks also contain code that is needed for setting
up these analog contributions and this code is not necessarily concurrent.
Apart from that: multiple contributions to a branch are principally sequential
in nature either by value retention or through switch branches. Analog
blocks are not @always blocks and they probably never will be.
In my opinion the advantage of multiple
analog blocks will mainly be in combination with generate constructs. If
a modeller creates multiple analog blocks that contribute to the same branch
he will need take the same amount of care as when he made them in a single
block.
If you need a stronger level of concurrency
then instead of multiple analog blocks you should use separate analog modules,
this given concurrency even to the point that reordering the instantiations
of these modules does not influence the simulation results. However, they
will no longer be able to do collective bookkeeping on the same set of
module-level variables. You can't have both without significant effort
in implementation and probably restrictions in how to model to prevent
ambiguity. In the end, analog is very different from digital.
Cheers,
Marq
Marq Kole
Competence Leader Robust Design
Research
NXP Semiconductors
"Geoffrey.Coram" <Geoffrey.Coram@analog.com>
Sent by:
geoffrey.coram@analog.com
15-12-2006 14:38
To
edaorg@v-ms.com
cc
verilog-ams@verilog.org
Marq Kole <marq.kole@nxp.com>
Subject
Re: Elaboration algorithm proposal
Classification
edaorg@v-ms.com wrote:
>
> This sounds bad to me. As a user I would expect to get the
> same behavior if I put the analog blocks in the same module
> or in separate modules if their connectivity is the same -
> I don't see that being the case if the blocks get concatenated.
> Reodering always blocks in Verilog doesn't change the behavior,
> the same should be true for analog blocks.
>
> I think there should be an explicit statement to the effect
> that: the reordering of analog blocks within a module or
> declaring them in seperate modules should not change the
> results of simulation for pure analog (to exclude A/D issues
> at ports).
Kevin brings up an interesting point: what about value
retention? If I do:
analog begin: block 1
V(out) <+ 5;
end
analog begin: block 2
I(out) <+ 5;
end
Then reordering the blocks before concatenation will
alter the results.
Also, if you have
analog begin: block 1
V(out) <+ 5;
end
analog begin: block 2
V(out) <+ 500;
end
then you will get a singular matrix error if these
are in separate modules connecting to the same node.
If they are concatenated, the values will add and
you'll get a 505-volt independent source driving
the node.
-Geoffrey
Received on Fri Dec 15 07:08:18 2006
This archive was generated by hypermail 2.1.8
: Fri Dec 15 2006 - 07:08:20 PST