Re: (discipline vs signal) name conflicts

but I'm guessing that we probably wouldn't consider
this until we were ready for the SVams merge.. but if
thats no too far off, I might be willing to wait and
fix it then.. if that fix is enough better..

Jonathan

--- Kevin Cameron <kevin@sonicsinc.com> wrote:

> 
> 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
> >
> >
> > 
> >
> >
> >  
> >
> 
>