Re: [sv-dc] Re: Verilog-AMS Committee Call - 28th Apr 2011

On 4/27/2011 12:37 AM, Kevin Cameron wrote:
> [Doubt I'll make a 6:00am call.]
>
> Gordon posted some examples - http://www.eda-twiki.org/sv-dc/hm/0311.html
>
> The examples in general are confusing instantiation statements with routine calls. Instantiation is mostly about connecting wires properly, and not about a single data transfer (as in a routine call). As mentioned before: types on ports in a module primarily tell you the type of receivers in the module, secondly any drivers, and nothing about the net unless you add a discipline.

Kevin,

Can you explain why you think I am confusing instantiation with routine
calls?
The example has port connections that would be completely legal in existing
digital SV with a real var port and would produce the output that I'm
saying.
So why do you think I am confused in my examples?

Now you may be thinking that in an ideal world you would like to think
about such connections in terms of "connecting wires properly", but the
existing **SystemVerilog** rules are clear about existing semantics and
type conversion rules on port instantiation boundaries. So assuming
that you
don't want to rewrite all of digital SV, you have to live within the
bounds of
those rules.

Adding new constructs (AMS disciplines, etc) would be a reasonable
option to consider at some point as one possible mechanism for dealing
with the semantic domain mappings but my key point is that we
must work within existing SV semantics and keep the rules for any
new constructs (ie. nettypes) extremely tight so that we have the option
of doing more useful mappings later on. Allowing the default SV
conversion rules to interact with nettype connection rules will likely
pose problems for the future and is what I do NOT want to allow that
at this point.

Pure SV example based on my earlier examples:

     module child(input var real w);
       always @(w) begin
           $display("%m w is %g", w);
       end
     endmodule

     module top;
        wire w = 1;
        real r = 2.0;
        integer i = 5;

        child c1(1'b1);
        child c2(3.5);
        child c3(w);
        child c4(r);
        child c5(i);
    endmodule

Produces:
   # top.c1 w is 1
   # top.c2 w is 3.5
   # top.c3 w is 1
   # top.c4 w is 2
   # top.c5 w is 5

Any compliant SV simulator will produce the above result.

Gord.

> A rather worrying example is the automatic conversion of a logic '1' to 1.0 as a real. In an AMS context you would probably expect that case to be handled by an A2D connect module to give you Vdd rather than 1.0. I can see this causing problems crossing power domains. The inclusion of Verilog-AMS disciplines into SV would help solve that problem.
>
> The proposal does not address how primitives will work or any back-annotation methodology.
>
> Given that there is still only one standing proposal for how to do back-annotation for Verilog-AMS -
>
> http://www.eda-twiki.org/cgi-bin/view.cgi/VerilogAMS/BackAnnotationProposal
>
> - which is equally applicable to SystemVerilog, I would recommend any proposal for discrete analog types in SV should support that back-annotation scheme (unless someone can come up with a better one that works for both).
>
> Resolution and type conversion functions should be definable outside of the driver/receiver types (nettypes), since they may need to be defined later in the design process when modules are reused in new contexts (as is done with the AMS connect rules).
>
> Kev.
>
>
> On 04/26/2011 11:22 AM, Dave Miller wrote:
>> Hello all,
>> We have a call scheduled for Thursday 28th Apr 2011.
>>
>> Agenda:
>> * SV-DC proposal. People have had a couple weeks to go over the proposal. If there are any issues that people have identified that will impact the AMS merge with SV, now is the time to raise them. This will allow us to pass them on to SV-DC so they can take them into consideration before they go to the champions committee.
>>
>> * Verilog-AMS representation in the SV-DC. Sri will discuss what this means.
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.