converting transistors in a schematic from analogLib to technology library

Dear Reza,

Rezara said:

I want to generate a general schematic that can be handled in all techs and then in each tech I want to convert the transistors from analogLib to the technology transistors. Is there any way to do this?

While it is possible to convert a schematic in one technology node to another technology node (or the same technology with a different set of processing options), it is not straightforward and requires some proficiency with SKILL.

I am not sure I fully understand your motivation. However, if it is to create a "generic" version of a subcircuit schematic and then "automatically" migrate it to an arbitrary technology in the interest of saving a lot of "schematic re-work", my personal opinion is you will not save any time. Why do I suggest this?

1. When migrating between technology libraries or technology nodes, the options and capabilities of devices change. Hence, one must make decisions about what parameters in one technology should change to in a different technology or technology node. These translation rules will be specific from one technology to another and must be included in the SKILL routine you used for the schematic translation. For example, what rules must apply to convert a planar MOS device with a given width and length to a FINFET MOS technology? This rule is only specific to this particular technology transfer. This includes resistor, resistor types, capacitors, and capacitor types. This is  a huge undertaking in my opinion!

2. The schematic symbols for devices (MOS, BJT, resistors, capacitors, varactors...) are not all common to all technology PDK. I believe this will always require some schematic re-work to make the schematic more readable after the translation.

3. Design decisions must be made about device sizes due to technology limits (currents, voltages, current densities). Programming this into a single translation routine seems to be a bit unrealistic when one considers the many, many applications for a "generic schematic". Would you agree Reza?

In summary, there are routines to do the translation from one technology to a second, but to generalize it seems a bit unrealistic to me. I'm open to your thoughts or, of course, any correction of my understanding of your question Reza!

Shawn

Shawn

Thank you Shawn. I see your point. But my idea is to make a GUI skill for this translation in order to make sweeping parameters. Although generally it is what you said but a design procedure based on Gm/Id might be a general solution for advanced nodes. Regarding the symbols, as long as I experienced, the core transistors are the same and for the FINFET you can keep W and sweep NF. You see my point? I always have to move between nodes and it is really bothering, 180 to 65, 40 to 90, 65 to 22, etc. And I realized that I can make what I am currently doing automatized. Do you agree or I am missing sth?

Dear Reza,

Rezara said:

But my idea is to make a GUI skill for this translation in order to make sweeping parameters. Although generally it is what you said but a design procedure based on Gm/Id might be a general solution for advanced nodes.

I believe I understand 100% Thank you for confirming my understanding Reza! While yes, the use of a metric based on Gm/Id may be useful, I think it neglects frequency effects as well as the impact of other parameters such as DC leakage, output conductance, and other AC parameters that are greater or less pronounced in different technologies/process nodes.

Rezara said:

I always have to move between nodes and it is really bothering, 180 to 65, 40 to 90, 65 to 22, etc. And I realized that I can make what I am currently doing automatized. Do you agree or I am missing sth?

I can fully understand your frustration! I am also faced with migrating between different technology/process nodes or simply different technologies within the same process node. I can only express the fact that every time we migrate, a new script is required to help with the schematic conversion. We have never been able to use a "generic" script. Each script requires significant effort with a lot of back and forth with the design community to provide reasonable translation options. Even with this, I still spend considerable time after the translation to further optimize designs for the specific application.

In short, what you propose sounds ideal, but without sounding pessimistic, my experience suggests the ability to generically translate between an arbitrary set of technologies or process nodes with a single script may not be practical.

Shawn