Efficient Structural Design August, 1989 Outline f Methodology Definition and relationship to tools f Good Methodologies Bottom-up and top-down deficiencies Evaluation criteria f A Methodology Illustrated f A Methodology Evaluated What's hot, what's not Methodology Transformation of Idea into Artifact f Each design has its own methodology uncertainties designer environment f Tools available constrain design's methodology f Desired methodology impacts tool requirements Bottom Up f Definition low level gate description + structure f In practice fixed macros frequently useless little early application constraint feedback low level primitives lead to f large source, which is f not easily modified at high level, requiring a f single pass, which leads to f top down methodology Top Down f Definition Multiple levels of abstraction Successive refinement f In practice f each level of abstraction has its own description language, which leads to f larger source, and a f consistency problem Claims f Minimal source leads to fast design Fewer keystrokes -> less to debug f Early design evaluation required Intended behaviour defined by what is possible f Fast turnaround for small changes required You can't get it right the first time so make it easy to go around the loop f High level primitives, but not too high Consistent with automatic synthesis capabilities f All designs will have some structural decomposition What we want to design always outpaces the capabilities of automatic synthesis A Methodology f Specification Ambiguous statement of requirements f Register Transfer Level Design Standard cell output provides initial space and time evaluation f System Simulation Ensure functional requirements are met f Layout Incremental improvement to meet space and time constraints Behavioral Models FFSimple: EvalProc = { SELECT ffClock FROM L => master := ffD; H => slave := master; ENDCASE => slave := master := X; ffQ := slave; ffNQ := NOT slave; }; What's Hot f Minimally redundant design capture less source to prepare & debug no manual maintenance of consistency some redundancy for error checking f Reusable parameterized component library less source to prepare & debug f No behavioural design less source to prepare & debug technology constraints factored into design f Some behavioural modeling invariant checks system environment More Heat f RTL describes logical organization of design f Evolution of RTL into physical description enables incremental optimization eliminates debugging entirely new description make a change, push a button, get a new artifact f Open system enables demand driven tool upgrade Dragon processor -> datapath memory controller -> FSM f Living documents RTL -> physical specification -> data sheet What's Not f Physical schematic loses RTL information data and control are split hierarchical bin sorting problem f Slow system simulation need good compilation, e.g. Verilog, DACAPO emulation f Partially incremental tool set Small changes only require a push of the button but the resulting action takes a long time f Primitives not entirely state of the art Only simple logic synthesis, no Synopsys No sticks layout editing Conclusion f Bottom Up Delays Application Constraint Satisfaction f Top Down Delays Technology Constraint Satisfaction f Evolutionary Structural Simultaneous Application and Technology Constraint Satisfaction Minimal Source Description Minimal Design Time and Manpower