1

Open Accessfor an Open

Custom Design Platform

Scott ChaseOctober 13, 2008

2

Open Access for an Open Custom Design PlatformOverview

• Introduction to Custom Designer• Brief History• Platform Overview • Complete & Comprehensive Solution• Our OpenAccess Experience

• Openness and Interoperability on OA• Dimensions of openness – what makes an Open Platform?• The IPL Initiative• Enabling Extensibility

• Consistent Usage • Front End Challenges• Schematic Driven Layout • Schematic Connectivity

3

Custom DesignerAn Open OA-based Custom Design Platform

• Architected for productivity

• Complete custom design solution

• Open environment

Galaxy Implementation Platform

Prim

eTim

ePr

imeT

ime

HSP

ICE

HSP

ICE

Design CompilerDesign Compiler

IC CompilerIC Compiler

Custom DesignerSE

Custom DesignerSE

Custom DesignerLE

Custom DesignerLE

Hercules / Star-RCXTHercules / Star-RCXT

• Production Release announced Sept 22, 2008 at BSNUG• Demo this evening

4

Layout EditorProductivity Enhancers• Push button DRC and Extract• Standard TCL & Python P-Cells• Auto via & guardring generation

5

Schematic EditorProductivity Enhancers• Real-time connectivity• On-canvas editing• Smart connect

6

Complete & Comprehensive Solution

• Unified environment

• Familiar look and feel

• Full custom chip and block authoring flows

HSPICE

WaveViewAnalyzer

Cadabra

Hercules

Star-RCXT

NanoSimHSIM

Custom Designer

7

Complete & Comprehensive SolutionWaveView Analyzer

• Highest capacity and performance

• Complex analysis toolbox

• Automated TCL verification scripting

8

Open & PortablePlug & Play IP

Pcells based on Python and TCL

OpenAccess based designs

set libName generic90RFset cellName n_4tset oaLib [oa::LibFind $libName]oa::getAccess $oaLib write 1set oaCell [oa::CellFind $oaLib $cellName]set accessMode "w"set dmData [oa::DMDataOpen $oaCell $accessMode]

db::setNetlistInfo fieldHeight -cell $dmData -section form \-value 15 \-type integer

TCL based script language

9

Custom DesignerAn Open OA-based Custom Design Platform

•Primary Editors: LE, SE, Symbol editors

• Supporting Tools:

Library Manager, Hierarchy Editor, Display Resource Editor, Job Monitor, Programmable Netlister, etc.

• Dockable Assistants:

Property Editor, Hierarchy Navigator, Marker Browser, Device Label Editor, Probe Assistant, Transaction History, Object LayerPanel, Schematic Object Filter, etc.

10

Undo/Redo per-design

Interact with your edit list graphically using the Transaction History Dockable Assistant

Transaction History Dockable Assistant

11

R&D Perspective on using OAGood:

• “Clean” data model and class hierarchy• Outstanding documentation• oaDebug and oaDiff• Forums• Bug Tracker• Contributions (“freeware” rocks!) • Community

Bottom line: it was easy to get up and running; we do still need a small dedicated OA team for bug fixes, build management and support of application developers. But we can put more of our effort into the value-added features and differentiators that make our products more useful to our customers.

This project was easier on OpenAccess.

Less Good:

• Release management• Performance limitations• Feature adds (getting more and more important as we look forward)

12

Open Access for an Open Custom Design PlatformOverview

• Introduction to Custom Designer• Brief History• Platform Overview• Complete & Comprehensive Solution• Our OpenAccess Experience

• Openness and Interoperability on OA• Dimensions of openness – what makes an Open Platform?• The IPL Initiative• Enabling Extensibility

• Consistent Usage • Front End Challenges• Schematic Driven Layout • Schematic Connectivity

13

Custom DesignerAn Open OA-based Custom Design Platform*

Major EDA Platforms for custom design have been closed in 4 key ways:

• Proprietary Database• Proprietary Libraries• Scripting languages the only way to extend• Proprietary UIs

That is changing. With Custom Designer:

• Design Database is Open Access DM4• Support for IPL’s iPDK, including PyCells• Scripting interface is Tcl, including oaTcl• GUI Toolkit is Qt 4.x

• Customize the platform through standard interfaces, or just dynamically link in your own stuff with Tcl’s ‘load’ command.

* Why Platform and not collection?

14

• OpenAccess is an enabler and set the stage– Provides access to core design data

• Shapes, instances, connectivity, technology– Being adopted by key vendors in several areas

• Synopsys, Mentor, Silicon Canvas, Cadence & Magma• BUT:

– Leaves a lot to semantic interpretation– Doesn’t include guidance for how to interpret and

interoperate certain key data• Parameters

– Definition– Expression languages– Parameter passing

• Interpreted labels• Constraints

Proprietary Database

15

OpenAccess

Zoomed in schematic:

•Pins / terminals•Interconnect

•Paths•Lines•Dots (ellipses)

•Instances•Parameters•Interpreted labels

16

• Notice the number of parameters and interpreted labels?– More parameters and labels on a device than shapes on the

symbol– 80+ parameters on current technology node transistor– Without the parameters, a schematic is useless

• We have been driving IPL– Not only for common pCells– Common interpreted labels– Common parameter definitions– Common parameter expression language

• The result, at DAC 2008:– Synopsys Custom Designer– Silicon Canvas Laker– Mentor Calibre

OpenAccess

17

The Result: One Design. One PDK. Same Result in Two Tools

©2008

18

The Result: One Design. One PDK. Same Result in Two Tools

©2008 IPLN

19

• Most platforms allow access via a scripting language– Tcl– SKILL– All low performance– Try writing a DRC check for real time use– Try writing an editor– They’re simply too slow

• OpenAccess provides a C++ high performance API– Can be used to access the same design data– At the performance needed for complex tools

• Routers• DRC engines for proprietary rules

Scripting Languages: The only way to extend?

20

• Synopsys Custom Designer– Allows you to create Tcl scripts– Load shared objects– And write truly high performance applications

• Written natively in OpenAccess C++• Portable

– Separate binaries in other tools– Loaded directly into our platform!

Scripting Languages: The only way to extend?

21

• Traditionally GUI access is restricted to– Proprietary technology– Limited scripting capabilities– Or a separate process

• Synopsys Custom Designer also enables– Via a Tcl based scripting– Opal

• What if you wanted to build this?

Proprietary UIs?

22

Complex GUI

23

• Don’t try doing that in a vendors proprietary language

• It’s natively written in C++/Qt• With an ability to load C++ shared objects

– You can create GUIs like this– And load them into a full platform like Custom

Designer

Proprietary UIs

24

• Interoperability is becoming a reality

– First design data via OpenAccess– Second consistent usage within OpenAccess– Common FTKs/PDKs via IPL

• Going forward:

– OA based apps you develop loaded into any platform– Non-platform specific GUIs– Enabled now in Custom Designer– More is need for real industry-wide interoperability

Summary

25

Open Access for an Open Custom Design PlatformOverview

• Introduction to Custom Designer• Brief History• Platform Overview• Complete & Comprehensive Solution• Our OpenAccess Experience

• Openness and Interoperability on OA• Dimensions of openness – what makes an Open Platform?• The IPL Initiative• Enabling Extensibility

• Consistent Usage • Front End Challenges• Schematic Driven Layout • Schematic Connectivity

26

Consistent Usage• We believe the goal of OpenAccess is interoperability

– For layout OpenAccess is a giant step forward– For front end design and layout creation interoperability is very difficult

• Most data can be inconsistently interpreted by users of OA– Stored as appDefs– Stored as properties– Storage not defined– No guidance on semantic interpretation

• This includes– Parameters / expressions / design variables– Constraints– Geometry connectivity correlation– Interpreted label expressions– Hierarchy definition

27

Consistent Usage• Without these front end / design tools can NOT interoperate

– Schematic viewers / editors– Netlisters– Simulation integrations– Sizing / optimization tools– Schematic driven layout– Layout generators– LVS

• All we really have for interoperability is consistent reading of layouts

– Even layout editors can’t really interoperate without • Common constraints• Common, and complete, rule specification• ECO tracking

28

Schematic Driven Layout• Manual: The layout designer “looks” at interpreted schematic in

context and creates matching schematic• SDL tool: Basic layout is created

– Correct device sizes– Honoring constraints for placement– Connectivity– All based on defined hierarchy (configurations) of schematics

• Remember, in a schematic you don’t usually place a schematic• There are frequently multiple “views” for each cell

– Designer connects devices based on “flight lines”• Layout generation: Same as above adding a router & compactor

– Also follows constraints

• ALL layout creation methodologies require consistent interpretation of schematics

29

Schematic Connectivity• What subset of oaLines, oaPaths or other oaFigs represent valid

wires? • How do we interpret the connectivity of wires based on their

geometries, abutments and intersections?• In schematics which of these sets of wires are connected?• Without knowing, how can I write an editor or schematic

generator who’s output can be modified by another vendor?

30

Summary• Is the goal of OpenAccess to:

• Use tools/components from multiple vendors?• Add your tool/component to a vendors flow?• Ex: Schematic editor, schematic generator, circuit optimizer, layout

placer, schematic p2p router, netlister, layout generator…• How can you interoperate without:

• Parameters / expressions / design variables?• Constraints?• Geometry / connectivity correlation?• Visualization / labels?• Hierarchy configuration?

• Without these• OA is a good database• It does not provide interoperability

• What do we need to do organizationally to move forward?

31

Schematic Driven Layout• Irrespective of methodology, tools need consistent

interpretation:• Schematic connectivity

• Generate the flattened connectivity across hierarchy• Hierarchy definition• Parameterized connections• Cross hierarchy pin correlation and mapping

• Resolved parameters and their expressions• Including across hierarchy• PCell generation• Simply for static device sizing

• Constraints for layout generation• Design rules are at least partly covered by constraints in the oaTech. • What about placement and routing constraints?

• Placement: Hard groups, matched pairs and other symmetry rules, etc. • Routing: buses, shielding, wire-length constraints, etc.

32

Thank you!

Want to talk more? Find me at the IPL and Custom Designer demosthis evening.

33

The Following are Supplemental Slides on Consistent Usage

34

Overview of Design Flow

• Typical analog/custom design flow: • Schematic Capture / Topology creation• Netlist / Simulation• Device sizing / Optimization• Layout creation

• Manual (looking at schematic)• Schematic-Driven Layout• Layout generators

• LVS

35

Schematic Capture / Topology Creation

Zoomed in schematic:

•Pins / terminals•Instances

•Parameters•Interpreted labels

•Interconnect•Paths•Lines•Dots (ellipses)•Wire labels

36

Schematic Capture / Topology Creation

• Parameters:– Note proliferation of parameters on MOS device

• More parameters than connections, most not even shown– Parameters are as important as the interconnect

• Without them, there are no device sizes (width, length, fingers,multiplier…)

• Designers want to specify defaults on the library and cell level– Where should they put them?

• Designers need expressions to represent values:– W=parent(nw) * 1.1

» Or worse– W=parent(nw) * scale

» Note: Here “scale” is a variable that can be swept in simulation– What is the expression language?

• How do I put a label on the symbol so all tools display result consistently?

37

Schematic Connectivity

• How are connection definitions, assignments and global nets interpreted?• If a pin has a connection definition

• And a wire intersects it• Does the net derive it’s name from the connectDef?• Does the net name over-ride the connectDef?

• If the wire has a label?• If it doesn’t?

• Does a global net with the same name as a connect def default become parameterized?

• Without knowing the above, how can I write a connectivity extractor or editor?

38

Schematic Driven Layout

39

Schematic Driven Layout• Irrespective of methodology, tools need consistent

interpretation:• Schematic connectivity

• Generate the flattened connectivity across hierarchy• Hierarchy definition• Parameterized connections• Cross hierarchy pin correlation and mapping

• Resolved parameters and their expressions• Including across hierarchy• PCell generation• Simply for static device sizing

• Constraints for layout generation• Design rules are at least partly covered by constraints in the oaTech. • What about placement and routing constraints?

• Placement: Hard groups, matched pairs and other symmetry rules, etc. • Routing: buses, shielding, wire-length constraints, etc.

40

Netlisting and Simulation

• To simulate you need to interpret the schematic hierarchy similar to layout generation

• How are terminals mapped across libraries?• What is the parameter expression language?• Where / how are parameters stored?• What is the inheritance and scoping precedence for parameters?

• Netlisting for different purposes or different simulators requires different hierarchy bindings

• How is this specified in OA?