Digital Sandbox Workshop Improving Semi-Custom Flow Outline Sandbox
Total Page:16
File Type:pdf, Size:1020Kb
Outline • Talk about what we accomplished Digital Sandbox Workshop • What to do next year Improving Semi-custom Flow – Flow improvements (Tom) – Design specification and class improvements Summer 2003 (Herm) Sandbox Design Experience Layout from CMU1 Cnode Team Course ¾ Accomplishments • OKI 0.16um ¾ Successfully completed Spring Course using technology NOC/LDPC design ¾ Implemented new ASIC Design Flow • 3 OKI memories ¾ Incorporated OKI 0.16um Library and Memories ¾ Shared server farm ¾ Web Conferencing for “common” lectures • Tool: Silcon ¾ Web-based Design Reviews Ensemble Layout from PSU Team SDX Class ASIC Design Flow Foundry Sandbox or Open/Free EDA Vendor Tools • OKI 0.16um technology Project Spec HDL Simulation NOC / LDPC (ModelSim, •5 OKI Verilog) memories RTL Lab Web CVS used Vendor Synthesis Synthesis Lab (Synopsys) • Tool: SE Library Info (OKI Semiconductor) Using Synopsys Place & Route Floorplaning Lab (Cadence) for Silcon Ensemble including STA Timing Analysis (PrimeTime) 1 Cadence Experience Monterey Experience ¾ Cadence Si Ensemble: ¾ Monterey: ¾ Tool is getting old and becoming less valuable ¾ Less ECO interactive since it cannot effectively handle 0.13um ¾ Modifying critical timing paths is less iterative technology and below ¾ Tcl based tool ¾ Students had difficult time learning/using SE ¾ Can effectively handle 0.13um technology ¾ Ability to change critical timing paths is difficult ¾ Accepts and generates GDSII data and iterative ¾This allows us to feed data back to Vertuoso for Full Custom design Proposed Design Flow What we’re doing to build this • Student building “Best of SDX” in ST 0.13 • Using Monterey for full chip design RTL Generation ST 0.13um, Dolphin / Seascape CMULib18 (Monterey) GDSII LEF .sdf Synthesis (.v’s, .sdf’s) (Synopsys) MTF DEF GDSII, LEF, or MTF data (ST, CMUlib18) STA (PrimeTime) Layout of Bit Node Next Issue: Verification •ST 0.13um • We promoted no formal tool for verification technology – Verilog-based testbench authoring • Cell Area is – Code line coverage 592342 – Use of OVL assertions in Verilog code •Layout tool: • Penn State used Verisity Specman E Dolphin • What tools are out there, results of that experiment 2 Verisity Specman Elite Synopsys Vera ¾ Easy to learn ¾ Next Gen. Constraint solver finds bugs quickly ¾ Constraint-driven test generation ¾ Formal analysis engine ¾ Data and temporal ¾ Supports re-use across projects, geographies, and teams checking ¾ Uses VHDL, Verilog, and SystemC ¾ Functional ¾ Access to OpenVera Verification IP coverage analysis ¾ HW/SW co- verification support ¾ Supports all major Verilog and VHDL simulators ¾ Uses E language Open Vera SystemVerilog ¾ OpenVera is an open hardware language ¾ Seamless tool integration and open distribution of verification • Language structures for assertions IP. ¾ Goal is to establish a hardware verification language (HVL), • Not yet accepted into tools… called OpenVera™, ¾ Easy to learn ¾ Combines the strengths of HDLs, C++ and Java ¾ Additional constructs for functional verification making it ideal for developing testbenches ¾ OpenVera accelerates verification by providing high-level constructs designed for complex SoCs. ¾ Designers create testbenches using OpenVera and EDA vendors create tools that are interoperable. Discussion New Libraries • Functional Verification tools: • Plan to using CMU18Lib – Good tools? • One technology library across the curriculum – Falsely perceived silver bullets? – Full Views • Satisfied with Verisity for Verification Class? –DRC, LVS, etc • Can be fabricated with MOSIS on TSMC 3 Problems/Issues with Libraries SDX Class Improvements • Memory Generators! • How did this class work? – Nobody gives these out –Network-on-Chip – Need: LEF, Liberty – Team organization – Like to have: GDSII (unlikely) • What could have been better? – May enlist undergraduates • What should be the design objective this • IOs / PLLs / Passives year? Requirements for Success Industry Challenges to SoC Design •A Firm Specification of Design • Divide and conquer (hierarchy) – Reduce the atomic problem size • Something that gets students excited – Improve the correspondence of wireload models • A Passionate “Consumer” – Allow multiple teams to work independently – Reduce time to market – PipeRench was successful •Design Re-use – picoJava was not • Decoupling of efforts – I think LDPC on NoC was successful – Specified Interfaces – Clear Match of Responsibilities and teams Industry < Education Network on a Chip Design • Design Productivity is in crisis • Hot and Hip Topic in Industry – Issues are even worse in academia • Great for education • Semester less than product design cycle – Highly decoupled design – Reality: less than a semester – Structured interfaces – Reality: less than full-time – If some team blows it off, still can evaluate others • Divide and conquer is even more important • Good results: –Senioritis – Can’t adjust if team doesn’t have right skills – Most teams successfully tested their component – Failure is an option, but we still have to give a grade – Two of four chip designs passed some whole chip test 4 NoC Methodology Spring 2003 • Taught Course at CMU, Pitt and PSU Independent Blocks – Ivan Kourtev (Pitt) P1 P2 P3 composing system – Vijay Narayanan (Penn State) •System spec: LDPC Decoder Forced standard interface – Good fit for NoC Methodology Structured global interconnect P4 P5 P6 – Exciting research topic P7 P8 P9 LDPC on NoC Team Organization • Nicely partitionable • Chip Team (given one spec) • Three distinct –4 Sub-Teams components Bit Check Bit • Each sub-team builds different component – Bit Node • Architecture team simulates, determines system – Check Node performance, and does system verification – Router Node CMU1 CMU2 PITT PSU Check Bit Check Bit Collaborate Check Compete Bit Check Bit Route Arch CMU Results Class Organization • We had one flunky subteam • Right size design teams? – Bad personality mix • Expected enrollment the same? – Two hard workers, two bums • Design review structure? – Their problems didn’t poison the well • Good load balancing – Arch teams worked hard on verification • My best Faculty Course Evaluation ever 5 New Class Design Class Logistics •Re-use NoC Methodology? • Conference Call Phone was not ideal •Could re-use the existing design specs? – Students are not aware of mikes – Cheating? / Novelty? – Repeated questions… repeated answers… • Substantially Modified Spec? – We are planning to upgrade our classroom – Change the network topology? • Other conferencing issues? – Make it substantially bigger? – Make the processors more general purpose? – Ideas from research? • Could attempt to develop a new app in NoC – A lot of effort Class To Do List • Schedules: – Do we have the same issues this year? • Verilog: – Pitt and PSU get VHDL, learning Verilog was hard – Better labs • Planning session in October… 6.