• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Custom IC SKILL
  3. defstruct in pcell (for layout), is it possible?

Stats

  • Locked Locked
  • Replies 8
  • Subscribers 144
  • Views 14856
  • 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

defstruct in pcell (for layout), is it possible?

sjoerdh
sjoerdh over 10 years ago

Hello,

This is what I want to do:

  • Create a pcell that instantiates other pcells (layout)
  • Perform various "measurements" on this new instance (i.e.: retrieve the bounding box)
  • This information has to be used lateron in the pcell code

I'd like to store this information in a table, where each cell is a defstruct.The code looks like this:

procedure( genCurMir( ... )
    let( ()
        ...
        curMirInst = makeTable( "curMirInst" nil )
        defstruct( instance boundingBox gateCenter drainCenter sourceCentre )
        curMirInst["CELL1"] = make_instance()
        ...
        curMirInst["CELL1"]->boundingBox = instID~>bBox
        ...
    ) ;;; end of let
) ;;; end of procedure genCurMir

After generating the pcell (loading the code containing the command "pcDefinePCell") weird things happen: I am unable to open any view (layout/schematic/symbol/...).Entering commands in the CIW will result (9 out of 10 times) in an error, which is the same error when trying to open any cell-view:

*Error* setq/set: Variable is protected and cannot be assigned to - instance

I have tried creating the defstruct with an other name (blablablabla, definitely not used anywhere else), but the same error, only "instance" replaced by "blablablabla". I have to restart Cedence to regain control.

Furthermore, this created defstruct seems to be global, whereas I created it inside a let. I'd like to keep it local though.

So my question is:

Is it possible to use defstructs in pcells?
If so, what am I doing wrong?

I'd realy like to use this method (table of defstructs) since it is very conveniant.

Any help is highly appreciated.

Thanks in advance,

Sjoerd

  • Cancel
Parents
  • Andrew Beckett
    Andrew Beckett over 10 years ago

    Hi Sjoerd,

    First of all, there is no problem with the defstruct using a global object to store its definition. After all, that's what your functions are too - these are globally named functions (unless you use lexical scoping in SKILL++ to have local functions, or potentially using the namespace mechanism in IC616 (I wouldn't recommend that currently since it needs some refinement in my opinion)). You're not really using a global object to communicate data - it's just a global definition - after creation you don't change it. So the trick is simply to give it a sensible prefix, which is what you should do with your functions too.

    Now, on to your question. Your table of tables is NOT a table of tables. It's a table, indexed by a list. Because of that, you have more keys in there than you really want. You could of course just filter them (using setof):

    foreach(key sortcar(setof(k tempInst cadr(k)=="name") 'lessp)  printf( "%L\n" tempInst[key]))

    Or have a conditional:

    foreach(key  sortcar( tempInst->? 'lessp) when(cadr(key)=="name" printf("%L\n" tempInst[key])))

    Or actually implement it as a table of tables! This is what I would do if I was implementing this without a defstruct - it means your keys in the top table are what you actually want them to be, rather than making the keys a compound of the real index and the slot name. So for example:

    tempInst=makeTable( 'tempInstTable nil )
    tempInstDS[1] = makeTable('instThing nil)
    tempInstDS[2] = makeTable('instThing nil)
    tempInstDS[3] = makeTable('instThing nil)
    tempInstDS[1]->instName = "instC"
    tempInstDS[2]->instName = "instB"
    tempInstDS[3]->instName = "instA"
    tempInstDS[1]->instOrient = "R90"
    tempInstDS[2]->instOrient = "R180"
    tempInstDS[3]->instOrient = "MX"

    Then you can use the rest of the code exactly as you did with the defstruct implementation. So for example:

    foreach(key sort(tempInstDS->? 'lessp) printf("%L\n" tempInstDS[key]->instName ))

    This works because rather conveniently if you have a table with symbols as the keys you can do:

      table->instName="instD"

    which is exactly the same as doing:

      table['instName]="instD"

    but has the readability of it being a defstruct or a DPL. It also makes it very easy to change a code implementation originally built using DPLs to tables, which can lead to a big efficiency improvement since DPLs are sequential, compared with tables which are hashed.

    Kind Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Andrew Beckett
    Andrew Beckett over 10 years ago

    Hi Sjoerd,

    First of all, there is no problem with the defstruct using a global object to store its definition. After all, that's what your functions are too - these are globally named functions (unless you use lexical scoping in SKILL++ to have local functions, or potentially using the namespace mechanism in IC616 (I wouldn't recommend that currently since it needs some refinement in my opinion)). You're not really using a global object to communicate data - it's just a global definition - after creation you don't change it. So the trick is simply to give it a sensible prefix, which is what you should do with your functions too.

    Now, on to your question. Your table of tables is NOT a table of tables. It's a table, indexed by a list. Because of that, you have more keys in there than you really want. You could of course just filter them (using setof):

    foreach(key sortcar(setof(k tempInst cadr(k)=="name") 'lessp)  printf( "%L\n" tempInst[key]))

    Or have a conditional:

    foreach(key  sortcar( tempInst->? 'lessp) when(cadr(key)=="name" printf("%L\n" tempInst[key])))

    Or actually implement it as a table of tables! This is what I would do if I was implementing this without a defstruct - it means your keys in the top table are what you actually want them to be, rather than making the keys a compound of the real index and the slot name. So for example:

    tempInst=makeTable( 'tempInstTable nil )
    tempInstDS[1] = makeTable('instThing nil)
    tempInstDS[2] = makeTable('instThing nil)
    tempInstDS[3] = makeTable('instThing nil)
    tempInstDS[1]->instName = "instC"
    tempInstDS[2]->instName = "instB"
    tempInstDS[3]->instName = "instA"
    tempInstDS[1]->instOrient = "R90"
    tempInstDS[2]->instOrient = "R180"
    tempInstDS[3]->instOrient = "MX"

    Then you can use the rest of the code exactly as you did with the defstruct implementation. So for example:

    foreach(key sort(tempInstDS->? 'lessp) printf("%L\n" tempInstDS[key]->instName ))

    This works because rather conveniently if you have a table with symbols as the keys you can do:

      table->instName="instD"

    which is exactly the same as doing:

      table['instName]="instD"

    but has the readability of it being a defstruct or a DPL. It also makes it very easy to change a code implementation originally built using DPLs to tables, which can lead to a big efficiency improvement since DPLs are sequential, compared with tables which are hashed.

    Kind Regards,

    Andrew.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information