Variables on properties in schematic is nice for simulations, but when
moving over to layout those variables make a little headache. I am now
looking for a way to script a replacement of the variables going from
a "schematic" schematic view to a "schematicWork" schematic view which
will later be used for Virtuoso-XL. I want to keep the original
schematic with the variables so that I can continue to make changes.
(I know, I know, typical designer mentality to change things in
schematic after layouter has started to work ... )
Has anybody got a quick script for such a process? I would probably
need to trigger some callbacks also, but that is a different topic.
--
Svenn
Hi Svenn,
I did write code for doing precisely this. Couldn't find an existing solution, although it seems
this is sort of a gap in the flow : parametric schematic -> optimization -> layout -> verification.
And it really is boring stepping through all the instances in one schematic, replacing the
parameters ! :)
The code copies all views to a new cell, including symbol and any other view. Then, it opens the
schematic, replaces properties on the cellview according to user-given values, and iterates through
all parameters of all instances, using AEL calls to evaluate the final parameter values. Then, it
re-generates the cell CDF, since there are no more parameters.
It also use Andrew's solution CCSabInvokeInstCdfCallbacks to invoke CDF callbacks for all instances
in the new schematic.
It works well most of the time, but I'm pretty sure it may break up with certain evil CDF callbacks.
Also included are two layers of user interface (I'm a UI freak :)), the first prompting the user for
the values of parameters, the second prompting also to select the source and destination cells.
Since the file is a bit large, I have put it online at http://dewww.epfl.ch/~badel/pub/SBMakeCell.il
Give it a try, and tell me what you think.
Stéphane
I always tend to use pPar("varName") on schematics for values I want to
parameterize, and then only use design variables in testbenches.
That way the design itself has only got inherited parameters, which have default
values in the CDF for the cell - and can be passed up through the hierarchy.
These will be resolved by VirtuosoXL - and VirtuosoXL can also call the
callbacks (there's a cdsenv for that), if you're unlucky enough to have a PDK
which derives values using CDF callbacks.
I liked the reference to "evil CDF callbacks" in Stephane's post above!
Regards,
Andrew.
--
Andrew Beckett
Senior Solution Architect
Cadence Design Systems, UK.