Re: Connect-ResolveTo stmts
Subject: Re: Connect-ResolveTo stmts
From: Jonathan Sanders (jons@cadence.com)
Date: Sun Mar 10 2002 - 23:03:42 PST
Sri,
A few issues on your suggestions below.
Jon
At 11:29 PM 3/7/2002, Srikanth Chandrasekaran wrote:
Hi all,
Problem:
With the current version of the LRM there is lot of ambiguity with
regards to
which of the rules apply when trying to do discipline resolution
connect x y b resolveTo b
connect x y resolveTo x
connect x y a resolveTo a
In the above set of rules it is not clear, when two nets having
disciplines x
& y will be resolved to b, z, or a.
Also it is not clear in the LRM whether the resolved discipline should be
part
of the list specified.
JONS: Seems like it would depend on if the resolved discipline was
one of the disciplines on being resolved.
The following is stated in 8.4.1:
If disciplines at the lower
connections of ports (where the undeclared net is an upper
connection) are among the disciplines in discipline_list, the
result_discipline is the discipline
which is assigned to the undeclared net.
As you state it is not clear whether the result_discipline needs
to be in the discipline list but I believe it should only if it is one of
the disciplines being resolved.
connect x y resolveto a; // this should be ok since "a"
was not one of the signals being resolved.
Solution: Best Match Fits
When there is an exact match for the set of disciplines specified,
the
resolved discipline would be as per the rule specified in the exact
match. In
the above case x,y would resolve to discipline x. It shall be an error
to
specify more than one rule with the exact fit. The resolved discipline
need
not be one of the disciplines specified in the discipline list.
When there is no exact fit, then the resolved discipline would be based
on the
subset of the rules specified. If there is more than one subset matching
a set
of disciplines, the simulator shall give an error message on ambigous
connect-resolveto
specification saying that there is more than one rule that matches
for
resolving the disciplines.
JONS: First I would say that we should not error but only give a
warning if we decide to do this. We should only error if we cannot
resolve the answer with some basic rules.
Your proposal provides an interesting method for dealing with multiple
connect rules. What we do is to work on the first rule that matches
principal. There are a number of reasons for this since in one of
our customers use model you could have hundreds of rules to try to work
your way through. For the resolveto connect statements I don't
expect users that have hundreds of disciplines to attempt to build all of
the combination but select one or two conflict resolution with the
hundred plus disciplines being used in the discipline list (connect
a b c d e f g h i j k l m n o p q r s t .... resolveto z). But I
don't think we should have a separate rule for the resolveto than we do
for the rest of the connectrules which I don't think this will be
efficient for. Since connect rules don't necessary by
themselves provide sufficient information you actually have to parse each
connect module which in a library based system could result in extra
overhead for this type of "look at all rules first"
method.
Anyway we can talk about the need for this flexibility in connectrules
and the pro/cons of your proposal vs the first rule method we use in our
next meeting.
Example 1:
----------
connect x y a resolveTo a
connect x y resolveTo x
x,y would resolve to x.
x,y,a would resolve to a
y,a would resolve to a
Example 2:
----------
connect x y a resolveto a
connect x y resolveTo x
connect x y b resolveto z
x,y would resolve to x
x,y,b would resolve to z
y,a would resolve to a
Example 3:
----------
connect x y a resolveto a
connect x y b resolveto b
x,y would resolve to
"ERROR: Ambigous"
y,a would resolve to a
y,b would resolve to b
Example 4:
----------
connect x y resolve to x
connect x y resolve to
y // ERROR:
Conflict
cheers,
Sri
--
Srikanth Chandrasekaran
Global Software Group, EDA SBU
Motorola Australia.
Phone: +61-8-8168 3592 Fax: x3501
***********************************************************
Jonathan L.
Sanders
Product Engineering Director
Custom IC Solutions
Cadence Design Systems, Inc.
555 River Oaks Pkwy
San Jose, CA. 95134
INTERNET:jons@cadence.com Tel: (408)
428-5654 Fax : (408) 944-7265
***********************************************************
This archive was generated by hypermail 2b28
: Mon Mar 11 2002 - 00:58:56 PST