Open PDKs Version 1.0

Table of Contents

Stable Version Release Notes
Older Version Release Notes
Things To Do
Bug Fixes

Open_PDKs version 1.0 Release Notes

Version 1.0.0 was released to the public on July 5, 2020. This version includes files for generating a PDK based on the Google/Skywater sky130 open process definition.

To-Do List for Open_PDKs version 1.0:

Goals of the open_pdks project:

The intended goal of open_pdks is to be able to support as many open source EDA tools as practical, and to be able to generate all needed files for those tools from any sufficiently complete set of vendor files.
A number of file conversions are not available but would be useful to have:

SPICE to liberty:
Create timing files by running simulations on SPICE netlists using ngspice.

liberty to verilog:
Use the function statements in liberty format to create verilog primitives. Maybe use liberty timing information to generate LEF specify sections.

verilog to liberty:
Reverse of the above. Use verilog logic tables and specify sections to generate liberty functions and timing tables.

File formats that need to be supported:

Schematic and symbol:
There are few standards, so either everyone needs to agree on a good format to use, or there needs to be a lot of scripts to do conversions between formats. Open EDA tools that could be supported include:
  • electric
  • xcircuit
  • kicad
  • sue2

Other open source EDA tools that need to be supported:

Commercial EDA tools can potentially be supported under this same system, provided sufficient compatibility with the file system structure.

Other scripts needed:

Project setup script: It would be useful to define a "standard project file structure" that is similar to the standard PDK file structure defined in open_pdks. The preferred project setup based on the efabless model is:
techdir (symbolic link to open_pdks PDK)
project.json (information file for tools)
tool_name (magic, qflow, ngspice, etc.) or
format_name (spice, gds, verilog, etc.)
In general, tool_name directories are intended to be workspaces for specific EDA tools (and may have their own nested hierarchies; e.g., qflow/digital_block/source,synthesis,layout) while format_name is a place to keep (final) files of a specific format, with the intention that any project can easily be made into an IP library and folded into the open_pdks scheme with little effort.

The project.json file contains project information that can be used by a script to build a setup for any EDA tool. One goal of the project.json file is to define "datasheet" (documented elsewhere) that can be used to drive characterization simulations and create a datasheet for the project. Field "ip-name" of "datasheet" is the canonical name of the project, which can be distinguished from the project directory top-level name, such that the project can be moved or copied without affecting the tool flows.

Bug Fixes from previous versions:

As of version 1.0.0, there are no previous versions.


Last updated: July 6, 2020 at 12:27pm