Subject: Re: Regarding restrictions on "connect-resolveto" statements
From: Kevin Cameron (dkc@galaxy.nsc.com)
Date: Mon Jan 07 2002 - 09:08:11 PST
Srikanth Chandrasekaran wrote:
> Hi all,
>
> According to section 8.7.2 "Discipline Resolution Connect Statement" during a
> discipline resolution
>
> connect_resolution ::= connect discipline_list resolveto discipline_identifier
>
> it specifies that the discipline_list has to be a list of compatible
> disciplines...
>
> 1. Does this mean we cannot resolve an electrical and a digital using a resolveto
> statement (without a connect module insertion)?
> or how about two incompatible continous disciplines?
>
> 2. If the list of disciplines is subset of the disciplines specified then
> is it implied that the resolveTo statement is effective?
>
> For example connect cmos1 cmos2 cmos3 resolveTo cmos3;
>
> If we have cmos1 and cmos2 would this also resolve to cmos3 if there is no
> specific rule resolving cmos1 and cmos2?
>
> Have i missed something very obvious.
1.
Originally disciplines were not analog or digital, they were a "technology" type
(e.g. electrical, hydraulic), and "digital" and "analog" were views of the discipline.
In which case you can say the following without worrying about analog/digital
usage:
connect Cmos3v3,Cmos1v8 resolveto Cmos1v8; // use 1.8V attributes
connect Cmos3v3,CoolingPipe5mm resolveto electrical;
// Fails if CoolingPipe5mm is hydraulic. See LRM Sec. 3.8
Making disciplines analog and digital was a by-product of Cadence choosing
to go with port-bound A/D conversion/insertion, as ports are intrinsically
neutral and the analog/digital properties actually belong to the driving/receiving
processes. I.e. with port-bound semantics you have to state if the port lo-conn is
analog or digital. It should have been done seperately form the discipline itself, but
was implemented by adding the "domain" attribute to the discipline - which breaks
using it as a "technology" type.
NB: if you use process-bound semantics the "domain" field is unnecessary
because auto A/D insertion is between views, not between disciplines and
the information is there implicititly.
There was (at one time) a discipline inheritance mechanism that let you have
it both ways by letting you declare (say) cmosX without a domain, and then
declaring the digital sub-class:
discipline cmosX_d : cmosX
domain discrete;
endiscipline
discipline cmosX_a : cmosX // analog only for port-binding
domain continuous;
endiscipline
- but that syntax seems to have vanished.
Note: if port-bound conversion is considered to disrupt the net (as
described in previous e-mails) it can be used to bridge incompatible
disciplines. E.g. in the cmos3v3/CoolingPipe5mm case you could insert
a valve or a flow-sensor.
2.
The original intent was that you look for a specific resolve-to rule and then
relax the constraints until you find one that works. Since that is a bit sloppy,
there is a standing proposal to do "attribute resolution" instead/as-well.
http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0014/index.html
An exact resolve-to would take precedence over attribute resolution, and
an inexact resolve-to would be used if attribute resolution fails (probably
with a warning).
A trickier question is: if you have multiple disciplines on the net e.g. cmos1,
cmos2 & cmos3 and you have the rules:
connect cmos1, cmos2 resolveto cmosA;
connect cmos2, cmos3 resolveto cmosB;
connect cmosA,cmosB resolveto cmosX;
Should the simulator use cmosX for a connection of cmos1 & cmos3?
- I think the answer is "yes" but what is the algorithm?
---Hope that helps.
Kev.
This archive was generated by hypermail 2b28 : Mon Jan 07 2002 - 09:09:47 PST