Re: disallow distributed switch branches

Marq Kole wrote:
>
> 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 no procedural language I know does the behavior of a statement change 
just because you move it from one context to another (given no type 
changes).
> 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.
Yes but that's pretty much irrelevant to simulation semantics.

If you move digital Verilog statements around you wouldn't expect their 
behavior to change.
>
> <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.
Scope is irrelevant. I can't find anything that says contributions 
should sum between between independent analog blocks (other than what 
you have written).

Your OOMR argument doesn't appear to have anything to do with the issue 
either since we are only discussing the branch summing semantics and 
switch branch behavoior.
>
> > > 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.
You are proposing that describing that behavior within a single module 
in multiple analog blocks will be disallowed.

I don't see how that makes any sense.

Kev.

>
> Marq
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 


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