This document describes the high-level architecture of openPCells. This serves as an introduction to the code base, which module does what, how do the modules interact and so on. This is NOT a technical description of HOW things work, this is covered in-depth (well, at least will be) in doc/techdoc.pdf.
OpenPCells is based on lua with additions written in C. It reads cell definitions and creates layouts corresponding to these definitions and user-supplied parameters. The main tasks are therefore to provide a user interface for cell definitions (geometrical functions), a translation from technology-independent cells to technology-dependent layouts (the so-called 'technology translation') and an appropriate export matching the requested format (GDS, OASIS, virtuoso, magic, etc.). These three main tasks should also provide easy mechanisms for the user to add her own cell/technology/export definitions.
The main program and entry point from a lua perspective resides in main.lua. The actual interpreter is adapted from the standard lua interpreter in main.c
and loads the API.
Geometry functions for cell definitions. Functions such as path, rectangle but also more specialized routines for IC layouts like crossing. Every function
takes a layer argument (see generics.lua).
This provides graphical routine for the geometry system. These are similar to classical computer graphics functions (e.g. calculating which pixels lie on a curve). Currently provides functions for lines, ellipses and circles. Extensions like bezier curves enable full SVG support for drawing pictures in layouts.
This module provides functions for generating generic layer objects. These are used in cell definitions and are technology-independent (e.g. a generic metal is
used instead of M1). Besides that, the technology module makes heavy use of this module.
Main module for handling cell definitions.
Modules for handling of layout objects. Objects are collections of shapes, which use points (for description of polygons and rectangles).
Module for technology translation. Here all generic layers are mapped to technology-specific layers. Read technology definitions in tech/.
Module for generating output. In export.lua the generic logic is implemented, the actual generator depending on the file format is in export.
aux.lua, stack.lua, stringfile.lua/stringbuffer.c, support.lua, util.lua, Various stuff needed by other modules.util.luaprovides geometry-related helper functions,aux.luageneral ones.stack.luaimplements a stack,stringfile.luatogether withstringbuffer.cprovides an object that behaves like a file but does not write to the filesystem until explicitly called for. support.luais likeaux.lua` and should probably be merged.
Provides helper functions for writing binary files and computing the required data. Written in C for performance reasons.
Provides bind to bind function arguments. Written in C because this is more easily done in C (stack manipulations, registry).
Module for simple filesystem queries (like lua-filesystem, but without the dependency).
config.lua, envlib.lua
Provides configuration for the user and other modules.
Rudimentary profiler, which is off by default (option --profile). Cell generation can take a while for big (-ish unfortunately) cells. The profiler helps
finding bottlenecks.
Provides _load_module, a fancy require. Used to load the API and submodules within modules.
Simple argument parser for command line options as well as the definition of these options.
This project aims for zero dependencies and easy installation for users without admin privileges. Because of this, some modules implement
functionality, that can be easily found in other libraries (lua-penlight for argument parsing, for instance). The only dependency needed is a C compiler and
make for building.