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.
The Cadence Academic Network helps build strong relationships between academia and industry, and promotes the proliferation of leading-edge technologies and methodologies at universities renowned for their engineering and design excellence.
Participate in CDNLive
A huge knowledge exchange platform for academia to network with industry. We are looking for academic speakers to talk about their research to the industry attendees at the Academic Track at CDNLive EMEA and Silicon Valley.
Come & Meet Us @ Events
A huge knowledge exchange platform for academia. We are looking for academic speakers to talk about their research to industry attendees.
Americas University Software Program
Join the 250+ qualified Americas member universities who have already incorporated Cadence EDA software into their classrooms and academic research projects.
EMEA University Software Program
In EMEA, Cadence works with EUROPRACTICE to ensure cost-effective availability of our extensive electronic design automation (EDA) tools for non-commercial activities.
Apply Now For Jobs
If you are a recent college graduate or a student looking for internship. Visit our exclusive job search page for interns and recent college graduate jobs.
Cadence is a Great Place to do great work
Learn more about our internship program and visit our careers page to do meaningful work and make a great impact.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
Overview All Courses Asia Pacific EMEANorth America
Instructor-led training [ILT] are live classes that are offered in our state-of-the-art classrooms at our worldwide training centers, at your site, or as a Virtual classroom.
Online Training is delivered over the web to let you proceed at your own pace, anytime and anywhere.
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.
I have successfully imported the layout from Encounter, and solved out the residual DRC errors, however; I am not sure now how to do LVS.
Before I had some problems with import which were covered in another subforums here and topics but I solved them all, right now I want to concentrate just on a specific LVS on Encounter Imported Layout issue.
Here are my actions:
1) get the verilog design synthesized properly and routed without geometry/connectivity violations in Encounter [DONE]
2) Properly export it to GDS file [DONE]
3) do saveNetlist -phys -includePowerGround from the Encounter, it basically produces a Physical Verilog netlist, which includes cell description + Power pins. [DONE]
4) Go to Cadence Virtuoso, do CIW->Import->Verilog, there I point to the physical verilog netlist produced by Encounter and also point to the newly created library based on technology kit with imported proper metal layers.
5) then i start the process of importing scehmatics for CDL, I see that the cells are created one after another, and the main big schematics is created, where each module of the schematic is the standard library cell. However, when I click and get inside that cell I see only ports, and no transistors.
It might look OK, since afterall it has imported physical VERILOG netlist, not a transistor schematic.
But problem starts when I try to produce CDL netlist using the IBM provided Perl script for the LVS. The final output of that script is MY_INSTANCE_NAME.netlist.lvs
However, when I start now doing LVS on the corrected/DRCed Layout, I get errors like:
a) nMOS on layout is unbound to any schematic device
b) pMOS on Layout is unbound to any schematic device
c) subC on Layout unbound to schematic device
Error (c) is OK, I can fix it simbly by adding the substrate contact in the imported schematics.
(reason for that is that DRC does not pass without proper amount of substrate contacts on a layout, so in an imported layout I added them.. but then again, I added it also in the schematic, so error (c) was gone)
However, what really weird is: why do errors (a) and (b) exist?
From one side, I understand, it does not SEE the transistors because the cells imported from physical verilog dont have one (because verilog describes hardware flow not transistor interconnect)
But from another side, why would it even try to find transistors?
Why does not it treat my imported layout cells as a standalone modules with just ports, because that is what they are.
I even tried creating CDL netlist in "Digital" format from the imported schematics view, same thing.
Am I missing something trivial here?
If you have in your top layout view some layout representation for the standard cells which contains transistors but your schematic view representing the standard cells are empty then your LVS tools is going to report them.
Most of the time founders provide a CDL file which contains the transistor description of your standard cells then you need to include into the netlist one your feed to your LVS file.
In reply to Alex Soyer:
Ok, I do can find the CDL file with standard cells. It seems that I am kind of close to solution but still have some questions.
Now I guess question is, how exactly I include it? Here are my steps:
1) Create CDL netlist from schematic which is imported from verilog (that schematic contains only instances of standard cells)
2) Use the script to transfer CDL netlist to LVS format
3) Go to LVS, in the LVS include the schematic netlist in LVS format obtained from step (2), and also include pure CDL file from standard cell library with all descriptions of standard cells.
As a result, this time LVS doesnt fail, however; it reports about thousands of mismatched layout<->schematic devices, like transistor width mismatch etc.
Seems like I am really close, but just missing something, what else had to be done there?
In reply to Kabal:
We are making progress this is great.
In step 2 why did not you run teh same script ofr teh std cells cdl ? Isn't it required is the format already ok?
In order to easily debug it I would suggest that you look at one std cells at a time.
You could for exmaple run a LVS on one std cells like the most basic invertor that you have in your design.
Alright, in step 2 I did choose just CDL now. (i noticed that it doesnt matter)
Here are my actions/observations:
1) I opened schematics of imported inverter (again, its schematics contained only *pins* and nothing else)
2) Export netlist
3) Apply CDL processor to convert it to LVS netlist format
4) Go to layout, start LVS window, there point it to two files, one file produced from empty schematic in step (3), another file is std. lib CDL file.
As a result two major errors were reported like something described below:
a) Terminal B of pMos should be connected to VDD! instead of floating pin.
b) Terminal B of nMOS should be connected to GND! instead of floating pin.
At this stage, let me tell something: When I design for example some custom inverter by hand in my own libs, and when I lay it out, I always put Nwell and Substrate contacts in a layout. But in a schematic I put only substrate contact primitive. Then I pass LVS.
Now back to this issue, error (2) was manually corrected simply by putting Nwell contact, after that when I ran LVS it only reported me error (b)
However, when I try to correct error (b) by putting substrate contact and then run LVS, the LVS process *FAILS*, and in the log it says that substrate contact on a layout is unbound to schematic. I tried to put substrate contact with GND! connection on top in a schematic, it didnt help.
And by the way, is it kind of a pain generally one has to deal with when working with Encounter layout import? (what I mean is the mess around with nwell/substrate contacts) ?
>Kabal, Is the layout view provided by your founder?
Yes. They provide GDS file, which I independently imported to my library, and could see all the layouts and open them in layout editor. And during GDS export from Encounter, I merged the final GDS of my design with the GDS file of the standard cells. That is how I had to do it for all the layers to show up correctly.
>Did you check your layer map file and your rule deck?
During that export process I pointed to the MAP file provided by customer as well, that MAP file was specifically made for Soc2GDs transition. Rule deck? whats that? You mean LEF? yes they were provided to Encounter
>Can you check the Bulk pins connections in layout?
There are *no* ones. When I imported the GDS file produced by Encounter in a way described above, the fresh library to which everything was imported had the standard cells, like INVERTER which I messed with before. And that Inverter, and all other type of pins have VDD! and GND! routed metals on top and bottom, but they do *not* have contacts to well or substrate. Which is weird right? I also did import the standard cell GDS manually from virtuoso to a separate library, and the layouts of each elemnts also do *not* have contacts to well and substrate.
>You r transistors should be connected to these substrate connections using a diffusion layer pwell or nwell but it should not be needed to add substrate contact or nwell contact.
So that is how things done normally with most Kits right? I mean is that how the big digital projects get done then, tool (Encounter+Kit LEF) takes care not only for net interconnect but also properly should place Nwell/Substrate contacts, right? Turns out that it is not a case then for me.. Does it mean a *HUGE* nightmare to design/route/LVS in Virtuoso a really big digital project? Or maybe there is something I missed during setup of flow and thats why it appears like that? Because, actually theres not much to do, all one does is a) provide LEF, b) provide RTL synthesized verilog c) route d) export GDS, e) import in Virtuoso f) DRC in virtuoso g) LVS in virtuoso. Seems like I am stuck on (g) but if tool didnt place contacts (or didnt take care of it) then I am stuck with (f) too because I *must* place them.
So, the way it looks to me now is that lots of stuff is now concentrated on this issue of bulk pin connection. Because if I place it, the schematic would require it to be there. But standard CDL files usually dont have those entities. So it complains. So if I am correct, I must somehow 1) Make encounter to put bulk connections/contacts during routing 2) somehow resolve the substrate contact issue.
You ever came across such situation? i.e. standard cell layouts without bulk connection and same during autorouting in Encounter?
Can you try to go for LVS without importing the GDSII in Virtuoso ? You can use the GDSII exported directly out of Encounter.
With this trial we will check if teh probelm is potentially due to the GDSII import in Virtuoso
Here are three ways I tried:
1) After encounter auto-routing done, just produce physical verilog netlist and GDSII. Then Run LVS and as a netlist point two files: produced physical Verilog netlist and CDL library, and as layout source GDSII. Result: LVS failssaying something like "duplicate subckt name AND2_F in .CDL file of standard library. Its weird that it complained only on that gate..
2) After encounter autorouting, produce physical verilog netlist and GDSII, run LVS and point only to verilog netlist as netlist source, and to GDSII as layout source. Result: LVS fails saying unbound nMOS/pMOS.
3) After auto-routing done, do add FILL1. Then produce physical netlist, and do LVS again, LVS failing saying that: FILLER1 not defined.
I have a feeling that something is wrong with FILLER/Conencting the substrate contacts when I do LVS versus imported Layout. But as you saw now, doing LVS with Stream looks even worse..
OK, following Solution 3, but I have problems with setting ignore on empty cells. I have three types of FILL cells: FILL1, FILL2, NWSX. And it seems to me that the ignoreCell avParameter of LVS only works for Layout view, not a Stream.
But here is anothe thing I did, I think I am really close to solution:
1) In the encounter after final routing done, add: FILL1, FILL2, NWSX
2) Produce GDSII by merging with GDS of standard cells
3) Import that GDSII in Layout in Virtuoso, guess what, now when I do DRC I *DO NOT* see those missing well/tap contact errors anymore. In other words, it looks like now DRC is clean (just some IO port misalignment on Pin layers, but that was fixed really quick). So, it looks that I do not have to add those substrate contacts in schematics or whatever to pass LVS, all I need now is just to pass LVS.
However, problem is, that once I start doing LVS of this nicely imported layout with clean DRC, I again get errors like: FILL1, FILL2, NWSX not defined.. and that ignore method described above doesnt work. Even though now, I do LVS over the Layout... so it should work. I attached picture showing avParameter for ignore cells.
I tried already all kinds of combinations, doing ignoreCell both for layout and schematic (by showing verilog file) in avCompare rules as well. its still same! LVS fails with saying that: FILL1, FILL2, NWSX is not defined.. it just doesnt make sense, am I missing something?
By the way, same error occurs if I want to LVS versus the Stream of GDSII. Ok, anyqay, I again decided to go from scratch from the point of clean DRC after Layout import.
I have my main module called refleks_switcher routed with added fills in Encounter, and I imported its GDSII into library called r_test2. The DRC was clean (after fixing port pin layers), i.e. *NO* substrate contact related DRC errors which would require me to add substrate contacts in schematic. And again.. that is because after final routing in Encounter I added: FILL1, FILL2, NWSX.
So, I am attaching now the log file of Assura fail run. Do you notice that at some point it actually TELLS that specific cells which I want to be ignored *ARE* ignored? But then later, it says:
*ERROR* cell 'FILL1' is not defined.
*ERROR* cell 'NWSX' is not defined.
*ERROR* cell 'FILL2' is not defined.
Also, the FILL1,FILL2,NWSX cells are imported into r_test2 library as well. I can see their proper layout view.
Why is it doing it? If the LVS ignored those cells, why again it says that they are not defined? Have any idea what exactly is going wrong here?
To be even more precise, I am attaching LVS settings window with avParameters and avCompare rules with preview, does it look right? My LVS tool is Assura LVS.
What exactly am I doing wrong when telling LVS to ignore FILL1,FILL2 and NWSX cells?
My knowledge on the Assura setup is very limited but I have asked on of my colleague to help here.
This question was split off by Kabal to a separate thread.