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