Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
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!