02. Design Methodology

• hughe, partially incomplete and/or inconsistent design specification

  • usually in early project -> has to be resolved in later stages…

• large interdisciplinary developer teams

• numerous interfaces and standards

• partially contradictory design objectives

• find best trade-off

• compromise…

• process to implement desired function

• with a given set of physical components

• improve quality of the product

• reduces

  • cost

  • development time (time to market)

• sequence of individual steps of the design process

  • manual, partially or fully automatic

  • design tools used for

    • synthesis

    • simulation

    • exploration (i.e. investigate design alternatives)

    • verification

    • validation

    • documentation

1. specification

   • of the fuctional behavior

2. exploration

   • of alternative realizations within the design space

3. refinement

   • of the most promising realization towards the next lower abstraction level

• do these steps at each abstractionlevel

• -> e.g.

  • system

  • architecture

  • RTL / Modules

• description of system behavior

• with formal, executable models

• comparison of alternative realizations

• with respect to

  • costr

  • performance

  • robustness

  • …

• synthesis of a structural system representation

• out of the functional specification

• specification/modeling forms basis

• for successive exploration and refinement phases (system synthesis)

• one has to find balance between

• accuracy vs. abstraction

• in system model

=> this balace is key parameter for quality vs. development effort during exploration and refinement

• roots on efficient estimation and simulation techniques

• => allow design charactersitic evaluation prior to costly realization / implementation

• establishes links between abstraction levels

• => thus represents main step towards system concretization and realization

• -> starting point for iteration of design flow on next lower abstraction level

• go step back to a higher layer

cause:

• design flaws / errors resulting from imprecise modeling or insufficient exploration

• -> requrie abstraction and reiteration of design flow at next higher layer

• design fow with successive refinement

• from abstract system layer down to physical implementation

• abstraction still posisble

• identify design flows during early phases of design (at high abstracvtion level)

• (more a wish:)

  avoid time consuming and costly iterations across miltiple abstraction levels (-> try to avoid abstractions)

• executable specificaiton / model

  • possible validation of important aspects of system behavior during early phases of design process

• forsters holistic system considerations (HW&SW)

  • and decision making on important design criteria early in design process (-> avoids costly re-implementations)

• supports reuse of design flows and sub-systems / components (Re-engineering)

• seamless documentationof HW/SW systems, functions, interfaces as well as work load assumptions and requirements

• higher efficiency in design representation / specificatoin

  • one or few lines of HDL code may represent 1000 logic gates equivalents…

• overseas much bigger implementation space

  • design flow evolves in controlled fashion from higher towards lower abstraciton levels

    • -> narrowing down covered solution space

  • can be directed towards optimal solution

• design flow from lower implementation layer to higher system-level layers

• move up the layers by abstraction

• => refinement still possible

• develop individual components in parallel

  • -> and combine them at higher levels (system exploration)

• accelerate development of low-level components

  • without influence of the whole system

• reuse existing IP blocks and combine them into a system

• no!

• => engineers usually are system designers or component/silicon designers but rarely both!

  • -> system designer does not need detailed silicon knowledge

  • silicon designer does not need full knowledge of the entire system

• use both top-down and bottom-up

• top-down part:

  • odemtofy which high-level dependnecies and communication channels are required in the system

• bottom-up part:

  • identify which low-level components or IPs need to be developed from scratch

• separate system design from silicon design

• reduce effort on individual designers

• motivate the creation of reusable low-level components

• a formal description of a system

  • and/or its consistent sub-systems

    
    

• no!

• -> limited description of selected properties without each and every detail (abstraction)

• depend on purpose of the model

• e.g. power model, latency model,…

• abstraction level

• view

• degree of model details increase with successive system refinement

• description of a system according ot its (or)

  • behavior

  • structure

  • physical gemoetries

• system

• architecture / module

• RTL / Block

• Logic / Expression

• Device / Instruction

• network of communicationg sub-systems / tasks / processes

• which model the desired application or system functionality

hardware:

• processors

• ASIC

• Memory

• Buses

• I/O

• …

software:

• interacting SW modules

• processes

• …

Hardware:

• Counter

• Comparator

• ALUs

• Registers

• …

Software:

• Iterative Loops

• Program sequences

• …

Hardware:

• Logic Gates

• Flip-Flops

Software:

• Assignments

• branches

• arithmetic

• logic operators

Hardware:

• MOSFET transistors

• R

• C

• L

• …

Software:

• Machine code instructions

• system

• architecture / Module

• verify a chosen design

• simulation can’t exhaustively coverate input combinations

  • even for simple designs

• e.g. 32-bit ALU

• -> 2^32 * 2^32 = 2^64 input combinations

• assumption: 1 billion combinations / second evlauation speed

• => takes 585 years…

• make simulation meaningful

• => by restricting it to reasonable subset of input combinations…

  
  

• evaluate typical input patterns

  • -> to get initial confidence in design

• use known border / corner cases

  • e.g. counter -> wrap around…

• simulatoin increase confidence in design

• cannot prove correctness or completenes of design

• divide and conquer

• mixed level simulation

• reductoin of simulated real-time

• use entire spectrum of abstraction levels

• parallel simulation of individual system building blocks

• remains to be solved:

  • validation of interconnected components (system validation)

• simulating different system components at different levels of detali

• however:

  • test bences hagve to be applicable across different abstacion levels

  • -> to ensure comparability/consistency of results

• 1s in real time can be an “eternity” if one has to simulate a lot

  • e.g. gigabit ethernet with 64B packets -> 4*10^6 packets / s

• => use / load seed configuation with “saturated” simulation state

• clarify which system aspects to validate

• at which abstractoin level

• and how to ensure inter-operability between the levels

• behavioral (functionality)

• structural (realization)

• physical-gemoetric

System:

• data flow graphs

Architecture:

• processes, algorithms

RTL:

• arithmetic expressions

Logic:

• boolean algebra

Device:

• differential equations

System:

• Interconnected subsystems

Architecture:

• CPU, ASICs, Bus, Memory

RTL:

• ALU, Register, MUX

Logic:

• Logic gates, Flip-Flop

Device:

• Transistor, R, L

System:

• Polygons / ISA

Architecture:

• standard cells

RTL:

• macro blocks

Logic:

• CPU, Bus, Memory block diagrams

Device:

• Chip component diagram

• implementation

• analysis

• optimization

• refinement

• synthesis

• abstraction

• generation

• extraction

• behavior (/structure)

• ->

• structure

• structure

• ->

• behavior

• momentary iteration of particular view and level

• ->

• improved iteration of same view and level

• abstract design representation

• ->

• more detailed design representation under same view

• behavior

• ->

• more detailed and optimized structure (go one level down in abstraction..)

• detailed design representaiton

• ->

• more abstract design representation under same view

• structure

• ->

• physical / gemoetrical design representation

• physical / gemoetric design representaiton

• ->

• structure

• well established in IT-system design

• covers design phase, implementation phase and testing phase

• desing follows top-down

• verification of implementation starts on module level (bottom up)

  • first, eliminate errors within individual modules

  • then eliminate errors in module interaction

• modules may be hardware or software

• iteartions when neccesarry (go back on same level from test to design phase…)

  • => highly undesirable in system specification an darchitecture design level…