Re: discipline vs signal name conflicts

Even if we fix the spec it will already cause some
problems.. 
think about design reuse & Ip reuse.. 

In fact, at this point it might be better to define a
new one.. 
(call it discipline.vams?) and deprecate the use of
disciplines.vams, rather than makeing such changes.

When I buy IP from someone, I don't want a missing
disciplines file to cause the integration team an
extra week!!

Nor do I want them to spend a week finding and
resolving incompatibilities between what one did and
what the other one did. 

The sad thing is.. I first knew of this problem about
7 years ago! but in those days they were two separate
languages.

BTW this would only affect compact models (where use
of Q(sig)
is probably more common) if there was NOT a
precompilation step and linking into the the analog
simulation engine. 

Of course the moment one goes to an entirely
Verilog-ams design description (include the parameter
definitions and subcircuits use in the model files)
then everything needs to use the same definitions.. (
you can't (per the spec) have different blocks using
different definitions of electrical - nor I think can
two different blocks have different definitions of the
same nature. 

the first time I ran into this, I just redifined the
current nature not to refer to the charge nature for
its idt nature.
that worked fine, for that design, but every block
needed to use that new definition. 

So the goal as I see it - define an update to the
disiplines.vams definition, (with a new name), that
users can switch to when they need to or are ready,
and has miniminal impact on recoding designs (ie its
ok to change the filename, but not the name of the
electrical discipline as that would require a lot of
changes in most models writen so far. 

Jonathan

--- "Geoffrey.Coram" <Geoffrey.Coram@analog.com>
wrote:

> Jonathan -
> 
> > in here the default access function for the
> "charge"
> > nature is defined to be "Q"..  which creates a
> problem
> 
> I've had a similar problem; in my case, the C code I
> was trying to
> convert to Verilog-A had a variable called "Acc"
> which is the
> access function for acceleration.
> 
> It seemed to me that the compiler should be able to
> distinguish
> between the two identifiers, since the access
> function always
> requires parentheses: Acc(porta,portb).  But I think
> SV has
> some new constructs, forget what they're called
> (methods?),
> where you can write Acc.function() to get some
> information
> about Acc, and one could imagine both parameters and
> access
> functions having such constructs.
> 
> 
> > IE my favorite simulator doesn't make it easy (not
> > impossible but not easy!!) to customize the
> default
> > displpines file so that this problem is
> eliminated..
> 
> Isn't it trivial to fix disciplines.h?  I mean, the
> first line
> of all my V-A files is `include "disciplines.h" and
> I could
> certainly replace that with `include
> "mydisciplines.h"
> 
> 
> -Geoffrey
>