"TECH is nil" error when copying library

Dear all,

I am experiencing the following errors in the CIW when making a copy
of an entire library:

*WARNING* no technology specified
TECH is nil

These messages appear whenever I open any cell of the copy library
(schematic view). This is how I made the copy:

1. I had an original library "lib_A" which was developed using the
AustriaMicrosystems design kit v3.70 and their C35B4 0.35um CMOS
technology. The integrity and correctness of the cells in this library
have been fully validated through exhaustive simulations.

2. From a new directory, I launched icfb with the environment set for
the IBM BiCMOS design kit for the 7WL 180nm technology (as provided by
MOSIS), and modified the library path in order to be able to 'see'
"lib_A" in my library manager. I also added AustriaMicrosystems'
"PRIMLIB" (a library of primitives) to the library path for letting
cadence 'find' the pmos and nmos instances in the schematics of the
cells in "lib_A".

3. Using the Library Manager copy utility, I made a copy of "lib_A",
which I called "lib_B". I checked the "Update Instances: Of Entire
Library" option in the dialog window when making the copy.

4. At the end of the copying step, when I was prompted to attach the
copied cell to a technology library, I selected the "bicmos7wl"
process, which was readily available in the cyclic field.

5. Now I have my copy library "lib_B" which is supposed to be attached
to the new technology. Nevertheless, any time I open one of its cells
(schematic views) I get the aforementioned errors.

I don't see where can the error(s) be. When I right-click to see the
properties of the copy library "lib_B", the field "techLibName" shows
"bicmos7wl" as expected. Also, I am pretty sure the IBM design kit is
correctly installed and is being properly loaded, because when I make
cells from scratch they simulate flawlessly.

Just in case someone wonders why I am interested in performing this
kind of copy, it is because I need to migrate the library to the
smaller IBM technology, basically by replacing all the mos instances
in all the schematics of the copied cells with their counterparts in
the new technology. I am using skill code to achieve this.

....I haven't been able to find a single entry when googling for these
errors; I don't even know if the procedure explained above is the
right way of copying an entire library in order to migrate it to a new
technology, in the first place.

Well, any help is GREATLY appreciated! Thanks in advance for any
ideas...

Regards,

Jorge.

 

Ok. The message is not too talkative. First thing I notice is, you
added PRIMLIB in your library path to see the primitives (which is
probably not necessary) but you did not include the technology library
(TECH_C35B4 or so). I suspect this error might be from some SKILL code
loaded in libInit.il of PRIMLIB library (just a guess).

In any case, if I were to do this I wouldn't even include the PRIMLIB
in my library path, but just the source library. Then doing the copy,
you will get a library with missing masters (but instances will be
there, unbound) that you can then rebind with SKILL to your new devices.

If removing PRIMLIB does not help, maybe you can try to re-attach the
IBM tech using Tools->Technology File Manager->Attach.

It might (it will...) be a nightmare to migrate the schematics, since
the devices from the new library will probably not have the same parameter
names, pin positions (when you change to the new device, some pins will not
be connected anymore), and CDF callbacks will hurt too.

I have done it for a dozen schematics that I was too lazy to redraw, but
in the end it would probably have been faster to redraw them

Are you planning to migrate layout too ?


Stéphane

 

Thanks so much for your help Stéphane. I tried to make the copy by
removing PRIMLIB as you suggested, but the problem persists. Then I
tried to use the attach feature of the Technology File Manager, but
also with no luck

I think that you are right, and as you foretell, all this is related
to the properties and callbacks of the instances getting messed when
performing the replacement. I guess the approach I am following to do
the replacement is not correct, but then the question is:

How can I completely replace (with properties, callbacks--everything)
the original instances in the schematics and entirely replace them
with completely new instantes of the transistors of the new technology
library (I mean, completely extirpate them)? (You can see the detailed
SKILL code I am using for making the replacement in the thread "On how
to migrate a design to a new technology, at the schematic level" in
this forum).

I really appreciate your help, and I would be really grateful if you
could please advice me on the best way to accomplish the replacement
of the instances. The project in which I am working is analog VLSI, so
there are just too many different cells with too many transistors to
do this manually. What's worse, this is not the only technology for
which I need to do the migration, so the burden completely skyrockets
when considering the manual approach!

On the bright side, I am not planning to migrate any layout; in fact,
I haven't even done any layout for the orginal library because before
doing such gargantuan job I first want to see if the design works in a
smaller technology. As a matter of fact, this is why I am doing all
this migration stuff in the first place!!!

Well, I look forward to your comments. Thanks once again for any help!

Regards,

Jorge Luis.

 

Ooops! I got confused; the SKILL code I am using is not posted on the
mentioned thread. Here it its:

procedure( AMS035_to_IBM_7WL( t_LibName t_CellName )

; open the cellview
cv = dbOpenCellViewByType( t_LibName t_CellName "schematic" nil "a")

; walk through all the instances, replace nmos transistors
foreach( inst cv~>instances
when( ( inst~>libName == "PRIMLIB" && inst~>cellName == "nmos4" )
dbSetInstHeaderMasterName( inst~>instHeader
"bicmos7wl" "nfet" "symbol_compatible" )
inst~>m=1
inst~>n=1
) ;when
) ;foreach

; save & close
dbSave( cv )
dbClose( cv )
) ;procedure


Regards,

Jorge Luis.

 

You may have to force reevaluation of the callbacks. Do a search on
this group as there is already posted code (think it was Andrew)
describing how to reevaluate CDF callbacks in the object properties
dialogs. I have now used this reevaluation a couple of times
successfully when replacing parameters on large chunks of cells.

 

Thanks a lot for your remarks, Svenn. I think I have found the threads
you mention (specially the one entitled "Triggering callbacks"). I
however don't fully understand when should I execute these procedures
in order to accomplish effect of a total instance replacement.

Would the following approach make sense?:

1. For every copied schematic, perform the replacement of all
transistors instances using the code above
2. For every replaced instance in every schematic, force the execution
of all the callbacks for its parameters, using code like the
following:

; set the global variable used to communicate with callbacks
cdfgData=cdfGetInstCDF(inst)
; assuming W is the parameter that was modified
paramName='W;
callback=get(cdfgData paramName)->callback
when(callback && callback!=""
; catch any errors during the evaluation
errset(evalstring(callback) t) )

....and If so, how can I now in advance for which parameters of the
copied cells should I trigger the callbacks? ...Maybe it would be
better to just sweep all the parameters of each of the replaced
instances and trigger their callbacks when applicable, but, how?

Thanks again for your time and interest.

Regards,

Jorge.

 

If you inspect the CDF parameters attached to your transistor symbols
with CIW->CDF->Edit ... you will quickly see which parameters are just
parameters, and which have a callback. Typically w and l of a
transistor are set as numbers and then some realW and realL are
calculated based on w and l. w and l is typically entered by the
designer when he places the symbol.

In my case it was a property called simM actually used by the
netlister that took the value of m and just copied it. Very simple,
but I had to traverse the whole tree and execute the callback
executor.

I think it is a bit trial and error to find out which callback has to
be executed first as other may depend on it.

 

If you have callbacks which are order dependent, you're in trouble - and this is
a sign of poorly designed callbacks (although my feelings on CDF callbacks used
to compute other parameters are probably well known - see my sourcelink solution
"The Dangers of CDF Callbacks" where I elaborate on this).

If you've got the code I've posted before, you should be able to either call:

abInvokeCdfCallbacks(cellViewId)

or

abInvokeInstCdfCallbacks(instId)

(I think that's what it's called) to call the callbacks for every instance in a
cellView, or a specific instance. It's also possible to specify the order you
want to call them in (look at the comments in the code) if you really need to...

Regards,

Andrew.

 

Why not try the CIW->Tools->Technology File Manager->Attach to attach
whatever tech file you want