1 of 17

OpenSource

Parametric Cells

A proposal for Analog Design

2 of 17

Which tools do we have to create OpenSource parametric cells?

The following tools support parametric cells in one way or another:

KLayout, OpenRAM, Magic, Berkely BAG, Glade, Coriolis/Alliance

Alternatively, a standalone generator tool can be developed e.g. in:

Python, Perl, TCL

-> we have about 10 different ways to design analog cells

3 of 17

Why should we standardize

Estimation of IP cores that are interesting for OpenSource: ~1000 Cores (reference: www.opencores.org)

A very rough market estimation of the number of process variants:

Foundries: ~20 * Processes: ~10 * ProcessVariants: ~5 = ~1000 Process Variants

Number of OpenSource tools: ~10 Tools

4 of 17

Interoperability

If all those tools are not interoperable and the cores need to be written for each process variant seperately, then we have to design 1000*1000*10 = 10,000,000 cores (cores*processvariants*tools) for the OpenSource community.

I think this exceeds the capacity of the OpenSource community.

5 of 17

To improve this situation:

  • Use parametric cells and intelligent algorithms to ease the porting to different process variants

  • Standardize on one way of doing parametric cells that can be adopted by all OpenSource tools, so that the OpenSource community can reuse the designs and build upon each other instead of redoing the same work again and again

So what are the requirements?

6 of 17

Requirement #1: OpenSource

The language must be OpenSource (e.g. Python, TCL, Perl, Javascript, …)

The API must be OpenSource (e.g. KLayout, OpenRAM, BAG, …)

All required tools, base algorithms, … must be OpenSource (e.g. KLayout, OpenRAM, Librecell, ...)

Commercial algorithms should be pluggable too

7 of 17

Requirement #2: Hierarchical Cells

Bigger Cells MUST be able to reuse smaller Cells

Examples:

  • Pad-Frame -> IO-Cell -> Diode
  • Bidirectional Buffer -> Inverter
  • ADC -> Comparator

A global Comprehensive Cell Archive Network / Cell Package Manager

8 of 17

Flow

scn4m_subm

Process

specific

Tech Files

Generic

Cell Library

ParaCell

n-Bit DAC

  • Bits
  • aspectratio

ParaCell

1-Bit DAC

ParaCell

Resistor

  • Ohm
  • Fingers

Generate Script/GUI

Tech: scn4m_subm

Target Cell: n-Bit DAC

  • Bits: 8
  • aspectratio: 1.0

uses

uses

use this

process

layout this cell

MAG/GDS

Spice

.LEF

.LIB

.V

Outputs

Compiler

recursive use

Algorithm Library

Placer

Router

DRC

9 of 17

Technology availability

OSU018

LS1UM

CDTA1UM

SKY130

Documentation

Magic.tech

PDF

PDF

PDF

BAG

?

Available?

OpenRAM

Available

Available?

KLayout

Available

?

MAGIC/TCL

Available

Available

Available

Coriolis

?

10 of 17

Requirement #3: GUI capable

Graphical Tools like KLayout, Magic, … must be able to use the cells

The parametric cells must be defined in a way that graphical schematic and layout tools can get a list of all available cells, their parameters, default values, description-texts, …

11 of 17

Requirement #4: Non-GUI capable

The cells must be usable in an automated way without a graphical user-interface.

They must be scriptable, runnable on the commandline, without the attendance of a user. They must be usable by an automatically scheduled batch-job running in the night.

They must be able to run without a dependency to an X-Server.

12 of 17

Requirement #5: Access to algorithms

The parametric cells must have access through their API (Application-Programming-Interface) to a list of registered algorithms, like placement algorithms, routing algorithms, optimization algorithms, layouting algorithms, DRC algorithms, … there should also be a global platform for those algorithms like e.g. npm.

13 of 17

Requirement #6: Naming conventions

14 of 17

Requirement #6: Secure solution

The language / environment SHOULD be reasonably secure against malware. Malicious parametric cells SHOULD NOT be allowed to “import os” and then “os.do_damage()”

Unfortunately the only language I have seen that is field-proven for this requirement is Javascript, and that language isn't supported by the VLSI industry, so it does not seem usable.

15 of 17

Market Overview

https://docs.google.com/spreadsheets/d/1WCekt2rG9TuRLX3oyiutRltuByPh3TL9FUhmbxJgahg/edit

Click on the link for the updated version and review, comment, complete!

16 of 17

Target solution

At the moment it seems that most of the industry has agreed on Python to be the language for parametric cells.

So the question at the moment seems to be: Which of the APIs that are currently available (KLayout, OpenRAM, BAG, Coriolis, FaSoC, ?) is best suited, or already fulfilling all requirements?

We will try to organize an evaluation of all the existing solutions soon, any help is highly appreciated!

17 of 17

Please join the discussion

Thanks for your attention!

If you are interested, feel free to join our channel and help with the solution:

https://skywater-pdk.slack.com/archives/C016M3ZJ2RY

Are there any requirements we missed? Do you know any potential solution that hasn't been listed yet? Do you see any problems with the currently existing approaches for Parametric cells that you would like to see solved?