Re: (discipline vs signal) name conflicts

This one keeps coming up in different contexts. Most of the problem 
(IMO) is due to the  way Verilog is compiled as a single  source stream 
rather than modular like C - i.e.  in C it's fairly  easy to have Q mean 
one thing in one place and something else in another. C++ fixes most of 
these problems by using namespaces and classes and overloading on 
functions (for the Acc() problem).

My previous proposal for fixing this kind of problem is to redo types 
like Q as typedefs (see SV) of a more verbose types (e.g. _vams_charge) 
and then allow the parser to hide or forget the short (clashing) 
definition as necessary - Google "untypedef" to find it in the reflector 
archives. With AMS I would suggest doing that and also splitting the 
discipline.vams file into some base definitions in long form and 
including that in a new disciplines.vams that has the short form (old) 
definitions as typedefs, that methodology would be completely backward 
compatible. You can also  add `ifdef not_defined_<whatever>/`endif round 
the typedefs in the discipline.vams so that you can nest it and prevent 
clashing definitions.

Since Verilog does not support passing functions around like C, Q and 
Q() are easily distinguisable as different kinds of objects that should 
be able to co-exist. If we want to pass function references around 
(later) we can use different syntax (to C) so that  there is still no 
ambiguity.

For the Acc(...) function clash I think namespaces and function 
overloading are required. With namespaces you could to add an "unuse" 
statement to hide unwanted definitions e.g. if you consider all AMS 
stuff as belonging to namespace "verilog_ams" which is used by default 
(for backward compatibility) then doing something like "unuse 
verilog_ams;" would hide all the AMS definitions. If you need to see 
both definitions then function overloading is your only option if you 
want to maintain backward compatibility, but in general that's a big can 
of worms I can't see anyone signing up for opening anytime soon, maybe a 
very limited version could be introduced for AMS that just applies to 
access functions.

Kev.


Jonathan David wrote:

>Gent's, I actually have a question / problem with the
>standard as its defined today.. 
>
>
>In appendix D1 we have published the default
>disciplines.vams file.. 
>in here the default access function for the "charge"
>nature is defined to be "Q"..  which creates a problem
>every time I try to write a verilog-A model (ie with
>electrical disciplines) of any of the storage elements
>in a standard cell library.. 
>
>Granted that this is the most natural symbol for us to
>us for Charge, and I certainly didn't think much about
>those many years ago when I first started to use
>VerilogA, but I do think that the digitial guys
>adopted their convention first.. and that we should
>either CHANGE the "default" access function to "qq" or
>"Qq" or even "QQ" would be OK..  or allow  signal
>names that confict with access functions used with the
>discipline associated with that signal.. 
>
>Otherwise we can approach the "ALF" folks to see if we
>can talk them in to changing the convention that "Q"
>is the non-inverted output of a latch or flip-flop
>gate..
>
>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..
>nor to use a local definition of the current nature in
>this block that doesn't use Q as the access function
>for charge.. 
>
>-- Ah so here's an idea, why not allow a LOCAL
>redefinition of the discipline so that an alternate
>access function can be use in the verilog-A model of
>the flip flop.. 
>
>(last time I tried this "my favorite simulator"
>complained when I tried to use this and connect it to
>a discipline with the same name, and altered
>definition.. )
>
>If I can reconnect to my session today I may give it
>another try.. 
>Jonathan David
>MSDV engineer
>Scintera
>
>
> 
>
>
>  
>