Define the number of instances as a parameter in Cadence Schematic

[huynguyenle]

Dear all,

I'm creating a schematic to simulate and measure Fanout-Of-h delay using Cadence Virtuoso.

What I want to do is to define the number of instances of a particular inverter as a parameter (hence I can use parametric analysis to evaluate the change of delay with respect to the change of fanout).

As far as I know, there are two ways to change the number of instances of a component in Cadence schematic:
+ Using the m-factor
+ Using the I1<0:3> to instantiate 4 similar I1 components.

However, in both ways I tried but failed to set a parameter for the number of instances.
For example, when I defined I1<0:h> then Schematic told me that an error occurred in my circuit.

If someone had a same problem and knew how to fix it, I would be very thankful to have your instructions.

Thanks, everyone!

 

[a.aghighi90]

hi, by the way I think it's convenient to model each fanout by its input Cap. as a load for your inverter and then you could use parametric analysis for the load. (Its possible if the input capacitance be constant for all fanout. )

 

[Dominik Przyborowski]

Try to do this in that way

 

[huynguyenle]

Thanks DP,

I will try your suggestion. However when I read the guideline, I haven't seen where it creates the parameter for instantiating the parameterized cell. If I missed that point somewhere please let me now. Will check it in details tmr. Thanks, DP.

- - - Updated - - -

Thanks, AA.

This is still a way I think. I'm wondering if it can yield a wrong result since doing this way means we might omit the resistance of the load which in turn changes the real propagation delay.

 

[chris.mourad]

Hi

When puting a parameter for the m-factor in cadence virtuoso, this parameter is passed to the ADE window (Analog Artist).

To retrieve it, go to the ADE window, Variables Tab, Copy From Cellview

 

[dick_freebird]

I had found that the instance "m" param does not deal with
variables appropriately (parsing as integer rather than
processing a string input, down to the int(num()) or whatever).
Similarly netlisters don't know how to deal with variable
topology, only variable geometry. I think this is the PDK
developer's call, if they don't expect fingering to be a
front end design variable then they don't build the right
scheme into the symbol properties / callbacks and the
netlisting.

Your workaround is to assign roughly-right m and/or I((x:0>)
and vary w for purposes of optimization, re-target m, repeat.