Stats

  • Locked Locked
  • Replies 7
  • Subscribers 143
  • Views 17242
  • 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

layout object purpose number directly?

drdanmc

if I have an ID for a layout shape, a "rect" for example,  I can get the layer number directly with

printf("Layer number = %u\n" fig->layerNum)

But to get the purpose number it seems I have to use

printf("Purpose number = %u\n" techGetPurposeName(tech, fig->purpose))

Is there a way to directly get the purpose number without invoking the tech file?  Similarly, for an MPP there doesn't seem to be a way to directly get at the purpose *or* layer number without going through the tech file.

But... I was looking at transferring some layouts from one technology to a different one where the layer numbers and purposes numbers are all different and may or may not have the tech lib for both the old and new technologies loaded at the same time.  For schematics, I just copy in unix-land (with tar) and then remaster all of my PDK instances and refer to a table that maps properties over and triggers callbacks, etc.  That seems to be working fine (yay for graphically compatible symbols).  On the layout end I was going to do  a similar thing (copy in unix-land, and then fix with skill code).  But I'm stuck on finding out the purpose number on shapes without invoking tech files which may or may not actually be accessible from the virtuoso session which is trying to fix up the layers.  What I had envisioned originally was something like

foreach(fig cv~>shapes

    old_lpp_nums = list(fig->layerNum,  old_purpose_num)  ;; but how to get old_purpose_num?  

    new_lpp_nums = conversion_table[old_lpp_nums]

    fig->layerNum = car(new_lpp_nums)

    fig->purpose = techGetPurposeName(tech_new, cadr(new_lpp_nums))  ;; would have been nice to have a ->purposeNum

)

to make matters worse, MPPs don't seem to give access to the layer number or purpose number in the subPart definition:

rodGetObj(fig)~>subParts~>layer  ;; is a string unless the layer is not defined in the tech file, then a number

rodGetObj(fig)~>subParts~>purpose ;; is a string unless the purpose is not defined in the tech file, then a number

so that translation looks like checking if I get integers or strings and if strings then use the new tech file to convert to numbers, then convert numbers with the old to new table, then convert back to strings with the new tech file.  Seems messy at best.

Am I asking for problems by allowing two different PDK libraries to exist in my cds.lib at the same time (what it would take I think to be able to gain access to both the old and new technologies simultaneously).

Maybe I should be using stream map files or even PVS so I can do logical operations if needed instead of directly fixing with skill code.

Thanks for any tips or pointers.

-Dan

  • Unfortunately there's no direct access to purpose numbers. What does happen though is that if you look at ~>lpp on a shape, then if the purpose (or layer) is not defined in the tech file it will return either the purpose (or layer) as a number instead. So I think you can do this without needing the original PDK enabled - that's probably safer than having them both at once (they may share some common functions, for example).

    It needs a bit of thought, and a little jumping through hoops, but I'd say it would be better to persist with this approach rather than going via stream (which is going to be a lossy process - you lose data that way because it doesn't preserve pcells, connectivity and so on).

    Regards,

    Andrew.

  • drdanmc said:

    printf("Purpose number = %u\n" techGetPurposeName(tech, fig->purpose))

  • in reply to Andrew Beckett
    Andrew Beckett said:

    Unfortunately there's no direct access to purpose numbers. What does happen though is that if you look at ~>lpp on a shape, then if the purpose (or layer) is not defined in the tech file it will return either the purpose (or layer) as a number instead. So I think you can do this without needing the original PDK enabled - that's probably safer than having them both at once (they may share some common functions, for example).

    drdanmc said:

    printf("Purpose number = %u\n" techGetPurposeName(tech, fig->purpose))

    I'm confused here. techGetPurposeName() gives out only the name of the given purpose. The original question of this thread and my need is to find the purpose number (GDS number given in the layer map for stream out). Is there any function to access this?

    -Ramakrishnan

  • in reply to RK56

    Ramakrishnan,

    I think it was just a typo - should have been techGetPurposeNum rather than techGetPurposeName.

    By the way, the purpose number and layer number are not necessarily the same as the GDS datatype and layer numbers. They're merely the layer number and purpose number used in the OA database.

    Regards,

    Andrew.

  • in reply to Andrew Beckett

    Then how do I access the GDS number that is shown in the pop up while hovering over the layer palate.

  • in reply to RK56

    That information comes from the layer map file (by default it's the techlib.layermap file in the techlib directory). So if your technology library is in a variable techlibName:

    ddGetObj(techlibName nil nil strcat(techlibName ".layermap"))~>readPath

    You'd need to read and parse that file to find the layer and datatype numbers. I don't believe there's a built-in API to do this (but it's an easy enough file to parse). OpenAccess doesn't keep this information as part of the OA technology library - it's in this separate file.

    Regards,

    Andrew.

  • in reply to Andrew Beckett

    Thanks.  I figured out a solution which I'm adding in case others find this thread in a search (or I find it in a few years).

    1)  As Andrew mentioned, "techGetPurposeNum" is what should have been in the original post, not "techGetPurposeName", the original was a typo.

    2)  shape~>lpp will return strings if the layer number and purpose numbers are defined in the tech file and numbers otherwise.   Same for shape~>purpose So I can do something like this:

    purpose_num = if(stringp(shape~>purpose) techGetPurposeNum(tech shape~>purpose) shape~>purpose)

    3) It appears that when setting ~>lpp I can use strings *or* numbers.  So for example (using made up numbers and names) either of these will work.

    shape~>lpp = list(50 -1)

    shape~>lpp = list("METAL1" "drawing")

    And assuming layer 50 is METAL1, purpose -1 is drawing, if I set via numbers, and then access shape~>lpp I'll see the strings.  That helps in terms of removing one additional layer of mapping.

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.