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:
2) Analog Constraints
– Reduce development costs for library development
– Standardize to be efficient
-ST, Xilinx, Dongbu
– June 2011: IPL Constraint 1.0 Available
– 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
– 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
– Placement with one tool, routing with another tool
– If I make a constraint how do I know that it is legal or valid?
– Future expansion built in
– 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
– 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
– At 65nm we see 16% LDE impact, 40nm a 22% LDE impact, at 28nm 28% LDE impacts
– Cause much simulation and iterations to converge
– 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
– Device costs
– Parasitic costs
– Power costs
– Device matching
– Parasitic matching
– Power matching
– 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
– 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?
– Automation of an iPDK generator
– Interoperable PDK validation
– IPL Adopter Kit
Ofer Tamer – CAD Director at ToawerJazz
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: 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
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”.