RE: multiple analog blocks in a module

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.