Re: multiple analog blocks in a module

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.