Re: multiple analog blocks

Hi all,

Marq, firstly thanks for summarizing the different points of view in a 
single email. I think this is useful to understand what the different 
threads of discussions are for this feature.

It definitely looks like we would have to move out of option 0. There
has been fairly repeated requests for supporting multiple analog blocks 
  and also to be in line with the new features from digital we are 
implementing in the AMS language. In my opinion, its best to go with 
option (b) to keep things simple and it addresses the problem of being 
able to use analog blocks within the generate syntax which was the 
original requirement.

Having said that, I understand the need to put in certain additional 
capabilities and not make things restrictive if we can avoid it - 
however, I get a feeling that we are overly complicating the issue here, 
putting in lot of new features, suggestions & design methodology (and 
along with it lot of new syntax) making the language fairly complex.

I would prefer to keep the language simple & easy to use. If it doesn't 
do this, the best of features might completely go unused by designers no 
matter what the tool does. I prefer the implementations (tools) being 
more advanced in dealing with things (pushing implicit optimizations to 
the EDA tool developers) rather than complicating on how it should be 
specified in the design. This would also impact portability of designs 
across the different simulation tools. In this sense, I agree with 
Geoffrey's comments on making the tool/compilers more aware and taking 
advantages and optimizing the design and simulation as is seen fit.

It might be good to take a step back and ff we can list out the 
requirements related to multiple analog blocks (and also the initial 
blocks) it might help us resolve the best approach and we can analyse 
what we would have to sacrifice if we take a particular approach.

We will discuss further on these in tomorrow's call.

Regards,
Sri

PS: Also, please keep the discussions purely technical. This reflector 
is not meant to reflect personal opinions but to share technical ideas 
on how to develop & enhance the Verilog-AMS language which best serves 
the design community and tool developers.



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.
> 
> 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

-- 
Srikanth Chandrasekaran
DTO Tools Development
Freescale Semiconductor Inc.
Ph: +91-120-439 7021 F: x5199