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 top down behavioural description and overoptimization, which leads to f larger source, and thus we have a f positive feedback system Claims f Minimal source leads to fast design Fewer keystrokes -> less to debug f Early design evaluation required Technology constraints affect requirements 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 mixed text and graphics f Register Transfer Level Design Technology constraints affect requirements Intended behaviour defined by what is possible f System Simulation You can't get it right the first time so make it easy to go around the loop f Layout Consistent with automatic synthesis capabilities Behavioral Models DRamSimple: EvalProc = { SELECT state FROM PowerUp => SELECT TRUE FROM nRAS AND nCAS => state := Idle; ENDCASE => NULL; Idle => SELECT TRUE FROM nRAS AND nCAS => NULL; nRAS AND CAS => state := RefreshStart; RAS AND nCAS => { rowAddress := Add; state := AccessOrExternalRefresh; }; ENDCASE => ERROR; RefreshStart => SELECT TRUE FROM nRAS AND CAS => NULL; RAS AND CAS => state := InternalRefresh; ENDCASE => ERROR; InternalRefresh => SELECT ctl FROM nRAS AND nCAS=> state := Idle; nRAS AND CAS=> state := RefreshDoneRAS; RAS AND nCAS => state := RefreshDoneCAS; RAS AND CAS => NULL; ENDCASE => ERROR; RefreshDoneRAS => SELECT ctl FROM nRAS AND nCAS=> state := Idle; nRAS AND CAS => state := RefreshDoneRAS; ENDCASE => ERROR; RefreshDoneCAS => SELECT ctl FROM nRAS AND nCAS => state := Idle; RAS AND nCAS => state := RefreshDoneCAS; ENDCASE => ERROR; ENDCASE => ERROR; }; 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 Κn–"anacapaslides" style–99999 firstVisibleFolio˜Iunleaded•Mark insideFooteršΡdis˜K– outsideFooterš ˜ title˜Iragged˜M˜•CharSetsο šΟb ˜ M˜$M˜—–οšž˜M˜#M˜M˜—–οšž˜M˜—–οšž˜M˜——šž ˜ Icenter˜N˜Nšž$˜$M˜M˜–ο$šž%˜%Mšœ ˜ M˜M˜ M˜—–ο/šž0˜0M˜—–ο.šž/˜/M˜——˜ M˜–ο šž ˜ M˜&M˜—–ο šž ˜ M˜M˜.M˜M–οšžœ˜M–ο1šžœ1˜2M–οšžœ˜M–οšžœ˜——˜M˜–ο šž ˜ M˜M˜M˜—–ο šž ˜ M–οIšžœI˜JM–ο$šžœ$˜%M–οšžœ˜——˜M˜–ο$šž%˜%MšœΟmœ ˜%M˜—–ο!šž"˜"Mšœ*˜*MšœΟiœ˜.M˜—–ο+šž,˜,MšœK˜KM˜—–ο(šž)˜)M˜0M˜—–ο4šž5˜5M˜N——˜ M˜–οšž˜M˜M˜—–οšž ˜ Mšœ*˜*Mšœ œ˜.M˜—–οšž˜MšœK˜KM˜—–οšž˜M˜0M˜——˜M˜codešΟn œ˜šΟkœ’˜šœ ’œ’œ’˜Jšœ’œ˜Jš’œ’œ˜J˜—šœ’œ’œ’˜Jšœ’œ’œ˜Jšœ’œ˜&šœ’œ ˜Jšœ˜Jšœ!˜!J˜—Jš’œ’œ˜J˜—šœ’œ’œ’˜ Jšœ’œ’œ˜Jšœ’œ ˜(Jš’œ’œ˜J˜—šœ’œ’˜"Jšœ’œ˜Jšœ’œ˜'Jšœ’œ ˜(Jšœ’œ’œ˜Jš’œ’œ˜J˜—šœ’œ’˜!Jšœ’œ˜Jšœ’œ˜(Jš’œ’œ˜J˜—šœ’œ’˜!Jšœ’œ˜Jšœ’œ ˜(Jš’œ’œ˜J˜—Oš’œ’œ˜—Ošœ˜O˜——˜ M˜–ο#šž$˜$Mšœ˜M˜$M˜"M˜—–ο)šž*˜*Mšœ˜M˜—–οšž˜Mšœ˜M˜+M˜—–οšž˜M˜M˜—L˜ M˜–ο-šž.˜.M˜—–ο+šž,˜,M˜ M˜-M˜0M˜—–ο/šž0˜0M˜ M˜M˜—–οšž˜M˜M˜M˜——˜ M˜–ο)šž*˜*M˜M˜ M˜—–οšž˜M˜+M˜ M˜—–οšž ˜ M˜/M˜+M˜—–ο)šž*˜*M˜(M˜——šœ ˜ M˜–ο šž ˜ Mšœ*˜*M˜—–ο šž ˜ Mšœ)˜)M˜—–οšž˜Mšœ?˜?M˜M˜ M˜———…—ώr