Re: V-AMS DevModeling meeting April 6, new proposal doc

Geoffrey.Coram wrote:

>Kevin Cameron wrote:
>
>
>>I was suggesting generate statements for binning because only the internal
>>behavior of the model changes, the ports don't . You can do sub-(macro)module
>>instantiation to call a single definition with different parameter overrides if you
>>want to do it that way.
>>
>>
>
>The more I think about using generate, the more I think doing so
>turns the system inside-out. Effectively, you're asking that
>every model card that's ever generated for a BSIM4 model would
>have to be coded into the module along with the equations.
>Either that, or you have a copy of the BSIM4 equations for
>each type of model (nmos and pmos; native, low-vt, medium-vt, etc.)
>and within each module, you only have the binning rules (lmin/lmax)
>for that type. That's inefficient, since the equations would
>likely be the same (if they aren't in some model file I get from
>a foundry, is that a bug, or did the foundry change the equations
>to better fit for that device?).
>
>
>Further, though the ports may not change, what is a parameter does
>(cf the one example where ad,as,pd,ps are parameters for a post-
>extraction model, but not for a pre-layout model). The parameter
>declarations cannot happen inside a generate statement.
>
>
You just need parameter overrides for a macro call, you don't need to
declare the actual
parameters.

>Sub-(macro)module instantiation is just a Verilog way of doing
>subcircuits, and people don't do that in Spice now if they can
>avoid it, for various reasons including efficiency.
>
>
Macro modules in Verilog don't introduce extra hierarchy. If you do a
macro module
instantiation in a generate it is transparent as far as namespace goes.
So you can
nest modules with generates such that a deep hierarchy of macromudules
is called
but it is transparent to the user - which means you don't have to put
all the cases in
one module as you suggest above, i.e. if you don't have all the cases
covered by the
foundary's model you can just use a generate/macromodule wrapper of your own
to add some extra ones on top.

>>You could also use Verilog 200X configurations (LRM 13.3.1.6 The use
>>clause).
>>
>>
>
>The "use clause" does seem to address the process corner part of
>the paramset proposal, insofar as I think it would allow you to do
>something like Spice's "lib fast" or "lib nominal", where the
>designer specifies how the simulator should find models.
>For binning, the designer does not have to tell the simulator
>which instances fit in which bins; the simulator does it
>automatically.
>
>
>>Similarly, "aliasparam" is probably unnecessary if you can say "ref param" (which
>>isn't allowed at the moment), or re-use the alias statement (currently only for signals).
>>
>>
>
>We had proposed using "alias" (perhaps not with the same syntax as
>for signals), but it was felt that this was a poor keyword to choose.
>Also, the semantics of alias (for signals) is backwards from what we want
>for parameters: in the example on page 43 of SystemVerilog_3.1_final.pdf,
>the port "rst" is allowed to be referenced by the macromodule under
>several different names (the instances know the port by the names
>Reset, reset, and Rst). Our aliasing requires the module equations
>to be written only for the original parameter name.
>
>
It's already a keyword in SV, so that issue is immaterial.

Why is it a requirement that the module equations be written "only for
the original parameter name".
Alias can work both ways i.e. you can have one name in your module's
code and multiple names
for interface or vice-versa, it's a superset of the functionality you
want, all that needs to be done
is the extension of the types it covers to include parameters.

If you just drop "param" form "aliasparam" in the proposal then the
syntax is the same and it's
just left to the compiler to do the type checking to work out what kind
of alias it is (not too hard).
You can add restrictive rules if you want (with a view to relaxing them
later).

As a user it's very annoying to find a language has different mechanisms
for doing the same thing in
different contexts. It's more stuff to remember that just makes the
language harder to use.

Kev.

>-Geoffrey
>
>

-- 
Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862