OrganizationInstructor: Adnan Aziz ACE 6.120 Email:adnan AT ece utexas edu Web:www.ece.utexas.edu/~adnan GPS: Longitude 30.287253, Latitude -97.736832

Office Hours: MW, 10:00am 11:00am

kuehl@eecs.berkeley.edu

GradingHomework (~ 8 homeworks):purpose is to solidify material and make you think deeper about conceptsteam work allowed, but each problem solution should be stated in your own wordsMidterms 1 after first half1 after 75%Course project: will start about halfway through coursefinal report (like conference paper)GraderTBDWebsite: http://www.ece.utexas/edu/~adnan/syn-07

kuehl@eecs.berkeley.edu

Homework

About two-thirds writtentheoretical problems hand calculations

One third programming assignments:to be written in C in SIS environmentassignment is typically:write some application (e.g., build a particular circuit representation)run some benchmarks on itcode and results (e.g. table of statistics) is to be turned in as .tar file in to grader

kuehl@eecs.berkeley.edu

Design of Integrated SystemsDesignVerification

kuehl@eecs.berkeley.edu

System LevelAbstract algorithmic description of high-level behaviore.g. C-Programming language

abstract because it does not contain any implementation details for timing or dataefficient to get a compact execution model as first design draftdifficult to maintain throughout project because no link to implementation

Port*compute_optimal_route_for_packet(Packet_t *packet, Channel_t *channel){ static Queue_t *packet_queue;

packet_queue = add_packet(packet_queue, packet); ...}

kuehl@eecs.berkeley.edu

RTL LevelCycle accurate model close to the hardware implementationbit-vector data types and operations as abstraction from bit-level implementationsequential constructs (e.g. if - then - else, while loops) to support modeling of complex control flow

module mark1;reg [31:0] m[0:8192];reg [12:0] pc;reg [31:0] acc;reg[15:0] ir;

always begin ir = m[pc]; if(ir[15:13] == 3b000) pc = m[ir[12:0]]; else if (ir[15:13] == 3b010) acc = -m[ir[12:0]]; ... endendmodule

kuehl@eecs.berkeley.edu

Gate LevelModel on finite-state machine levelmodels function in Boolean logic using registers and gatesvarious delay models for gates and wires

in this lecture we will mostly deal with gate level1ns

kuehl@eecs.berkeley.edu

Transistor LevelModel on CMOS transistor leveldepending on application function modeled as resistive switchesused in functional equivalence checkingor full differential equations for circuit simulationused in detailed timing analysis

kuehl@eecs.berkeley.edu

Layout LevelTransistors and wires are laid out as polygons in different technology layers such as diffusion, poly-silicon, metal, etc.

kuehl@eecs.berkeley.edu

Design of Integrated SystemsRelative EffortProject TimeSystemRTLLogic- Design phases overlap to large degrees- Parallel changes on multiple levels, multiple teams- Tight scheduling constraints for productTransistor

kuehl@eecs.berkeley.edu

Design ChallengesSystems are becoming huge, design schedules are getting tighter> 100 Mio gates becoming common for ASICs> 0.4 Mio lines of C-code to describe system behavior> 5 Mio lines of RLT code

Design teams are getting very large for big projectsseveral hundred peopledifferences in skillsconcurrent work on multiple levelsmanagement of design complexity and communication very difficult

Design tools are becoming more complex but still inadequatetypical designer has to run ~50 tools on each componenttools have lots of bugs, interfaces do not line up etc.

kuehl@eecs.berkeley.edu

Design ChallengesDecision about design point very difficultcompromise between performance / costs / time-to-marketdecision has to be made 2-3 years before design finisheddesign points are difficult to predict without actually doing the designscheduling of product cycles

Functional verification simulation still main vehicle for functional verification but inadequate because of size of design spaceresults in bugs in released hardware that is very expensive to recover from (different in software ;-)

kuehl@eecs.berkeley.edu

Design ChallengesFundamental tradeoffs between different modeling levels:modeling detail and team size to maintain modelhigh-level models can be maintained by one or two peopledetailed models need to be partitioned which results in a significant communication overheadmodeling accuracy versus modeling compactnesscompact models omit details and give only crude estimations for implementationdetailed models are lengthy and difficult to adopt for major changes in design pointssimulation speed versus hardware performancehigh-level models can be simulated fast but cannot be implemented efficiently with automatic meanslow-level models can be made to have a fast implementation but cannot be simulated very fast

kuehl@eecs.berkeley.edu

General Design ApproachHow do engineers build a bridge?

Divide and conquer !!!!partition design problem into many sub-problems which are manageabledefine mathematical model for sub-problem and find an algorithmic solutionbeware of model limitations and check them !!!!!!!implement algorithm in individual design tools, define and implement general interfaces between the toolsimplement checking tools for boundary conditionsconcatenate design tools to general design flows which can be managedsee what doesnt work and start over

kuehl@eecs.berkeley.edu

Design AutomationDesign Automation is one of the most advanced areas in practical computer sciencemany problems require sophisticated mathematical modelingmany algorithms are computationally hard and require advanced and fine-tuned heuristics to work on realistic problem sizesboundary conditions need to be well declared and synchronized between different tools (patchwork to cover all wholes)

Two common pitfalls in CAD researchproblem is looking for a solution:problem scope is too big, makes modeling difficult or algorithms dont scaleproblem scope is too small, solutions are not good enoughsolution is looking for a problem:model was oversimplified because real problem was too complex with too many boundary conditions

kuehl@eecs.berkeley.edu

Key to SuccessFine-tuned combination of Design Methodology and Toolsaddresses algorithmic complexity by requiringmanual partitioning of the problemmanual input of hints/suggestionsmanual iterations to drive tool application to best solutionmakes CAD systems and design flows very complex and difficult to manageProblem spaceTools applicablePractical combination through design methodology

kuehl@eecs.berkeley.edu

Examples of Divide and ConquerRLT cycle simulation does only evaluate the next state logic of the circuits, timing is assumed to be correctcombination of static timing analysis, formal equivalence checking, and cycle simulation allows separation of issuescycle simulation avoids expensive event scheduling and processing and performs significantly faster

However:timing analysis is conservative with respect to the achievable clock cycle time

kuehl@eecs.berkeley.edu

Examples of Divide and ConquerStatic timing analysis assumed simple gate delay modelscomplexity of static timing analysis becomes linear (simple longest and shortest paths analysis in circuit implementation)very efficient implementation of incremental static timing analysis which is needed in the inner loop of the technology dependent part of logic synthesis

However:actual gate delay varies a lot in realitymodels often assume average fan-out rather than actual gate loaddelay model assumes ideal signalsslew dependency ignored

kuehl@eecs.berkeley.edu

Examples of Divide and ConquerLogic synthesis assumes ideal gates which are independent of physical environmentstandard cell place and route technology has made logic synthesis possiblegates are heavily over-designed to be functional in a wide variety of combinations (e.g. range of fan-out gates possible, different wire loadslayout placement and route done in standard rows that minimize latch-up effects and optimize power and clock wiring

However:layout implementation remains sub-optimal because cells are designed for worst case application and with large safety margins with respect to environment

kuehl@eecs.berkeley.edu

Examples of Divide and ConquerLogic synthesis uses crude model to estimate circuit arealiteral count or simple table-lookup for gates sizes allows fast comparison of different implementation choices

However:actual gate size can vary to a very large degree depending on load and timing requirementarea for wiring completely ignored

kuehl@eecs.berkeley.edu

Examples of Divide and ConquerFormal equivalence checking assumes identical state encoding of the two designs to be comparedreduces the general equivalence checking problem to combinational equivalence checking which is computationally less complexexploitation of structural similarities between designs to be compared makes tools applicable for huge (multi-million gate) designsautomatic algorithms for identifying register correspondence compensate to some extent for limited model

However:combinational verification model cannot handle sequential verification problems

kuehl@eecs.berkeley.edu

Full Custom Design FlowApplication: ultra-high performance designs general-purpose processors, DSPs, graphic chips, internet routers, games processors etc.Target: very large markets with high profit marginse.g. PC businessComplexity: very complex and labor intenseinvolving large teamshigh up-front investments and relatively high risksRole of Logic Synthesis:limited to components that are not performance critical or that might change late in design cycle (due to designs bugs found late)control logicnon-critical data paths logicbulk of data-path components and fast control logic are manually crafted for optimal performance

kuehl@eecs.berkeley.edu

Full Custom Design FlowIncomplete picture:ISA SpecificationRTL SpecGate Level NetlistTransistor Level CircuitLayoutCircuit SimulationSimulationDesign Rule CheckerFormalEquivalenceCheckingSimulationLogic SynthesisManual or semi-automaticDesignExtract&Compare

kuehl@eecs.berkeley.edu

ASIC Design FlowApplication: general IC marketperipheral chips in PCs, toys, handheld devices etc.Target: small to medium markets, tight design schedulese.g. consumer electronicsComplexity of design: standard design style, quite predictablestandard flows, standard off-the-shelf toolsRole of Logic Synthesis:used on large fraction of design except for special blocks such as RAMs, ROMs, analog components

kuehl@eecs.berkeley.edu

ASIC Design FlowIncomplete picture:Informal SpecificationRTL SpecGate Level NetlistModifies Gate Level NetlistStatic Timing AnalysisFormalEquivalenceCheckingSimulationLogic SynthesisManual Changesto fix timing ASIC FoundryTest Logic Insertion

kuehl@eecs.berkeley.edu

What is Logic Synthesis?DXYGiven:Finite-State Machine F(X,Y,Z, , ) where:X: Input alphabetY: Output alphabetZ: Set of internal states : X x Z Z (next state function) : X x Z Y (output function)Target:Circuit C(G, W) where:

G: set of circuit components g {Boolean gates, flip-flops, etc}W: set of wires connecting G

kuehl@eecs.berkeley.edu

Objective Function for SynthesisMinimize areain terms of literal count, cell count, register count, etc.Minimize powerin terms of switching activity in individual gates, deactivated circuit blocks, etc.Maximize performancein terms of maximal clock frequency of synchronous systems, throughput for asynchronous systemsAny combination of the abovecombined with different weightsformulated as a constraint problem minimize area for a clock speed > 300MHzMore global objectivesfeedback from layoutactual physical sizes, delays, placement and routing

kuehl@eecs.berkeley.edu

Constraints on SynthesisGiven implementation style:two-level implementation (PLA, CAMs)multi-level logicFPGAs

Given performance requirementsminimal clock speed requirementminimal latency, throughput

Given cell libraryset of cells in standard cell libraryfan-out constraints (maximum number of gates connected to another gate)cell generators

kuehl@eecs.berkeley.edu

Instability of Logic SynthesisExperiment to write out netlist in middle of synthesis run and read back in w/o change

kuehl@eecs.berkeley.edu

Brief History of Logic Synthesis1960s: first work on automatic test pattern generation used for Boolean reasoningD-Algorithm1978: Formal Equivalence checking introduced at IBM in production for designing mainframe computersSAS tool based on the DBA algorithm1979: IBM introduced logic synthesis for gate array based main frame designedLSS, next generation is BooleDozerEnd 1986: Synopsys foundedfirst product remapper between standard cell librarieslater extended to full blown RTL synthesis1990s other synthesis companies enter the markerAmbit, Compass, Synplicity. Magma, Monterey, ...

kuehl@eecs.berkeley.edu

Why learning about Logic Synthesis?Logic synthesis is the core of today's CAD flows for IC and system designcourse covers many algorithms that are used in a broad range of CAD toolsbasis for other optimization techniques, e.g. embedded softwarebasis for functional verification techniques

Most algorithms are computationally hardcovered algorithms and flows are good example for approaching hard algorithmic problemscourse covers theory as well as implementation detailsdemonstrates an engineering approaches based on theoretical solid but also practical solutionsvery few research areas can offer this combination

kuehl@eecs.berkeley.edu

Course OutlineRepresentation of Boolean functions and basic algorithmsBoolean functions, formulas, circuits, cube representations, BDDsefficient data structures and algorithms for manipulation and Boolean reasoning SAT

Functional optimization of combinational circuitstwo-level circuitsQuine McCluskeyEspressomulti-level circuitsalgebraic methodsstructural transformation-based methodstechnology mapping

kuehl@eecs.berkeley.edu

Course OutlineTimingtiming models and timing analysistiming optimization

Functional Optimization of Sequential Circuitsretimingsynchronous versus asynchronous circuitsstate assignment and state minimizationreachability analysisclock skew optimization

Low-power Synthesispower analysislow-power synthesis

kuehl@eecs.berkeley.edu

Course OutlineTestingtesting problem and test modelsautomatic test pattern generation (ATPG)

Verificationformal equivalence checkingverification planning

kuehl@eecs.berkeley.edu