Re: Minutes from AMS call of July 26

Geoffrey.Coram wrote:

>Kevin Cameron wrote:
>
>
>>What's the rationale for this stuff? - it looks unnecessary to me.
>>
>>See SV "program blocks".
>>
>>
>
>The text for program blocks indicates it is intended for testbenches.
>The constants module was a thought about how to recognize certain
>things as constants, even though they are accessed through OOMRs.
>It looks like we're not going to do this after all, though.
>
>
SV interfaces would probably do the job as well since you can pass a
reference to an interface down
through the hierarchy rather than use OOMRs.

>>I still think you would be better reconsidering the paramset syntax, and
>>just doing it as a module definition with inheritance: if you keep
>>adding more stuff to it, it will end up looking like a module anyway.
>>
>>
>
>There's still no behavior in a paramset. Also, paramsets are
>intended to go in libraries and designers may or may not instantiate
>a particular device (maybe no NMOS_LVT in a design); recall that
>the LRM specifies that a module that is not instantiated is a
>top-level module, so we'd end up with a bunch of top-level but
>floating devices.
>
All the simulators I use allow you to specify that the contents of a
file are not to be used as top-level as well as the "library" auto-load
mode (-v,-y), so that's not really an argument. Also, I see no reason
why I would never want to use a paramset as a top level module - there
is no restriction that paramset only applies to transistors, it could
apply to any level of model.

The fact that you currently have no behavior in paramset does not mean
that it will not be added later. IMO that's what happened with SV
interfaces: they were a simple object originally and more and more stuff
has been added until they look pretty much like modules, but since the
person who thought of it originally sees them as different objects they
didn't get rationalized.

SV has become a monster of a language because there as been hardly any
work put into rationalizing the constructs, I don't think we should add
to the problem if we can avoid it.

Kev.

>>SV supports pass-by-reference which allows multiple returns.
>>
>>
>
>Yes, and we're adding that to functions; the point was that
>AD=hdif*weff is simple, but if you have a complicated function
>that computes a lot of intermediate values to arrive at
>AD,AS,PD,PS, then it's hard to write that efficiently as
>a single constant_expression for a parameter initialization.
>
>-Geoffrey
>
>

-- 
Altera Corp, 101 Innovation Drv, San Jose, CA 95134. T# (408) 544 7126