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

On 04/27/2011 07:30 AM, Gordon Vreugdenhil wrote:
>
> 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.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?

Maybe it's legal, but it's not really representative of any interesting cases, and as I pointed out: the case of passing a logic '1' is being handled entirely differently from what you would expect as a hardware engineer if you tied a wire to Vdd.

Legality is somewhat irrelevant if the goal is to accurately model hardware and you are failing to do it. Also, legality is not necessary with new constructs and semantics - the semantics should be defined first, syntax rules second.

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

The golden reference is not the LRM, it's what actual hardware would do. Also, I have repeatedly said there is no intention on my part to invalidate existing SystemVerilog, or change it's behavior in simulation, implying otherwise is disingenuous.

You seem to be approaching this from what the minimum change you are prepared to make to your simulator is, rather than attempting to support mixed-signal discrete modeling to tackle problems like power-management and the fact that most of the fan-out load for logic is now wiring.

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

On what authority are you "NOT" allowing anything?

If you are going to constrain yourself to working "within existing SV semantics" then you are not going to be doing anything new - and adding new features is the point of this committee. So I'm wondering what your motivation is other than stopping the committee doing anything, and if so, should we consider your proposal at all?

We already have most of the syntax and semantics defined for connecting logic and (precision/continuous) analog in Verilog-AMS, it's just a question of incorporating that into SV and filling in the spectrum of behavior.

NB: a lot of Verilog-AMS was defined in committee before anyone implemented it.

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

And again, that's the view I would expect from a computer scientist looking at it as a routine-call style conversion. From a hardware design perspective I would expect the w=1 to translate as a wire tied to Vdd, and I would probably expect the 5 to be treated as a 3-bit value (probably on 32 wires per the Verilog behavior) - and as such an invalid connection.

Just because something is legal syntax doesn't mean it's doing the right thing - any C programmer can tell you that.

I think the proposal needs a lot more work. Also, the discrete modeling problem should be tackled from the perspective of solving at least one real problem in design flows, rather than an abstract exercise in type conversion.

Kev.

>
>
> 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.org/twiki/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.
>>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.