Subject: RE: resolveto statement's discipline list constraint
From: Martin O'Leary (oleary@cadence.com)
Date: Mon Jan 28 2002 - 15:04:29 PST
Graham,
I can see how your approach gives the user more flexiblity with
the default (basic) discipline resolution method. Thanks for
the example outlining this.
However, a concern I have whether (how?) this approach will work
with the detailed discipline resolution method - when
analog is pushed down.
Thanks,
--Martin
> -----Original Message-----
> From: Graham Helwig [mailto:ghelwig@asc.corp.mot.com]
> Sent: Wednesday, January 16, 2002 2:53 PM
> To: Verilog-AMS Committee
> Subject: resolveto statement's discipline list constraint
>
>
> Hello,
>
> Based on the LRM conference call on 15 jan 2002, the following email
> with examples has been sent. This discussion started with a
> question why
> the disciplines of the discipline resolution connect
> statement (section
> 8.7.2 LRM version 2.0) is constrained to be compatible with
> each other.
> This prevents discipline resolution connect statement like below to
> occur:
>
> connect cmos1 electrical logic resolveto cmos1;
> connect kinematic electrical mechanical resolveto mechanical;
>
> According to section 8.4.4, it is assumed that continuous nets have
> precedence over discrete nets. This applies to both basic and detailed
> discipline resolution algorithms.
>
> During the conference call it was discussed whether the LRM
> should have
> such a constraint within the discipline resolution connect statement,
> and
> actually be able to allow the connect statements described above to be
> legal.
> By doing this the LRM defined net domain precedence is overridden
> with an user defined precedence via the discipline resolution connect
> statement(s). This then allows the discipline resolution and ACMI
> mechanism to be extended into multidisciplinary continuous Verilog-AMS
> description.
>
> The following examples and scenarios illustrate the above explanation
> further.
>
> Example 1:
>
> module m1;
> m2 i1(n);
> m3 i2(n);
> endmodule
>
> module m2(a);
> input a;
> electrical a;
> ...
> endmodule
>
> module m3(d);
> output d;
> logic d;
> ...
> endmodule
>
>
> Example 2:
>
> module k1;
> k2 i1(n);
> k3 i2(n);
> endmodule
>
> module k2(e);
> input e;
> electrical e;
> ...
> endmodule
>
> module k3(m);
> output m;
> mechanical m;
> ...
> endmodule
>
> Since the nets m1.n and k1.n is implicit then its discipline must be
> resolved before determining the need for ACMI (assuming the basic
> method is used). The following scenarios illustrate how these
> undeclared
> nets will resolved:
>
> Scenario 1:
> Using example 1 and the following discipline
> resolveto statement
> the net m1.n is resolved to be electrical.
>
> connect electrical logic resolveto electrical;
>
> Scenario 2:
> Using example 1 and the following discipline
> resolveto statement
> the net m1.n is resolved to be logic.
>
> connect electrical logic resolveto logic.
>
> Scenario 3:
> Using example 2 and the following discipline
> resolveto statement
> the net m1.n is resolved to be electrical.
>
> connect mechanical electrical resolveto electrical;
>
> Scenario 4:
> Using example 2 and the following discipline
> resolveto statement
> the net m1.n is resolved to be mechanical.
>
> connect mechanical electrical resolveto mechanical;
>
>
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Graham Helwig email: A11558@email.mot.com
> ghelwig@asc.corp.mot.com
> Telephone:+61-8-81683532 Fax:+61-8-81683501
> Motorola Australia Software Centre,
> 2 Second Avenue, Mawson Lakes, Adelaide, SA, 5095, Australia
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
This archive was generated by hypermail 2b28 : Mon Jan 28 2002 - 15:05:26 PST