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.