Re: Some merged_datatype.pdf feedback.

Hello Ken,

Please see my comments below:

> 1. In the 2.2 LRM the event_control syntax definition seems ambiguous.
>    The event_control statement is defined in terms of an
>    event_expression, but an event_expression is never defined. Rather
>    analog_event_expression and digital_event_expressions are defined,
>    but it is never made clear how they relate to an event_expression.
>   
> 2. It does not appear as if one can trigger a named event within an
>    analog block (the -> operator is not mentioned in the 2.2 LRM from
>    what I can tell).
>   

I'm aware of a number of these event expression related problems in LRM
2.2. Have a look at the event expression syntax of
http://www.verilog.org/verilog-ams/htmlpages/public-docs/merged_syntax.pdf.
Does this address your needs?

> 3. A change in an analog discrete variable (an integer) cannot trigger
>    a change in a continuous assignment nor in an event expression.
>    (This is ambiguous in the LRM and not allowed in the Cadence
>    implementation.)
>   

Agreed, it would be help for continuous assignment statements to be
sensitive to discrete integer variables. IF this is to be allowed then
it should be document in section 6.

> Note, between restrictions 2 & 3, it is not possible to have analog
> behavior trigger changes in digital signals without there being a cross
> function involved, and and one cannot use cross functions on integers.
>
> 4. Cannot have multiple analog blocks. This unnecessary restriction
>    forces dissimilar behavior to be combined into a single block,
>    which is unlike the original Verilog language. It also limits
>    the language support for multirate simulation techniques.
>   

Agreed multiple analog blocks would be useful to better organize the
contents of a large mixed-signal module to be more modular instead of
lumping the analog behavior together (away from it related digital
blocks) in one part of a module description.

> 5. At some point I remember there being a restriction that a node
>    declared as being ground could not be the first node listed in
>    an access function, but I cannot find that restriction in the
>    v2.2 LRM. Is that still a restriction? If so it should be removed
>    as it means that the behavior must be written knowing which node
>    is ground, making it more difficult to copy and paste code fragments.
>   

Yes, I believe it has been removed. Currently nothing is documented
about ground terminals. I figure it was good to add a short  statement
to the affect that ground nets are treated no different to non-ground
nets when used as branch terminals.

> 6. It would be nice to have real valued variables act as registers.
>    In other words, it would be nice if reals could act as ports without
>    needing a continuous assignment to a wreal. In this way real becomes
>    something like a 64 bit register with implied $realtobits() and
>    $bitstoreal() conversions, with the difference being that you could
>    use a scalar wire to connect to the port. It would be important
>    to pass this enhancement back to verilog itself, along with the
>    need for a wreal, as this represents an large issue when trying
>    to use Verilog-AMS to develop pure verilog models of analog IP.
>    To develop a pin accurate verilog model of analog IP you need to
>    have a simple scalar pin for each bias line (vdd, vss, etc.),
>    and that pin needs to pass a real value. Today you cannot do
>    this with verilog, you need a 64bit buss, meaning that the model
>    is no longer pin accurate.
>   

I would also include connectmodules with a wreal digital port need to be
considered. OK, connectmodule don't support vector digital ports, and
wreal is treated as a 64-bit vector. The difference is that the wreal
vector is always treated as a scalar.

> 7. Cadence's implementation does not support transition sensitivity of
>    a digital register in an analog block. Thus, ...
>        analog begin
>            @(regvar)
>                ;
>            ...
>        end
>    is not allowed if regvar is associated with the digital context. I
>    tried this with regvar being both a real number and a register. When
>    using a register I could replace it with "posedge regvar or negedge
>    regvar" and it worked). I believe support for this feature is implied
>    in the current LRM but not completely spelled out. It would be good
>    if we could clearly indicate that this was supported, and that regvar
>    is allowed to be a real variable associated with a digital context.
>   

The latest merged syntax should make it clear that this type of event is
allowed in the analog context. I also wish that Cadence
implementation would  support this type of event to.

> 8. Currently $bitstoreal() et al is not supported within an analog
>    context.
>   

Agreed.

> 10. Finally, this is probably a longer term project, but we need to take
>    on the issue of making connect modules sensitive to power supplies,
>    particularly local power supplies. With the heavy emphasis on power
>    management, and the associated use of multiple power domains and the
>    disabling and enabling of power supplies, this is becoming
>    increasingly important.
> 


I absolute agree. I have been regularly encountering similar problems in
my work, the current work-around is tedious and results in slower
simulations. Like Jonathan, I'll be happy to help define a solution to
this problem.

Regards
Graham



-- 
==========================================================
Graham Helwig
AMS Verification
Australian Semiconductor Technology Company (ASTC) Pty Ltd

Location: 76 Waymouth St, Adelaide, SA, 5000, Australia
Phone     +61-8-82312782
Moblie:   +61-4-03395909
Email:    graham.helwig@astc-design.com
Web:      www.astc-design.com
==========================================================