Stats

  • Locked Locked
  • Replies 9
  • Subscribers 127
  • Views 21921
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Global signals and spiceIn

kvntien

Hi all,

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?

 Thanks!

-Kevin 

  • As sort of a follow-up, when I try to define a global signal with something like *.GLOBAL soisub!, conn2sch warns me that it is not in fact global and that the '!' in the net name will cause it to be seen as global in schematic extraction. That's all fine and good since that's all I want, but then what is the *.GLOBAL statement doing...?
  • In the Spice definition there is no "!" as global assignment.
    So *.GLOBAL assigns nets in the Spice netlist to global nets.
    *.GLOBAL VDD VSS
    .SUBCKT cell1 Y VDD VSS A
     Assigns VDD and VSS as globals.
    See a similar post with an excellent explanation form Andrew:
    http://www.cadence.com/community/forums/T/26004.aspx

  • 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 VSS
    MP1 Y A VDD VDD pch w=2u l=0.5u
    MN1 Y A VSS VSS nch w=1u l=0.5u
    .ENDS

    using this devMap:

     -- Device Mapping file generated from SpiceIn GUI
    devSelect := pfet pmos4
            propMatch := pch

    devSelect := 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 IC6.1.5.500.16.2 (so ISR16).

    Regards,

    Andrew.

     

  • 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?

  • Sorry to keep adding, this is just quite an annoyance to me. Is it possible that the version of Assura we have affects this? Is the parser that Spice In uses tied to the physical install of Assura, or is it internal to IC615? Thanks, Kevin

  • Hi Kevin,

    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 view
    terminal name will be suffixed with !.
    WARNING (CONN2SCH-136): The cell view terminal VSS is connected to a global signal VSS. The cell view
    terminal 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:I
    MP1 Y A VDD VDD pch w=2u l=0.5u
    MN1 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.

    Regards,

    Andrew.

     

  • Hi Andrew,

    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!

    --Kevin 

     

  • Kevin,

    Yes, explicitly declaring the pins with *.PININFO means that it marks them as not being global any more.

    Regards,

    Andrew.

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. 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. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.