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

Shalom.Bresticker@freescale.com wrote:

>....
>
>Now, regarding paramsets, as I wrote previously, someone who really wants to
>understand the idea should read the proposal document on the AMS website.
>
>I am not sure about some of the rest of this stuff, but I do like the idea of
>being able to group a set of parameter values into a set and then just
>having to refer to the set name in order to get the entire list of parameter
>values defined in the test. A little like one of the reasons behind interfaces,
>or structs, where you can refer to a whole set of signals with a single
>high-level name.
>
>I also like the idea of implicit parameter connections using #(.*).
>
>Some of this, on the other hand, sounds less nice to me.
>For example, it sounds like I would instantiate a certain module with a certain
>set of parameters by instantiating the paramset name. I don't like that
>because it adds obscurity to the code. I write that I am instantiating X when
>really I am instantiating Y, just indirectly. And even if I know that X is
>a paramset, I have to go look up its definition in order to find what module
>it really does instantiate.
>
>Shalom
>
It's the same kind of problem you get with C++: you can't easily tell
which version of an overloaded routine call or virtual function you will
actually be using until run-time. It's just part of the cost of being
able to overload things.

All paramset is trying to do is move "binning" used in Spice
simulators into the language proper so that the design descriptions
are fully portable and the simulator vendors don't come between
foundaries and the users.

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?

Kev.

>On Tue, 22 Jun 2004, Steven Sharp wrote:
>
>
>
>>>I would think if Verilog-AMS can maintain
>>>that syntactical equivalence, then it would not be an issue for AMS to add
>>>to the 1364 a requirement that an AMS implementation shall (required)
>>>in-line macromodules, while other types of implementations may (optional)
>>>in-line macromodules, as it is now). I also do not see it as a problem for
>>>AMS to specify restrictions on macromodules, if needed, in order to in-line
>>>them.
>>>
>>>
>>It would be problematic for an AMS implementation built on top of a 1364
>>implementation. It would also be problematic for users who want to be
>>able to use the digital subset of their design in both AMS and digital
>>Verilog.
>>
>>Steven Sharp
>>sharp@cadence.com
>>
>>
>>
>
>
>
Received on Wed Jun 23 10:36:18 2004