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.
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.
> 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.
-Geoffrey
Received on Tue Apr 6 05:36:46 2004
This archive was generated by hypermail 2.1.8 : Tue Apr 06 2004 - 05:36:52 PDT