RE: (discipline vs signal) name conflicts

I think, but I'm not sure, that SystemVerilog has a solution to this by
allowing you to place the declarations before and outside the module
definitions. Then if you declare the same name inside the module, the
local declaration overrides the global declaration. Simply, an
additional namespace called $unit was added.

Shalom

> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-
> ams@eda.org] On Behalf Of Kevin Cameron
> Sent: Monday, January 30, 2006 8:11 PM
> To: j.david@ieee.org
> Cc: verilog-ams
> Subject: 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.