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