Cadence version: IC6.1.5
Lately, we have been converting our design database from IC5 to IC6, using cdb2oa script, that was shipped along with IC6.
We managed to convert the database without any error. The schematic in OA matched perfectly to its CDB counterpart, but not for the layouts. Most of the layouts were converted correctly. Only a few showed some weird characteristics. For example, the location of a small part of layers (M1, M2, VIA1 and VIA2) in OA version got shifted in the same vertical direction (upwards). Their shapes and sizes still remained the same but shifted. It did not happen on the entire layers, just a part of them.
The command we used to convert the databse is shown as below:
/cadence/lnx_ic615.500.15/tools/dfII/bin/cdb2oa -lib library_oa -cdslibpath ../cadence_cdb -mapviaparams > cdb2oa.log
Did anyone run into this problem before? Please advise. Thanks.
I suggest you contact customer support. I wouldn't expect this to happen without some indication in the log file - maybe due to things snapping to the manufacturing grid?
In reply to Andrew Beckett:
Thanks, Andrew, for the quick reply.
I suppose I need to talk to the customer support.
There were a few warnings in the log file, but none of them related to the layers I am dealing with. Here I listed down the warnings I have: CDBOA-517, CDBOA-518 and CDBOA-639. I can provide the elaboration if you are interested.
At first, I thought it was something like "snapping to the closest grid", but I gave up the idea after finding out some of the shapes actually got shifted more than a grid away. Is there any snapping function in cdb2oa by any chance?
The latest finding of this issue was the inconsistency of the conversion outcome. I have deleted the OA library and re-converted it, using cdb2oa, the layout was different from the deleted one. This caused the debugging becoming worse.
In reply to sebastion:
There's no snapping function in cdb2oa as far as I know. Your consistency problem sounds very strange to me and not something I've seen before.
Something other things you may want to check.
You only mention that you are converting your design library.
Is your design referencing a pdk that you have previously migrated?
Or does the pdk already exist in OA and comes from a third-party ?
I have seen similar problems that were due to updates to the PDK.
I think the problem may be with the "-mapviaparams" switch but without more details I cannot provide more input
In reply to ColinSutlieff:
Thanks for sharing, Colin.
We got the PDK in OA version straight from the foundry and the design is referencing to the OA PDK.
May I know what makes you think that the "-mapviaparams" switch is the problem?
I had a silmilar situation a few years ago where the pdk had been updated. Something changed with the default values of the standard via definitions in the new pdk. This could be similar.
When you translate to OA, the vias themselves are not converted. They simply reference the via definitions in the new lib.
I think you may be converting symbolic or cdsvias to standard vias in OA.
With the -mapviaparams switch you are using the via default values from the instance masters of CDB instead of the default values from the standard vias in the OA pdk.
It is possible that things like layerenclosures are calculated differently in OA when defaults are used.
Check if you have values such as "NONE" in your original CDB techlib.
Or, simply try running the translator without the -mapviaparams switch
As always, if this doesn't help, contact customer support.
We have found the root cause! It is due to the OA techlib version that is older than its CDB counterpart.
After switching to the later version of OA techlib, all the weirds things went away. :)
@Colin: I have tried to run the translator without -mapviaparams switch, it caused more warnings and did not convert the vias correctly. So I think it has to be turned on, but I still do not understand why.
Anyway, thanks to Andrew and Colin for helping out.
I noticed that the prboundary/drawing [layer/purpose] layer in CDB got converted into prboundary/boundary in OA, through cdb2oa conversion. This has caused errors in LVL. Is there anyway we can disable the layer purpose conversion in cdb2oa? What I mean is that keep the purpose to remain the same after the conversion.
It does not convert it to prBoundary/boundary. It converts it to the new prBoundary object, which is not a shape any more. You don't want it to be a shape...
It uses the packet associated with the prBoundary/boundary LPP to display it, but the object has no real layer purpose pair any more (OA has specific objects for some things which were represented by layer-purpose-pair conventions in CDB).
If you are doing the LVL from a stream (GDS) file, then you can choose what LPP the prBoundary object gets mapped to. On the Stream Out form, if you show the Options and then go to the Objects tab, you can say which layer number/data type number a Boundary (Sub Object type of "PR") gets mapped to. Maybe that will help?
I see what you mean by converting to the new prBoudary object. However, I could still find prBoundary/drawing on the OA layout, on top of the prBoundary/boundary which was already converted to the prBoundary object. So is there any condition for the conversion to happen? In the CDB DB, only prBoundary/drawing layer was used.
I have streamed out the GDS by mapping the prBoundary object and managed to pass the LVL. Thanks. :)
I don't believe I saw that, but I wasn't paying that much attention... (and I've deleted my example now).
Anyway, glad you got it working!