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

Steven Sharp wrote:

>>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.
>
>
We will be adding paramset or something equivalent which does module
overloading to Verilog-AMS, this is just your opportunity to suggest how
you would like it done if you think paramset isn't the right solution.
Whatever we do will be merged with SystemVerilog
(probably next year).

Kev.

>Steven Sharp
>sharp@cadence.com
>
>
>
Received on Wed Jun 23 16:40:59 2004