multiple analog blocks

All,

Although it momentarily seemed that section 7 was nearly at the end of the 
review, I cannot escape the notion that there is still no resolution on 
the multiple analog blocks issue. Let me rephrase the possible options 
brought forth during the past couple of weeks discussion.

0) (current situation) multiple analog blocks are not supported.

1) multiple analog blocks in a single module are supported under the 
condition that during elaboration they are concatenated into a single 
analog block. The consequence is that analog blocks differ from always and 
initial blocks in that their order of appearance is important. This 
prevents ambiguity/race conditions in the model behavior.

2) multiple analog blocks in asingle module should behave as though they 
were implementing separate entities and therefore their order of 
appearance should not matter. Analog blocks are considered to be run 
concurrently; ambiguity/race conditions need to be resolved through better 
programming.

Question: Does this correctly reflect the current state of the discussion?

Provisionally assuming an affirmative answer to the above question, let me 
try to phrase the pros and cons to above positions

0)      Pros:   (a) clear situation, no ambiguity/race conditions can 
occur.
                (b) protects model creator from having to deal with 
concurrency.
        Cons:   (a) no support possible for analog blocks in generate 
constructs.

1)      Pros:   (a) situation just as clear as 0), but now support for 
analog blocks in
                      generate constructs.
                (b) model creator still does not have to deal with 
concurrency.
        Cons:   (a) conceptual difference between always blocks and analog 
block
                (b) no opportunity for optimization based on activity of a 
particular
                      analog block as all blocks are essentially 
concatenated together.

2)      Pros:   (a) analog blocks and always blocks have similar 
semantics,
                      possibly easier for mixed-signal model developers.
                (b) allow activity-based simulation performance 
optimization per
                      analog block.
        Cons:   (a) concurrency issues (race conditions) enters 
analog/mixed-signal
                      environment
                (a1) handling of module-level variables
                (a2) handling of OOMR variables
                (a3) switch branches
                (a4) value retention
                (b) supports "bad" programming

Question: Are the above pros and cons correct? Is anything missing?

My hope is that if we can get some sort of agreement on the current 
situation of the discussion, we may get to a resolution on this item for 
section 7 for the coming LRM update.

Cheers,
Marq


Marq Kole
Competence Leader Robust Design

Research
NXP Semiconductors