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.
This problem differentiates from another post, but it is more relevant to termOrder case, thats why I created separate this thread.The problem is that during LVS I get a lot of pin mismatches, however; according to the CDL netlist for LVS all the schematic-to-pin connection in the top cell are correct.Again, I have one cell with layout view generated before, and with a auCdl view as a symbol. So it has just two views, layout and auCdl. The name of that cell with two views is refleks_switcher. I instantiate the auCdl view of refleks_switcher cell in another top level cell called refleks_switcher_wrapper. After that, I export the CDL netlist for LVS. Then I go ahead and create another layout, that layout is basically a wrapper layout, I just instantiate refleks_switcher layout view and then add ports with "_top<N>" suffix in them, where N is just number of each individual port. Then I perform the LVS of the top layout view, and get a lot of pin mismatch errors. For example something like this:
Pin SchNet : LayNet--- ------ : ------rst pwm_ctrl_top : rst_toppwm_ctrl pwm_out_top<0> : pwm_ctrl_topThis does not make any sense! If you look at the attached CDL netlist file, you will see that the cell refleks_switcher or XI19 is connected properly pin-by-pin according to SUBCKT and PININFO statements! and same goes for layout! I have no idea why this tools acting crazy!
I am attaching 5 files in this and next posts:
cdf_properties.png - snapshot of refleks_switcher CDF properties, where you can clearly see my termOrder defined.schematic_top.png - snapshot of schematic in top cell called refleks_switcher_wrapper with the auCdl view of refleks_switcher cellrefleks_switcher_wrapper.netlist.lvs - a CDL file produced from top schematic for LVS.cdf_dump.txt - CDF dump of refleks_switcher celllvs_output.txt - an LVS output which shows pin errors.
In reply to Kabal:
I partially figured out the problem.. The biggest problem was in < > [ ] bus expansion symbols!! The thing is, layout was generated from Verilog, and there busses had to be with [, but in auCdl and higher level block I used <> So there is an option to change <> to [ during CDL generation, I used that option and it changed <> to [, however; for some reason all VDD! and GND! nets lost their ! symbol, and just became VDD and GND. So I had to manually correct for that.I hate to say this but this software has tons of bugs! And sometimes its just "anything goes" principle which works out.
Anyway, the reason I am saying problem is partially solved is because CDF temOrder is still not being respected by netlister. In this post, I am attaching the manually corrected final CDL netlist for which LVS worked out without errors.You can see that the ports and busses for instance XI19 have a different term order than in the CDF properties window attached in previous posts. But that is a combination which worked! And also, note, that it is NOT in alphabetical order! In the top layout, I connected each port pin to corresponding xxx_top[N] pin, where N is a right number. (also, layout has [ for pins belonging to buss).Now what should I make out of it? If someone can notice some errors I would like to know them.Let me actually be even more precise: It's not that the order which I set in CDF property editor line does not appear, its just I do not know what order to write there.For example, if I write some term order in that CDF window in the auCdl line, it will appear in exactly same order in XI19 instance in netlist file during netlisting.The real problem is, that I do not know which order will work out and I have to guess it to find the one which works and results in successful LVS.
Without seeing your verilog, it's hard to know - but it appears that the issue may be related to the order of the bus expansion. If you need to control the order, you'd have to put the individual bits in the termOrder in the right order. I think otherwise the order is form LSB to MSB - and if this doesn't match the order in the Verilog, it won't work. Looking at what you've changed, it's that the order was original 0 to 7 and is now 7 to 0.
I'm not that sure that the [ vs <> should matter here - because the leaf cell (refleks_switcher) is going to connect by order, not by name.
You confused me a bit because the original post didn't look the same when I looked at it, so I assume you edited it after posting.
BTW, you wouldn't normally instantiate an auCdl view directly in the schematic. You'd have a symbol and an auCdl view (which are the same). You instantiate the symbol, and then during netlisting it would view switch to the auCdl view. It shouldn't cause problems doing what you've done, but it's a little unusual.
In reply to Andrew Beckett:
Hi Andrew,Yes original post had simpleer example, I deleted it, then put this example where all top ports are different to better udnerstand situation.You was actually right about verilog port order, in fact I was suspecting that too before, but since it didnt matter because of [ <> issues I thought its not verilog order which matters. Only when I managed to get it working after changing <> to [ during netlisting and after arranging my ports in CDF termOrder I discovered now that they match the way how they appear in verilog!Here is the description of top instance from verilog:
module refleks_switcher ( clk, rst, pwm_in_port1, pwm_in_port2, pwm_ctrl, pwm_out, \VDD! , \GND! );If you look again at the working final netlist from my previous post, you will see that it matches the verilog port order shown above!So, turns out, that in order to get it working, one just needs to create auCdl and symbol views which are same, go to CDF properties and arrange the termOrder in a way in which it appears in the top verilog cell in verilog source.Then in LVS, just put in three files: top verilog source, CDL description of standard cells and final CDL netlisting of top structure.And yes, <> vs [ matters! I verified it! If I do not use an option to change <> to [ during netlisting the LVS goes banana. The only weird downside is, as I described before, after Netlisting with <> to [ change option, the exclamation mark "!" is removed after all GND and VDD ports, so I have to go ahead and add them, but its kinda ok, I can live with it so far, at least things are working as they "supposed" to.p.s. also had to add *.RESI to final netlist because of those cds_thru things. And yes, I will use auCdl and symbol views which have same content from now on. Also, I control CDF bus ordering with "D" property set up in .simrc.OK, finally, digital placing/autorouting with further integration in Virtuoso without involving schematics is achieved.Thanks.
I'm not sure why the <> vs [ should matter, unless your pins are labelled in the layout with [. Maybe that's what is going on here.
The *.RESI should not be necessary if you fill in the Resistor Threshold Value on Export CDL form (default is 2000; you may want to set it lower).
Note that in recent versions, the cds_thru should netlist as *.CONNECT statements rather than as a small resistor. Not sure which version you're using. So *.RESI would be irrelevant.
Which IC615 subversion are you using? Don't think you'd ever want to use cellIgnore for this, because that just removes the block - it won't short them. The cds_thru has got lxRemoveDevice on it (which caused the CDL netlister to attempt to short the nodes in earlier IC615 versions, and if that failed, it would netlist as a small resistor); in later IC615 subversions it should netlist it as a *.CONNECT statement, and so the shorting is done in the LVS tool. With the small resistor, a low enough *.RESI is needed to short inside the LVS tool.
I'm not really sure precisely what the problem is that you have with [ and <> - I'd need to see the data. Maybe you can report this to customer support so we can take a full look at your data.
I'm using IC18.104.22.1680.1OK, I'll take into account that .CONNECT thing for future version.Regarding <> and [, since I found a way to work with it and can move forward with my design, I'll leave it for now, otherwise I'll spend another countless hours with tech support on issue which actually doesnt hold project now.Thanks for all your hints Andrew