Re: Potential Contributions

Ken,

I like your point of view - I see that I made this silent assumption of 
associating unnamed branches with analog blocks rather than the module in 
my discussion document while it should have been an explicit choice. I'll 
update the document to reflect this notion.

My comments are in the text below.

Cheers,
Marq


Marq Kole
Competence Leader Robust Design

Research
NXP Semiconductors


Ken Kundert <ken@designers-guide.com> wrote on 31-01-2007 21:02:42:

> Kevin,
>     Indeed, the loop of voltage sources issue is a tangent. Concerning
> the original issue, I would have to say that I am not yet in agreement.
> 
> I have wanted multiple analog block in a module to improve the
> modularity of my models. I would like to describe distinct effects each
> in their own analog blocks, and perhaps be able to enable or disable
> them by enabling or disabling the block. I have found this to be
> particularly desirable in Verilog-AMS testbench modules. For example, a
> typical test bench module for a complicated mixed-signal circuit would
> have many have hundreds or thousands of lines of code, and tens or
> hundreds of initial and always blocks that are used to perform
> individual tests and set drive, load, or bias conditions. It is nice to
> be able to group these together, so that, for example, all supply
> related code is together, all stimulus related code is together, etc.
> Consider the supply related code. In a mixed signal design it will
> contain both analog and event-driven behavior. The event driven behavior
> might determine which supply signals should be enabled and the analog
> code would actually create the supply signals for the analog portion of
> the design.
> 
> To see why it is undesirable to associate unnamed branches with the
> block rather than the module consider the model of a nonlinear lossy
> inductor. Assume that there is a logical separation of the model into
> code that describes the nonlinear inductor and code that describes the
> loss. If I put these into one analog module (and assuming that they both
> contribute to the potential of the branch) then they would go in series.
> However, if they were each in their own analog blocks they end up in
> parallel, which is not what I wanted.

That is only true if you described them as potential branches: flow
branches would give you the desired effect (summation) by being in
parallel. In that sense it can be said to be a matter of modelling.

> Presumably I could address this issue in one of two ways. Either I could
>  force them to be combined in series by creating a named branch and have
> them both contribute to that. Or I could combine both effects into a
> single analog block and separate them by placing them both in their own
> named blocks. The former is undesirable because I am forced to use named
> branches. The latter is undesirable because it constrains the modulatity
> (all analog behavior must be adjacent, and cannot be intermingled with
> the event-driven behavior).

The latter would be addressed by the some options of the continued analog
construct proposal in my document Multiple_Analog_Blocks_v1.pdf.

> The rationalization for associating unnamed branches with analog blocks
> rather than with the module seems a bit of a cop out. It basically
> results in branches from different blocks being combined in parallel.
> But in a multirate setting if we can combine branches in parallel, why
> can't we also combine them in series. Wouldn't the same basic techniques
> apply? And if for some reason we cannot combine them in series, then
> what do we do about named branches declared at the module scope?

I guess you mean branches in series as a figure of speech as a real
series of branches would require internal nodes and an increase of the
system to solve?

> One more thing. I noticed in the v2.3 syntax that a named branch cannot
> be declared in an analog block. This, combined with the current
> proposal, implies that unnamed analog branches are associated with
> blocks and named branches are associated with modules. This means that
> named branches would no longer be a superset of unnamed branches. This
> is problematic because the expressive ability of unnamed branches is
> less than named branches, meaning that there will be some things that
> you can do at the module level that you cannot do at the block level.
> That does not seem like a good idea to me.
>
> Instead, I recommend:
> 1. associating the unnamed branches with the module
> 2. specifying the behavior of multirate contributions so that they are
> the same for both named and unnamed branches

Could you explain what you mean here?

> 3. allow named branches to be declared within analog blocks

The last one puzzles me: what would be the advantage of having a named
branch in the analog block? Wouldn't it be more appropriate to keep
named and unnamed branches semantically close by specifying that they
are both associated with the module rather than the analog block?
 
If a named branch is associated with a single analog block, does that
mean that other analog blocks cannot contribute to it? I don't think
current upward hierarchical reference functionality supports that.

Named branches can already be declared inside generate blocks according
to the proposed section 7 text and syntax. Wouldn't that be sufficient?
Still, using the upward hierachical referencing other blocks are able to
contribute to such a branch.

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