iPDKs and Analog Constraints

Lunch time Monday at DAC and I learned about what’s new at the IPL Alliance in 2011.

IPL Sponsors: Magma, Mentor Graphics, Springsoft, Accelicon, Ciranova, Synopsys, TSMC, TowerJazz, Jedat, Tanner EDA

Two major projects:
1) iPDKS
2) Analog Constraints

To:
– Reduce development costs for library development
– Standardize to be efficient

New Members:
-ST, Xilinx, Dongbu

Momentum
– June 2011: IPL Constraint 1.0 Available

IPL 1.0
– Comes with a 90nm reference iPDK

IPL Constraint 1.0
– New emerging standard for Constraints

Rich Morris – Marketing Manager at SpringSoft, Chairman of Constraint Working Group at IPL Alliance
– IPL Constraing 1.0 Standard (single unified set of interoperable constraints)
– Active members: Altera, Ciranova, Pulsic, SpringSOft, Synopsys, TSMC
– Constraints: Design Rules (what not to do)
– PDKs have lots of constraints
– OA has 145 foundry constraints
– IPL is focused on design constraints, not foundry constraints, typically analog and custom design

What type of constraints?
– Communication between schematic entry design and IC layout implementation
– Enter constraints once for entire tool chain, not multiple times
– Today: Constraints for Placement, Routing, Layout editing (All different)
– Open Access: consistent way to store constraints for all design tools
– Text-based constraints can synch with the OA DB

Charter
– Define the syntax and schema for open, interoperable design constraints
– Create a single unified set of constraints
– Start with a proof of concept constraint set
– Ask for donations from real users to maximize coverage

Interoperability
– Placement with one tool, routing with another tool

Validation
– If I make a constraint how do I know that it is legal or valid?

Extensibility
– Future expansion built in

Constraints
– Routing: wire width, wire space, preferred direction, net matching
– Placement: Group symmetry, group alignment, …

Publication of Constraints Standard – Coming next

Design Constraint Standard
– using YAML (easy to parse, human readable, open source)

IPL Constraints 2.0
– Planned for end of 2011
– General release in 2012

Steven Chen – Deputy Director at TSMC

TSMC AMS Reference Flow 2.0 & Design Constraint

History
– 2006: 65nm, Cadence PDK
– 2007: Porting PDK tool by tool
– 2008: Demo TSMC iPDK concept
– 2009 65nm iPDK
– 2010: 28nm iPDK, 40nm, 65nm, 90nm, 130nm, 180nm

AMS Reference Flow 1.0
– An interoperable AMS design flow
AMS Reference Flow 2.0
– DFM and RDR compliance defined
– Design iteration and cycle-time reductions
o Predict and optimize layout style to LDE, RC and IR
– Design for Reliability
o Flag issues early before tapeout
o Layout based, simulation based DFR flows
– EDA tool flow integration of 28nm HP and HPM nodes

AMS Challenges
– At 65nm we see 16% LDE impact, 40nm a 22% LDE impact, at 28nm 28% LDE impacts
– Cause much simulation and iterations to converge

AMS Flow
– Constraint driven physical effects (LDE, RC) aware flow defined
– Pre-layout: LDE budgeting, custom wire load emulation
– Covers: Schematic Driven Layout, Analog P&R

Electric Design Constraints
– Device: Idsat self-degradation
– Parasitic
– Power
– Device costs
– Parasitic costs
– Power costs
– Device matching
– Parasitic matching
– Power matching

Pre-layout flow
– Use the TSMC iPDK
– LDE budgeting (pass constraints to each layout tool, RC extractor)
– Custom wireload estimation
– An LDE API is provided by TSMC
– RC Extraction API: Between extraction tool and layout editor
– TSMC provides an LDE constraint checker

Demo Case Study
– Old way versus new way showed a reduction in pre/post layout simulations.

Vincent Varo – ST Micro, iPDK and Open PDK

– Common objectives
– ST wants standardization to reduce design and support costs
– Open PDK goal is a single PDK generation flow
– iPDK will enable a single PDK
– Both concepts (iPDK, Open PDK) are complementary efforts

PDK ecosystem today
– Each foundry starts with a PDK
– PDK development team (Device libraries, DRC, LVS, SPICE, PEX)
– Too many versions of PDKs creating a large support efforts

PDK ecosystem goal
– Foundry creates and electronic document with both DRM and device specifications
– A PDK generator creates an automated techfile

Si2
– Is creating an Open PDK Standard (OPS) XML file
o Has: Process, libraries, devices, layers, rules
– A Standardized High level EDA tools tech file
o Goes into a PDK Translator
o EDA tools could read the high level tech file directly

New IPL Working Group – connecting Open and Interoperable groups

How do you validate a PDK?

Next steps
– Automation of an iPDK generator
– Interoperable PDK validation
– IPL Adopter Kit

Ofer Tamer – CAD Director at ToawerJazz

iPDK Advantages

Who is TowerJazz?
– Specialty foundry. RF. Image Sensor. Power management. MEMS.
– Processes: .50um to .13um, all AMS

Multi-vendor flows: Cadence, Synopsys, Mentor, Magma, SpringSoft
– Use CiraNova tools for library development
– iPDK tools: Synopsys Custom Designer, Magma Titan, Mentor IC Station, SpringSoft Laker
– Allows PDF development to use a single methodology, not specific to any one EDA vendor format
– PyCells used to create Pcells

TowerJazz AMS Reference Flow
– Live demo today showing Synopsys Custom Designer tools
– Same flow to show tools for: Cadence, Magma, Mentor, Ciranova

Q&A

Q: IPL is based on OA from Cadence, but where is Cadence support today?
A: TSMC – That’s a tough question. Cadence has been invited to be part of IPL. TSMC has used IPL libraries in Cadence tools just fine. Customers are the drivers to change the mind of Cadence to support and join IPL.

A: TowerJazz does two PDKs: Cadence, IPL. Doubles their development efforts.

A: ST – Develops two PDKs: Cadence, IPL. Want to support just IPL.

Q: What’s the next development from IPL?
A: We’re limited in resources, depend on member resources. Enhance Constraint 1.0 for public release at next DAC.

Q: What about an interoperable Simulation language?
A: Synopsys – we take input from IPL members to sponsor a working group.

Q: Twitter Question.
A: IPL stands for Interoperable PDK Libraries

Summary
Cadence continues to promote only their Skill-based PDK while the rest of the industry is adopting iPDK and Open PDK. The message from the speakers today was loud and clear, “Ask your EDA vendors and Foundries to support iPDK”.