Kevin Cameron <kevin@sonicsinc.com> wrote on
19-04-2007 00:17:53:
> <snip>
> > > If
> > > The behavior of an analog blocks should not change if they
are
> > moved from separate modules into the same module.
> > > holds, then
> > > If you contribute to the potential of a branch in two analog
> > blocks, the values add; if you put the analog contrib statements
> > into separate modules, the potentials are in parallel.
> > > is untrue.
>
> > Then one should conclude that the above proposition (The behavior
> > ... same module) is false.
> From a programmers perspective it is extremely
bad to have the same
> piece of code do different thing in different contexts - a
> guaranteed source of bugs.
Once the context involves a new scope then also for
programming languages like C, Java, ADA, etc. the above assumption does
not hold. In the case of parallel instances each piece of code in the body
has its own scope and can be accessed that way using OOMR. In the case
of multiple analog blocks the code in the body share the items declared
at the module-level.
<snip>
> As far as I'm concerned all contributions from
analog processes
> (blocks) to a given branch/node-pair should be considered as being
> in parallel. Only internal to an analog block do potential contributions
sum.
Only if the scope is at the analog block level instead
of the module level. For consistency, unnamed analog blocks should not
have a scope of their own. If one wants to refer to the contribution to
an unnamed branch in one particular concurrent analog block using OOMR
it would be necessary to device an external naming scheme for unnamed analog
blocks similar to that of unnamed generate blocks as in IEEE 1364-2005,
section 12.4.3. This would break backward compatibility for OOMRs to analog
quantities.
> > You would only get that problem if you were
automatically
> > concatenating analog blocks - but we are not doing that so there
is
> > no issue, and no need to disallow multiple switch branches.
>
> The problem is in the combination of switch branches, concurrency
> and value retention, but we've been through these moves before as
in
> the email thread started on January 26th.
> (see http://www.eda-stds.org/verilog-ams/hm/1893.html)
> Yes, and I'm saying you have the wrong solution.
A bunch of switch
> branches in parallel is perfectly legitimate hardware, I should be
> able to describe it.
You can, only it's got nothing to do with multiple
analog blocks.
Marq
--
This message has been scanned for viruses and
dangerous content by
MailScanner, and is
believed to be clean.
Received on Thu Apr 19 00:35:10 2007