Re: [sv-ec] Re: Quick poll for AMS extension to overload modules

>What I'd like folks to consider is: since SystemVerilog has a more
>extensive type scheme than Verilog and Verilog-AMS also has an analog
>typing scheme that can be used with module ports, it may be desirable to
>also allow overloading of modules on port types so that an "ideal"
>module version can be picked for whatever simulation is being performed.
>E.g. if you have a module which has two descriptions one using "bit"
>type ports and the other using "logic" type ports, and the simulator
>knows that all the actuals are of type "bit" then it can use the "bit"
>version (which is probably going to be faster since it doesn't handle Xs
>or Zs). Similarly if one of the ports is actually connected to something
>analog I may want to switch to a module with analog ports rather than
>digital ports (which might be more efficient than inserting A2Ds or
>D2As). If you think that might be useful, how would you mix that
>functionality with the paramset functionality?

Not everyone agrees that overloading is a good idea even in software
languages. I think that the arguments become even weaker in Verilog,
where modules tend to be less abstract.

At any rate SystemVerilog already has features that can do some of this.
It has "type parameters", which allow passing a type in as a parameter,
allowing something like templates. So for example, you can have a module
that uses a type parameter for its port types, and set it to "logic" or
"bit" for a given instance. If parts of the module have to change for
different types, there is a mechanism for testing the type in a generate.

I believe you can also use a "generic interface" for your ports, and
then connect different kinds of interface instances to the ports of
different module instances. These can encapsulate different types of
ports, with access functions for them.

So I think SystemVerilog already has more than enough configurability
of this sort. I wouldn't worry about module overloading getting added
any time soon. But maybe someone more active in the SystemVerilog area
has a different opinion.

Steven Sharp
sharp@cadence.com
Received on Wed Jun 23 15:56:40 2004