Re: multiple analog blocks in a module

I'm not sure I like "You cannot put exactly the same code in sub modules
with OOMRs and expect it to work. " - that seems somewhat dysfunctional.

The initial posting implied this was a rewrite rule: i.e. multiple
"analog begin..end" blocks are equivalent to one "analog begin
{begin...end} end". If that's not the case then it needs clarified. If
it is the case I'm not seeing how you can skip the evaluation without a
very smart compiler.

Arbitrary imposition of ordering in parallel descriptions is (IMO) a bad
idea in general (not just for Verilog-AMS). I still have not seen a good
statement of the problem, and as I mentioned using resolved signals for
sharing data removes any races conditions and works for code not in the
same module for the only problem I see wrt to model stability.

"The problem is expanding on a calculation done in a previous analog
block." - as I mentioned analog solver model evaluation is usually
performed on a copy-in/copy-out basis for each analog block, because you
can't do updates until you have an acceptance point, so if you mean
analog blocks interfere with each other during evaluation that is not
likely. If you mean time-step to time-step then you could have a
dependency on variable assignment from the previous cycle iff there are
multiple writers to a variable used in the eval, but restricting shared
variable writes to resolved signals/variables fixes that. I.e. I would
expect a modern simulator to evaluate all analog blocks in parallel in
whatever order is efficient, then at acceptance when variables are
written any shared variables are resolved before continuing. Making the
simulator do arbitrary ordering is only going to slow it down by forcing
serialization of evaluation. A not-so-smart compiler can warn/error out
if post-elaboration analysis shows you have the kind of race conditions
you are worried about - that's a lot easier than trying to
re-parallelize something that has been forced into serial semantics.

Multiple analog blocks in a module where in my original plan for
Verilog-AMS, but Cadence vetoed that and made it a single analog block
because their compiler couldn't handle it. It's much easier to get the
performance gains of "islanding" if you let the users tell you the islands.

Kev.

On 05/25/2012 02:33 AM, Marq Kole wrote:
> Hi Kevin,
>
> With respect to item (a) you will find that you cannot use OOMRs to access variables assigned in an analog block, much less assign them hierarchically. Check the LRM 2.3.1 section 6.7.1 Usage of hierarchical references (page 145). You cannot put exactly the same code in sub modules with OOMRs and expect it to work.
>
> With (b) as said before the choice of evaluation of separate (named) analog blocks can be handled as a compiler optimization - the ordering does not force evaluation.
>
> With (c) the non-determinism is not just with the writing to the same variable from two different analog blocks. If something like this happens in analog we generally let the solver sort it out. The problem is expanding on a calculation done in a previous analog block.
>
> When using loop generate and conditional generate statements you cannot write the code in one analog block as suggested in (d). The whole reason multiple analog blocks appear in LRM 2.3 at all is due to the generate statements. To my knowledge attributes in Verilog are suggestions: no behavior can be inferred from the presence of attributes.
>
> Cheers,
> Marq
>
> -----Original Message-----
> From: Kevin Cameron [mailto:edaorg@v-ms.com]
> Sent: Friday, May 25, 2012 11:00 AM
> To: Xavier Bestel
> Cc: Marq Kole; VerilogAMS Reflector
> Subject: Re: multiple analog blocks in a module
>
>
> My issue is they should not be concatenated because:
>
> a) it potentially gives different results from what you would get if exactly the same code was put in sub modules (with OOMRs)
>
> b) if forces synchronizing/joint-evaluation of otherwise disjoint behavior which impacts performance
>
> c) you can get the desired behavior without concatenating (only allow resolved types when there is shared writing),
> - which also works with the submodule version
>
> d) if you need ordering you could indicate it with parameters/attributes, or you could just write it as one block.
>
> I don't think the ramifications of this have been thought through properly. It might make sense if you have a single-solver Verilog-A only simulator, but it doesn't make sense in a multi-solver/rate mixed-signal context.
>
> Kev.
>
>
> On 05/25/2012 01:16 AM, Xavier Bestel wrote:
>> Kevin,
>>
>> how about specifying that analog blocks semantics make them appear like
>> they are concatenated (that resolves the IMHO important problem of
>> shared variables), and let the compiler detect when there's no ordering
>> dependency and make the blocks independent ?
>>
>> Xav
>>
>> On Thu, 2012-05-24 at 11:24 -0700, Kevin Cameron wrote:
>>> Analog block are evaluated with copy-in/copy-out semantics, so the only
>>> non-determinism is that common variables written from multiple analog
>>> blocks would be disordered, but the same is true for Verilog always
>>> blocks firing on the same event.
>>>
>>> The main goal of the original architecture of Verilog-AMS (as I
>>> envisioned it) was to improve the accuracy of digital simulation by
>>> using existing Verilog digital models with tuned D2A/A2D connect-modules
>>> back-annotated with SPEF. If you ignore cross-coupling that gives you
>>> lots of small analog nets, which means you can parallel process solving
>>> them for a huge speed-up (it's ~ O(N) for a large design).
>>>
>>> Given that you can do that methodology by subsuming the connect modules
>>> into the cell models' module (to skip the auto-insert), it's important
>>> that concatenation is not the default behavior for the disjoint analog
>>> blocks handling the I/O.
>>>
>>> Also (as you mention), in that scenario if an analog input changes, but
>>> the output does not change there is no need to evaluate the output
>>> analog net - another large speed up. I don't think you can mix that
>>> behavior with concatenation as you imply below, if you did then the
>>> probability of odd behavior goes way up (IMO).
>>>
>>> The non-determinism can be fixed by saying that variables written to by
>>> analog blocks should be a resolved type if they are shared (making each
>>> analog block a driver), that way the order is irrelevant because
>>> resolution will give you the same value regardless - that also works
>>> with a multirate simulator.
>>>
>>> If you need to order the evaluation for and/or jointly evaluate analog
>>> blocks for all simulators I suggest adding some extra syntax, rather
>>> than this blanket approach. An alternative approach might be to do it
>>> with block parameters so that it can be done through defparams, e.g.
>>> something like "evaluate_with=<other block name>", "eval_order=<n>".
>>>
>>> Also, ordering the updates coming out of the analog blocks at acceptance
>>> is not the same thing as concatenating their internals, and the former
>>> should be sufficient for the problem you cite.
>>>
>>> Kev.
>>>
>>>
>>> On 05/24/2012 02:00 AM, Marq Kole wrote:
>>>> Hi Kevin,
>>>>
>>>> The problem being solved by fixing the order is determinism and reproducibility of simulation results.
>>>>
>>>> If you want multiple islands then create them as separate modules - if there is no interaction between the elements there is also no problem with making them into separate modules.
>>>>
>>>> In my opinion you largely overestimate the benefit of maximizing islanding in analog - if there is any interaction between separate islands you have more overhead solving the communication issues then you gain from using multi-rate.
>>>>
>>>> If you take another look at the current standard text you will see that there is nothing that stops you from applying multi-rate on the separate analog blocks. If we assume multi-rate to mean that a specific analog block can skip evaluation then that is a compiler/simulator internal optimization. Already in current Verilog-A(MS) compilers named blocks will not be evaluated if none of their inputs (dependents) change. However, for the blocks that do get evaluated during the current time-step the order is fixed - they will be evaluated in the order they appear in the module source text.
>>>>
>>>> Cheers,
>>>> Marq
>>>>
>>>> -----Original Message-----
>>>> From: Kevin Cameron [mailto:edaorg@v-ms.com]
>>>> Sent: Thursday, May 24, 2012 10:37 AM
>>>> To: Marq Kole
>>>> Cc: VerilogAMS Reflector
>>>> Subject: Re: multiple analog blocks in a module
>>>>
>>>>
>>>> I still don't see what problem is solved by saying that multiple analog blocks in a module are equivalent to concatenating the statements into one block. Also, I see no reason to exclude folks from doing multi-rate/islanding if that is possible - the analog blocks can easily be in separate analog islands in a mixed signal context, e.g. if you have analog in and out interfaces to a digital core in one module, this will screw up the opportunity to accelerate the simulation (the ins and outs being in separate islands).
>>>>
>>>> A specific goal in my original design was to maximize islanding to minimize the need for large matrices, this would work against that.
>>>>
>>>> If anyone thinks there is particular benefit to this behavior they are free to make it an option on their simulator, but I think it's a really bad idea to have it be the default.
>>>>
>>>> Kev.
>>>>
>>>> On 05/24/2012 01:04 AM, Marq Kole wrote:
>>>>> OK, I'll bite :-)
>>>>>
>>>>> First a few basic statements:
>>>>> - Analog blocks contain model code that is ultimately handled in the matrix solver (SPICE solver).
>>>>> - Although multi-rate analog solvers exist, they are not commonplace and have inherent problems and limitations that prevents them from being used in high-performance SPICE engines like ADS, AFS, Finesim, Spectre, Hspice and Eldo. Multi-rate analog solvers do not use a fine-grained partitioning - that is fundamentally too expensive due to the complexity of aligning the multiple partitions. Multi-rate is only beneficial if there are multiple analog "islands" in the design that have no interaction. So at the module level a multi-rate solver should be considered single-rate. So for the discussion we can assume that the matrix solver is single-rate.
>>>>> - Due to the single-rate solver all analog blocks are executed at exactly the same simulation time, i.e. the time controlled by the analog time-stepping control of the matrix solver.
>>>>> - Design teams (and tool developers, too) want deterministic behavior from the analog/mixed-signal simulation engines.
>>>>>
>>>>> Unlike the event driven engine the analog engine has no user-controlled mechanisms to modify the evaluation order of separate concurrent (analog) blocks - the concept of blocking is non-existent inside the analog block. At every time step all analog blocks are evaluated. The only way in which the evaluation order of multiple analog blocks inside the same module can be guaranteed is by fixing that order. The most logical way of doing that is by taking them in the order they appear in the module body.
>>>>>
>>>>> Although I concede there are many situations where multiple analog blocks could be evaluated in arbitrary order without consequence to the evaluation results, there is also no benefit from evaluating them in arbitrary order: if the results does not change any order is fine - also a fixed order.
>>>>>
>>>>> Finally, in model optimization and debugging a fixed (deterministic) order is by far preferred over an arbitrary order.
>>>>>
>>>>> Cheers,
>>>>> Marq
>>>>>
>>>>> -----Original Message-----
>>>>> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Kevin Cameron
>>>>> Sent: Wednesday, May 23, 2012 8:06 PM
>>>>> To: Geoffrey Coram
>>>>> Cc: Dave Miller; VerilogAMS Reflector
>>>>> Subject: Re: multiple analog blocks in a module
>>>>>
>>>>>
>>>>> I'm still not seeing what problem is being solved. As I said before: if
>>>>> you are just in-lining an analog block from a submodule there's no
>>>>> particular reason I can see why it would suddenly have ordering it
>>>>> didn't before - that way madness lies.
>>>>>
>>>>> Kev.
>>>>>
>>>>> On 05/23/2012 03:16 AM, Geoffrey Coram wrote:
>>>>>> In this particular case, the user wanted a structural genvar loop,
>>>>>> like this example from the LRM:
>>>>>> // "generate" and "endgenerate" keywords are not required.
>>>>>> for (i=0; i<`N; i=i+1) begin
>>>>>> resistor #(.r(Rsec)) R(n[i], n[i+1]);
>>>>>> capacitor #(.c(Csec)) C(n[i+1], gnd);
>>>>>> end
>>>>>>
>>>>>> and they replaced it with a genvar loop of analog blocks,
>>>>>> each of which implemented a resistor and capacitor. It
>>>>>> was this genvar loop idea, I believe, that led the committee
>>>>>> to decide that multiple analog blocks should be concatenated.
>>>>>>
>>>>>>
>>>>>> Kevin Cameron wrote:
>>>>>>> I don't understand why you would want to do this. What problem does
>>>>>>> it solve?
>>>>>>>
>>>>>>> The problem with the switch branch is that if you don't concatenate,
>>>>>>> it's just a voltage contribution and won't be overridden by the
>>>>>>> current contribution (so it's not a switch branch).
>>>>>>>
>>>>>>> As a user I would expect separate analog blocks in submodules to
>>>>>>> behave the same if subsumed into a parent as separate blocks, and
>>>>>>> ordering to have no effect. Arbitrary context dependency is a really
>>>>>>> bad idea.
>>>>>>>
>>>>>>> I'm fairly sure Cadence had something like this in an earlier LRM
>>>>>>> (and it didn't make sense then).
>>>>>>>
>>>>>>> It's particularly bad if you are trying to optimize blocks that
>>>>>>> simulate at different rates, i.e. this forces you to use the same
>>>>>>> time-step on blocks which could be handled independently and will
>>>>>>> increase the computation you have to do.
>>>>>>>
>>>>>>> Kev.
>>>>>>>
>>>>>>>
>>>>>>> On 05/22/2012 03:34 AM, Geoffrey Coram wrote:
>>>>>>>> Kev -
>>>>>>>> This concatenation was added only recently (post-2.2); I am working
>>>>>>>> on the
>>>>>>>> implementation in our simulator, not complaining about any
>>>>>>>> commercial tool.
>>>>>>>> We had a whole discussion about this in the committee, and those of
>>>>>>>> us who
>>>>>>>> participated decided that concatenation was the best solution.
>>>>>>>>
>>>>>>>> Of course the two I(a)'s add; that's the way the contribution operator
>>>>>>>> has always worked in the analog block. Indeed, switch branches are
>>>>>>>> potentially confusing, but the LRM describes how to handle them in one
>>>>>>>> analog block, and therefore this statement:
>>>>>>>>
>>>>>>>>>> In other words, they are concatenated in the order they appear in the
>>>>>>>>>> module.
>>>>>>>> now allows us to know what to do when they are spread across multiple
>>>>>>>> analog blocks.
>>>>>>>>
>>>>>>>> -Geoffrey
>>>>>>>>
>>>>>>>>
>>>>>>>> Kevin Cameron wrote:
>>>>>>>>> My rule on this kind of thing is that a) you follow the scoping
>>>>>>>>> rules of Verilog, and b) it shouldn't matter where the analog
>>>>>>>>> blocks are located (or their order), since you wouldn't (as a
>>>>>>>>> Verilog user, and hardware engineer) expect that to make a difference.
>>>>>>>>>
>>>>>>>>> My Verilog says x is not accessible from block2, but using
>>>>>>>>> "block1.x" works.
>>>>>>>>>
>>>>>>>>> The order of evaluation of separate analog blocks shouldn't make a
>>>>>>>>> difference, if it ever did it was because of something
>>>>>>>>> dysfunctional in Cadence's simulator. As such I don't think Dave's
>>>>>>>>> rewrite is an equivalent of Geoffrey's original, you would not
>>>>>>>>> expect any ordering like that to be enforced with digital processes
>>>>>>>>> (always blocks). If you put the blocks in separate modules I think
>>>>>>>>> you would expect to get the same behavior as being in the same
>>>>>>>>> module, and there is definitely no ordering there.
>>>>>>>>>
>>>>>>>>> I would suggest striking the text that says the blocks
>>>>>>>>> concatentenate. If it was treated that way you then have the
>>>>>>>>> question of what happens with the two "I(a)"s - do they add or does
>>>>>>>>> the second override the first. If I add another block with a "V(a)"
>>>>>>>>> assignment between the "I(a)"s, that would imply switch-branch
>>>>>>>>> behavior in the concatenated block - which confusing at best.
>>>>>>>>>
>>>>>>>>> Block ordering in evaluation should not have any effect (on analog
>>>>>>>>> results) since the analog processes are evaluated with
>>>>>>>>> copy-in/copy-out semantics. The only non-deterministic behavior
>>>>>>>>> would be any updates to variables from the analog processes, and
>>>>>>>>> you would expect similar non-determinism with digital processes.
>>>>>>>>>
>>>>>>>>> Kev.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 05/21/2012 11:04 AM, Dave Miller wrote:
>>>>>>>>>> If I remember correctly, the idea behind the "concatenated in the
>>>>>>>>>> order they appear in the module" stmt was so we could define the
>>>>>>>>>> order in which the blocks are evaluated, avoiding problems with
>>>>>>>>>> OOMR etc.
>>>>>>>>>>
>>>>>>>>>> So in your example below I would interpret it to be equivalent to:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> analog begin
>>>>>>>>>> begin : block1
>>>>>>>>>> real x;
>>>>>>>>>> x = V(a);
>>>>>>>>>> I(a) <+ x * 1.0;
>>>>>>>>>> end
>>>>>>>>>> begin : block2
>>>>>>>>>> x = V(a);
>>>>>>>>>> I(a) <+ x * 2.0;
>>>>>>>>>> end
>>>>>>>>>> end
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> As such, the reference to variable 'x' in block 2 is illegal as it
>>>>>>>>>> is out of scope.
>>>>>>>>>> So x = V(a) is illegal as we are assigning to a variable declared
>>>>>>>>>> in another scope (5.3.2)
>>>>>>>>>>
>>>>>>>>>> Reference of x in the contribution should be using the
>>>>>>>>>> hierarchical name:
>>>>>>>>>> I(a) <+ block1.x * 2.0;
>>>>>>>>>>
>>>>>>>>>> If you wish to assign to 'x' in block2, you would need to declare
>>>>>>>>>> 'x' in the module scope.
>>>>>>>>>>
>>>>>>>>>>> And, if x had been declared in block2, is the compiler required
>>>>>>>>>>> to keep block1.x distinct from block2.x ?
>>>>>>>>>> Yes (5.3.2) variables declared in blocks are distinct/unique. So
>>>>>>>>>> the compiler would keep them separate (same goes for parameters
>>>>>>>>>> declared in named blocks.
>>>>>>>>>>
>>>>>>>>>> At least that is how I interpret the use of named blocks and
>>>>>>>>>> variables etc.
>>>>>>>>>>
>>>>>>>>>> Cheers...
>>>>>>>>>> Dave
>>>>>>>>>>
>>>>>>>>>> On 05/21/2012 11:26 AM, Geoffrey Coram wrote:
>>>>>>>>>>> Hi -
>>>>>>>>>>> I have some questions about multiple analog blocks, working from
>>>>>>>>>>> LRM 2.3.1.
>>>>>>>>>>>
>>>>>>>>>>> In section 5.2, it says
>>>>>>>>>>> Multiple analog blocks can also be used within a module declaration.
>>>>>>>>>>> Refer section 7.1 for more details on multiple analog blocks
>>>>>>>>>>>
>>>>>>>>>>> but 7.1 doesn't seem to be the right section. I found some more on
>>>>>>>>>>> multiple analog blocks in 6.2, which says:
>>>>>>>>>>>
>>>>>>>>>>> A module definition may have multiple analog blocks. The behavior
>>>>>>>>>>> of multiple analog blocks shall be defined by assuming that the
>>>>>>>>>>> multiple analog blocks internally combine into a single analog block
>>>>>>>>>>> in the order that the analog blocks appear in the module
>>>>>>>>>>> description.
>>>>>>>>>>> In other words, they are concatenated in the order they appear in
>>>>>>>>>>> the
>>>>>>>>>>> module. Concurrent evaluation of the multiple analog blocks is
>>>>>>>>>>> implementation dependent as long as the behavior in that case is
>>>>>>>>>>> similar to what would happen if they had been concatenated.
>>>>>>>>>>>
>>>>>>>>>>> What I don't see is any discussion of how one concatenates *named*
>>>>>>>>>>> analog blocks -- and the scope of variables declared therein.
>>>>>>>>>>>
>>>>>>>>>>> analog begin : block1
>>>>>>>>>>> real x;
>>>>>>>>>>> x = V(a);
>>>>>>>>>>> I(a) <+ x * 1.0;
>>>>>>>>>>> end
>>>>>>>>>>> analog begin : block2
>>>>>>>>>>> x = V(a);
>>>>>>>>>>> I(a) <+ x * 2.0;
>>>>>>>>>>> end
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I would expect this to be illegal, since x is not declared in
>>>>>>>>>>> block2,
>>>>>>>>>>> but I don't know what the concatenation looks like. And, if x had
>>>>>>>>>>> been declared in block2, is the compiler required to keep block1.x
>>>>>>>>>>> distinct from block2.x ?
>>>>>>>>>>>
>>>>>>>>>>> -Geoffrey
>>>>>>>>>>>
>>>>>>>>>>>
>

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