Stats

  • Locked Locked
  • Replies 5
  • Subscribers 126
  • Views 17065
  • 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

How to fix layers after changing layer numbers in the technology file

Sheppy

Hi,

This is what I have done:
I have updated layer number information in the technology file in the sections TechnologyFile->layerDefinitions->techLayers and TechnologyFile->layerRules->functions. The reason for changing the numbers is that in the original technology file, the layer numbers did not match the actual gds2 numbers. So exporting a layout to gds2 resulted in a not compatible database.The second reason is that I had to change layers because Virtuoso crashed due to inconsistent layer name-number mapping in the technology file, see post Home > Community > Forums > Custom IC Design > Virtuoso crashes when trying to instantiate a stacked Via (community.cadence.com/.../34766).

But then I ran into a problem: after the recompiling and attaching the new technology file, when I open an existing layout layers have changed color/fill or are completely invisible. It looks like Virtuoso does not store the layer purpose pair (lpp) as MET1:drawing, but rather as the assigned numbers, like 19:0. When you reassign the numbers to a different lpp name it will get the display information of that new name as specified in the display.drf file. If a layer had a number like 22:0, and this number is not assigned to any layer in the new technology file, it is completely invisible.

What I see is that all shapes in a layout have the layerNumber stored, and only a few have the layerName stored. When I do the following:
foreach( shape cv->shapes printf( "%L - %L\n" shape->layerName shape->layerNumber ) )
I'll get the following output (example after updating the technology file):
nil - 107
nil - 55
nil - 107
"METTOP" - 31
"VIAT" - 30
"METTOP" - 31
This looks to me that Virtuoso stores only layer number information (all shapes have the number, not all have the name) and when asking for the layer name, it simply matches the number to the name in the technology file. If a layer number is not associated to a name, it reports nil. So the name is not stored.

My questions:
1. How do I fix the layout after changing the layer numbers in the technology file?
2. Is it possible to configure Virtuoso so that is stores the layerName instead of the layerNumber?

If I have to roll-back all changes (giving each layer it's original, wrong, layer number again) I might end-up in a situation that I am unable to instantiate a stacked via, since Virtuoso will crash. How can I disable the stacked via option?

Thanks in advance.

With kind regards,

Sjoerd

  • Hi Sjoerd,

    First of all, I would suggest not changing the layer numbers in the techLayers section, because that will give you a big migration headache, and it's really unnecessary. So rather than answering your first question, I'll explain what I think you should do to the tech file instead. For your second question, that's not possible - the underlying database uses layer numbers.

    • The numbers in the functions section of the layerRules should be a sequence - they do not have to correspond to the mask layer numbers or the layer numbers in the techLayers section. Also, changing them later shouldn't be a problem either - but I would suggest they are a continuous sequence of numbers (no gaps).
    • There is no requirement for the layer numbers in the techLayers to match the stream (GDS) layer numbers. Given that you can have many more layers in Virtuoso than nominally are supported in stream, plus you have stream data types to contend with, this is normally sorted by putting a layer map file (called techLibName.layermap - e.g. gpdk045.layermap) inside the technology library which defines how to map layer purpose pairs to stream layer numbers/datatype numbers. So I would leave the numbers here as is - I doubt very much this is related to the crash you had (whereas the sequence numbers for the functions probably are related).

    You might want to take a look at the tech file from gpdk045 from as an example.

    Regards,

    Andrew.

  • In addition, the OpenAccess database only stores layer and purpose numbers. This keeps the database very compact, instead of having to store both the strings and the layer/purpose numbers. The design tool maps the technology information (layer name, purpose name and LPP) to the OA database. This was originally done for the sake of the designers rather than the design tools, although in Virtuoso, you usually refer to the LPP by layer and purpose names. When you look directly at the OA database, the layers and purposes are integers as are the coordinates, only when a design tool applies a technology file do you get names and floating point coordinates.

    As Andrew said, you can create a map between the Virtuoso data (layer and purpose names) and the GDS2 data with a layer map file.

    Ted

  • Hi Andrew,

    Thanks for the detailed reply.

    I ended up putting the original layer numbers in the technology file. The only change I made were the numbers in the functions part. There were duplicate numbers in there, and that was what caused the crashes.

    For the next PDK, I'll make sure I generate the technology file with the proper numbers (that layer numbers match the GDS2 layer numbers). I got this PDK from someone else (who "had to leave" the company) and they asked me to clean up the mess he left behind. Unfortunately, this mess is something which will have to be there...


    Kind regards,

    Sjoerd

  • Hi Ted,

    Thank you too for the reply.

    When I write p-cells (all pure SKILL), and add shapes in certain layers, I refer to the layers as follows: list("MET1" "drawing"). Referring to the original problem stated in the original post, all p-cells generated like this were still working fine. All other p-cells (generated by a p-cell made using the standard graphical p-cell editor) were corrupted after changing the layer numbers.

    Does this mean that:
    - graphical p-cells have th elayers stored as numbers
    - p-cells which are purely SKILL-based will always be working fine, thus the safest option when creating p-cells?

    If the second is true, this would be a huge incentive to never use a graphical p-cell editor.

    Kind regards,

    Sjoerd

  • SKILL based pcells are prefered, you can use the layer/purpose names instead of the layer/purpose numbers. I've never looked at the data in a graphical pcell but I bet the layer/purpose was stored as numbers. With SKILL pcells, you are creating the data when the program runs.

    If you are interested in graphically created pcells, check out Pcell Designer from Cadence Services.

    Ted

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.