Subject: Re: Alternative approach to discipline defintions ...
From: Kevin Cameron x3251 (dkc@galaxy.nsc.com)
Date: Thu Jan 17 2002 - 16:48:29 PST
> From: "Graham Helwig" <ghelwig@asc.corp.mot.com>
>
> Hello,
>
> Based on the following paragraph from the "Re: resolveto statement's
> discipline list constraint" email (dated "16 Jan 2002") highlights a
> double standard within the LRM wrt. the compatibility of base
> disciplines of differing domains. Below is a possible approach that may
> resolve this situation
>
> > 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.
>
>
> >From a users point of view the following base discipline compatiablity
> statements are true:
>
> "logic" and "cmos" discrete disciplines are compatible
> "electrical" and "logic" disciplines are compatible
> "mechanical" and "logic" disciplines are NOT compatible
> "mechanical" and "electrical" disciplines are NOT compatible
>
> >From a language point of view, any base discipline should be
> incompatible with each other, therefore the above examples all should be
> incompatible with each other. These examples high-lights a double
> standard wrt. disciplines and their compatibility rules. After talking
> with Sri, the users and language points of view can be made consistent
> with each other through the use of derived disciplines (similar rules to
> derived natures). For example, consider the following derived discipline
> definitions:
>
> discipline voltage;
> domain continuous;
> potential Voltage;
> enddiscipline
>
> discipline electrical : voltage;
> // NOTE: The potential binding is inherited.
> flow Current;
> enddiscipline
>
> discipline logic : electrical;
> // NOTE: The flow and potential nature binding
> // are inherited but not used.
> domain discrete;
> enddiscipline
>
> discipline cmos : logic; // Alternatively "cmos : electrical"
> enddiscipline
>
> Using this these derived discipline definitions and applying a domain
> independent rule that all base disciplines are incompatible with each
> other, the above compatibility examples become true again. The
> difference now is that the logic of the compatible are contained in the
> discipline definitions instead being embedded within the LRM
> documentation.
>
> Should discrete discipline definitions be restricted to derive from the
> "electrical" discipline definition only?
The idea that "discrete" is a discipline is bogus, "discrete" is a view
of an object as is "continuous", you can add other views e.g. "spectral"
for RF. The discipline is only defined by its flow and/or potential natures,
the domain attribute forces which view(s) you are allowed to use in an HDL
context.
Verilog logic types are a "discrete" view of the default discipline
(electrical) unless otherwise defined.
> Note: A side effect of this change is the DR and ACMI mechanism will be
> based on the "domain" specification of the two compatible nets being
> resolved and not based on their incompatibility.
>
> As a result, we feel that derived disciplines can be efficiently used in
> trying to do discipline resolution and ACMI in conjunction with the domain
> attribute for a discipline. So this approach could be investigated
> further to clarify the LRM and associated algorithms, with the
> possibility of reintroducing this in the BNF.
>
> Regards
> Graham
Personally I would prefer to have base disciplines declared with both
nature and potential (and no domain) and derive from them with no override
on the nature, but since we need backward compatibility to the current
"discrete discipline" syntax I think we should just state that all derived
disciplines must have the same base natures.
All "discrete" disciplines - which have no natures - can be viewed as a being
derived (implicitly) from a base "void type" discipline and are therefore
compatible.
NB: "discrete" really means "verilog-1364 view", if you want to use different
logic types then you need ACMI between them too, e.g. "wreal" also carries
discrete values and if it needs to be associated with a physical wire it
would need to be associated with a discipline too e.g.:
discipline cmos3v_f : cmos3v;
domain discrete float; // discrete signal of type float
enddiscipline
module foo...
wreal vco_in;
cmos3v_f vco_in; // restrict for port-bound semantics
....
Note: ACMI between discrete views can be handled by functions as well
as modules since state history is not usually required.
Hope this doesn't confuse things.
Regards,
Kev.
This archive was generated by hypermail 2b28 : Thu Jan 17 2002 - 16:50:40 PST