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.
I am trying to import a CDL netlist using Spice In to generate a schematic view. However, I would like to keep the VDD and VSS pins local. When the import process calls conn2sch, conn2sch insists on appending a '!' to those net names because it thinks they should be global...
In my CDL netlist, there is no *.GLOBAL or *.PIN control statement, and the subcircuit header reads as
.SUBCKT cell1 Y VDD VSS A
I generated just a netlist view and sure enough the VDD and VSS signals in the view have isGlobal set to 't'. Where does this occur in the translation process, and how can I prevent that from happening?
In reply to kvntien:
In reply to berndfi:
Right... I understand that post and had already read it, but I am having a different issue (and also not using CDL In, but Spice In).
I /want/ my pin names to be just VDD and VSS, but the translation process forces them to VDD! and VSS! independent of the presence or lack thereof of a *.GLOBAL statement.
In the Dracula documentation for how it handles CDL netlists, 'VDD' and 'VSS' are in the list of names that the power/ground pins must have. Does anyone know if this is true for the Assura parser that Spice In uses? In which case, does the parser auto-mark such signal names as global regardless of what else is in the CDL netlist?
I don't see this. I just imported this CDL netlist:
* example of block with supplies.SUBCKT blockWithSupplies Y A VDD VSSMP1 Y A VDD VDD pch w=2u l=0.5uMN1 Y A VSS VSS nch w=1u l=0.5u.ENDS
using this devMap:
-- Device Mapping file generated from SpiceIn GUIdevSelect := pfet pmos4 propMatch := pchdevSelect := nfet nmos4 propMatch := nch
(I had analogLib as a reference library, and had chosen CDL as the input language).
I ran this with both the normal schematic generation and also the Analog schematic generation. The ASG picture is below. Checking in the database, VDD and VSS signals don't have isGlobal set.
I'm using IC126.96.36.1990.16.2 (so ISR16).
In reply to Andrew Beckett:
First, thanks so much for trying to reproduce the issues, Andrew, I appreciate it a lot.
Unfortunately, I tried with your minimal example, and I still see the same issues... my generated schematic (analogue) is the same in every regard except for the VDD and VSS pins; conn2sch still warns that VDD and VSS are supposed to be global and appends a '!'. I'm importing into a library with no techfile attached, and with no PDK customisations, too...
We're running ISR12, so maybe that's the issue?
Either way, any ideas where this might be tripping up? Odd default settings in the Assura parser hidden away somewhere?
I just tried it in ISR12, and got:
WARNING (CONN2SCH-136): The cell view terminal VDD is connected to a global signal VDD. The cell viewterminal name will be suffixed with !.WARNING (CONN2SCH-136): The cell view terminal VSS is connected to a global signal VSS. The cell viewterminal name will be suffixed with !.WARNING (CONN2SCH-134): The signal VDD is a global signal but does not end with '!'.WARNING (CONN2SCH-134): The signal VSS is a global signal but does not end with '!'.
And I see the pins as being VDD! etc. I don't get this in IC615 ISR16. A bit of searching, I found CCR 910263 which implemented this (unfortunately I can't quite see which subversion it was integrated in, but I know it was after ISR12.
I've got a workaround for ISR12 though. If you add *.PININFO statements within the .SUBCKT, you can force the pins to be input pins. For example:
* example of block with supplies.SUBCKT blockWithSupplies Y A VDD VSS*.PININFO VDD:I VSS:IMP1 Y A VDD VDD pch w=2u l=0.5uMN1 Y A VSS VSS nch w=1u l=0.5u.ENDS
BTW (to answer your last question), this is nothing to do with the Assura version you have installed. Assura doesn't even need to be in your path for SPICEIN to work.
I'm really glad to hear that what I was seeing was in fact incorrect behaviour! I've been pulling my hair out reading the documentation trying to see where I could've been going wrong.
Thanks for the fix with *.PININFO; is this a result of the .subckt internal *.PININFO declaration forcing those pins to look local?
And about the Assura version, I was aware that it didn't need to be in the path (as it is in fact not in our setup), I was just grasping at straws :).
Thanks again for the help!
Yes, explicitly declaring the pins with *.PININFO means that it marks them as not being global any more.