Re: Elaboration algorithm proposal

Dave Miller wrote:
> edaorg@v-ms.com wrote:
>> /Marq Kole wrote
>> Concatenation of the analog blocks occurs after all generate 
>> constructs have been evaluated, i.e. after the loop generate 
>> constructs have been unrolled, and after the conditional generate 
>> constructs have been selected. If an analog block appears in a loop 
>> generate statement then the order in which the loop is unrolled 
>> during elaboration determines the order in which the analog blocks 
>> are concatenated to the eventual single analog block after elaboration. /
>> This sounds bad to me. As a user I would expect to get the same 
>> behavior if I put the /analog/ blocks in the same module or in 
>> separate modules if their connectivity is the same - I don't see that 
>> being the case if the blocks get concatenated. Reodering /always/ 
>> blocks in Verilog doesn't change the behavior, the same should be 
>> true for /analog/ blocks.
>>
>> I think there should be an explicit statement to the effect that: the 
>> reordering of /analog/ blocks within a module or declaring them in 
>> seperate modules should not change the results of simulation for pure 
>> analog (to exclude A/D issues at ports).
>>
>> Kev.
>>>
> But the order of the analog blocks and execution of them does change 
> the simulation results. Ignoring generate blocks, consider just a 
> situation of two analog blocks in the one module.
>
> module bb();
>    electrical a;
>    real x;
>    analog begin
>       x = x + 5;
>       V(a) <+ x;
>    end
>    analog begin
>       x = 1;
>    end
> endmodule
>
> V(a) gets the value of 5, 6, 6, 6, .......
>
> Swap them around and V(a) gets 6, 6, ....
>
> Okay not the best example but you get what I mean.
>
> So the analog blocks should be concatenated in the order that they are 
> written, and the user should be aware that assignment statements in 
> particular are executed in a procedural manner.
No, wrong conclusion.

This should remain indeterminate. If you want the specific ordered 
behavior then you should write one analog block.

The example above is just bad programming that relies on a particular 
implementation. If you made the value 'x' global and put the analog 
blocks in different modules you wouldn't expect to get any ordering. 
Digital designers writing always blocks don't expect them to be ordered, 
analog should follow that.

A chunk of the LRM I wrote a while back is intended to guarantee that 
you can treat analog blocks as separate processes that can be solved in 
parallel, doing concatenation destroys that. This has significant impact 
when you have processes running at different rates or with disjoint 
input/output sets, e.g. if you put an analog block for the thermal model 
in the same module as the analog block for electrical model then you 
will force the simulator to re-evaluate both calculations for all events 
for each.

More specifically: not concatenating the blocks means that as a module 
gets larger and you decide to split it into multiple modules there 
should be no change in the behavior just because you moved the analog 
blocks into sub modules.

Kev.
>
> Dave
>
>