Re: resolveto statement's discipline list constraint


Subject: Re: resolveto statement's discipline list constraint
From: Kevin Cameron (dkc@galaxy.nsc.com)
Date: Wed Jan 16 2002 - 18:27:25 PST


Graham Helwig wrote:

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

I'm not sure that that is necessary. The 'connect/resolveto' mechanism is
really just for attribute resolution, and the current ACMI mechanism really just
converts between views on what is considered (electrically) the same node,
i.e. continuous (actually piecewise-linear) and discrete (logic) values. It is not
physically possible to connect nets with different base disciplines such that
they become one node, so the connect statements above are unnecessary
because you don't need to do attribute resolution.

You could use the ACMI mechanism between distinct disciplines if you
particulary want to do so, but the semantics are definitely going to have to be
port-bound: top and bottom nets of the port are distinct and would have their
drivers and receivers resolved independently.

This was proposed before as a mechanism for auto-inserting transducers, e.g.
something like the following code be used in the connect rules to instantiate
a opto-coupler between a fibre-optic input and an IC:

  connect fibre_optic to cmos3V_pad using module opto_coupler_3V;

Any help?

Regards,
Kev.



This archive was generated by hypermail 2b28 : Wed Jan 16 2002 - 18:31:15 PST