Software Engineering of the PREDITOR Process Editor and Statistical Simulator

1. Outline • The Past • The Present: PREDITOR • PREDITOR Organization • PREDITOR Example • Software Engineering in PREDITOR • Little Layout Editor (LILY) • Canvas Experiments • LILY Implementation Software Engineering of thePREDITOR Process Editorand Statistical Simulator Hank Walker

2. 1978 - FABRICS 0 (Maly, Strojwas) • FORTRAN, batch, bipolar only 1980 - FABRICS I (Nassif, Strojwas, Director) • FORTRAN, DEC-10, DEC-20, 1-D process, 2-D device models for MOS and bipolar process, interactive user interface 1981 - FABRICS I.X (Nassif, Strojwas, Director) • Pascal, DEC-20, HP9836, MOS and bipolar, DEC-20, HP9836 1983 - FABRICS II (Nassif, Strojwas, Director) • C, UNIX, process supervisor concept, device structure - library of analytical 1-D process models, 2-D device models • "wafer representation" just bunch of variables - geometry fixed at compile time The Past

3. 1986 - Process Engineer's Workbench (Low, Kager, Strojwas, Director) • Process Editor (PED) specifies artwork and process flow - library of analytical 1-D process and 2-D device models • Process Interpreter and Compiler (PI/C) simulates process - 3-D wafer representation - bag of rectangles • PI/C generates C code for FABRICS process supervisor - interpreted flow too slow for statistical simulation - tended to break C compilers 1985 - Prometheus (Spanos) • nonlinear optimization • tune FABRICS to process disturbances • optimize process/device parameters The Past

4. Process Engineer's Workbench

5. Old PEW/FABRICS Capabilities • interactive process/device specification/simulation • statistical process/device simulation with analytical models • library of simulation steps New Capabilities • general 3-D wafer representation - mixture of geometry and field representations - flexibility for new applications - extraction, yield simulation - lower model development, integration overhead • interpreted statistical simulation - no more compilation • modular system organization • new models - 2-D seminumerical device model, Poisson solver - partial SAMPLE, SUPREM-IV links • new functions: sensitivity analysis, general layouts The Present: PREDITOR

6. PREDITOR Organization

7. Core simulator and database surrounded by interface programs • communication primarily via files Use engine for batch-mode simulation, optimization LLE, Forms/Menus still integrated, GKS-based, not separate programs PREDITOR3 Implementation

8. Chip is composed of layers and fields • chip divided into corner-stitched regions at direction of simulation models • regions contain a list of layers and fields (layer stack) • layers contain layer model (surface shape) and attributes • attributes include doping profiles, material type, surface shape, etc. Chip Database

9. PREDITOR Example Monte Carlo Simulation Results Id vs. Gate Oxide Id vs. Poly Length

10. Large System • 250K lines of C in 1500 modules, 2MB binary • parts date to 1982 - generations of students and programmers Evolution from Process Engineer's Workbench (PEW) • reuse as much PEW code as possible • focus new work on CDB, model integration • experiment with new system • evolve to PREDITOR2, PREDITOR3, PREDITOR4,… • commercialization as pdFab from PDF Solutions, Inc. Project Organization • chief programmer - six years experience on PREDITOR, PEW • one assistant programmer - component development • students hand over new models for integration Software Engineering in PREDITOR

11. System Evolution • PREDITOR1 - PEW interface and models integrated with CDB • PREDITOR2 - xgraph, xmdraw user interfaces, pdFab V1.0 • PREDITOR3 - SUPREM-III, virtual grid, pdFab V2.0 • PREDITOR4 - server mode, Tcl interface, LILY - never completed, became later versions of pdFab Tool Usage • cc, dbx, lint,... • no rapid prototyping tools • no GUI builder • heavy software reuse • standard project libraries - math, GKS, SIN, C Programmer's Toolbox,... • no CodeCenter/ObjectCenter - problems with large programs Software Engineering in PREDITOR

12. Goals • specify/view transistor, inverter, small cell mask artwork - <= ~1000 polygons • specify points and cutlines for simulation and visualization • read/write CIF and maybe Calma layout files • handle polygons • painting, not object paradigm • communicate with rest of system via messages • not a full-blown layout editor History • PED layout editor from PEW - GKS-based - gridless colored box outlines - part of monolithic GUI Little Layout Editor (LILY)

13. PED Layout Editor

14. Construct with Tk/Tcl widgets • flexible, can change look-and-feel • fast enough for buttons, mouse operations • convenient communication mechanism • fits in with intended use of Tcl as PREDITOR extension language • canvas widget provides rectangles, polygons, lines, bitmaps, text,... Concerns • canvas is object, not paint oriented • too slow on 1000 items? - all operations use item linked list - while operating on DECstation 3100 - ~ 3 MIPS machine • no polygon outlines • order of display - opaque objects • no translucent colors LILY Implementation

15. Is the canvas fast enough? • modify mkScroll.tcl in widget demo • 100x100 array of diamond polygons Results • startup 30 sec, 3 MB memory • scroll speed okay • select/deselect is 0.5 sec! - dominated by linear item search • but 1000 items is 10X faster => interactive • compile -O instead of -g for 2-3X speedup Conclusions • canvas is fast enough for ~1000 items • modify to use quadtree, etc., for 10,000 items - lot of work Canvas Experiments

16. Can we have acceptable item colors? • do we need polygon outlines? • play with canvas in widget demo • stipples are user-defined, have colors, transparent • use order of mask layers in item list to control visibility - each item can have a tag, e.g. layer name - items are drawn in list order • can hide layers by making items transparent • no translucent colors via X color map tricks Conclusion • can use stippled colored polygons for now • maybe modify canvas to add polygon outlines later • translucent colors require major rewrite, corner-stitched database Canvas Experiments

17. Can we easily implement painting? • coalesce polygons that touch • erase polygon regions under eraser • perform boolean polygon operations - union new polygon with nearby ones - subtract eraser from nearby polygons - use VLASIC polygon package • useful canvas item functions - find nearby item - exec command on event sequence Conclusion • painting not too hard to implement • will run fast enough Canvas Experiments

18. CIF - Caltech Intermediate Form • hierarchical mask artwork format • symbols, boxes, wires, polygons, labels,... How to read CIF into LILY? • new Tcl parser? No, a major undertaking • use existing CMU C parser - user supplies callbacks, e.g. outputpolygon - will flatten and sort geometry • write C callbacks to issue canvas Tcl commands - outputpolygon(layer, path) calls $c create polygon x1 y1 ...xn yn -fill $layercolor -tags $layer - optional Tcl callback layer for look-and-feel decisions • link callbacks with CIF parser and rest of LILY (canvas,...) • CIF parser uses same LILY interface as rest of code LILY CIF Interface Canvas Tcl Tcl Tcl Callbacks Tcl C Callbacks C Calls CIF Parser CIF

19. Code • Wish • polygon package • CIF parser • C callbacks Tk/Tcl command file • optional Tcl callbacks • GUI organization, behavior • link to PREDITOR Tcl LILY Implementation Drawing Tools Menu Bar Layers Canvas Scroll Bars Zoom