Re: multiple analog blocks

Marq Kole wrote:
>
> 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.
                                     (c)     manually inlining modules 
can change the behavior of the analog blocks therein.
>
> 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.
                                     (c)    supports efficient programming
>           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?


I think you missed my suggestion in the last e-mail that we add some 
syntax and have it both ways, e.g. (taking Dave's example):
  ...
   analog begin
     c = cap;
     I(p, n) <+ V(p, n)/r;
   end
   ....
   analog begin
     r = res;
     V(p, n) <+ idt(V(p, n)/c);
   end

Could be written as:
  ...
   analog begin : continue rc  // the /continue /here is optional, the 
name isn't
     c = cap;
     I(p, n) <+ V(p, n)/r;
   end
   ....
   analog begin : continue rc
     r = res;
     V(p, n) <+ idt(V(p, n)/c);
   end

which is equivalent to (or some other rearrangement if you prefer):

   analog
     begin : rc
         c = cap;
         I(p, n) <+ V(p, n)/r;
         r = res;
         V(p, n) <+ idt(V(p, n)/c);
     end

That allows you to concatenate some blocks and not others, so you can 
concatenate those inside a generate and leave the rest autonomous. 
Testing your code to see if it has non-continuous analog blocks is 
fairly easy (if you want to do that).

> 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.
I'd say the syntax/semantic extension is the easiest way forward since 
everyone can get what they want.

Kev.
>
> Cheers,
> Marq
>
>
> Marq Kole
> Competence Leader Robust Design
>
> Research
> NXP Semiconductors