Re: multiple analog blocks in a module

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.