Large System Design…different approaches needed

• People Usage– Dozen’s, geographically distributed– Decompose problem per designer– Divide and conquer can reduce design/debug time– Use existing IP (intellectual property)– Efficient tools • HDLs, SW environment, scripts, make files

Large System Design…different approaches needed

• Chip Build Process– Self documenting– Test data self-generated and user generated– Self checking– Can regress over multiple designs– Highly automated and repeatable

Top Down/Bottom Up Design Methods

• Top Down Design (TDD) – Dominant in the late 70’s and 80’s (1st space shuttle)

– Emphasis: planning and complete system level understanding prior to implementation

– Focus moves from general to specific– Basic idea: recursively break down design into well

understood pieces, then implement

Top Down/Bottom Up Design Methods

• The TDD Process– Establish overall system view• No low-level details in sub-parts

– Each sub-part is refined, adding detail and breaking into smaller pieces if necessary.

– Repeat the above step until all parts are well defined in brain-sized pieces so that validation is possible.

– Use “black boxes” where necessary to hide complexity.

This class will primarily use top down design.

Top Down/Bottom Up Design Methods

• Bottom Up Design – Became established with OOP; C++, Java, the 90’s, 2k+– Emphasis is early coding and testing– More often seen in revolutionary advances in hardware

(Cray 3)

Top Down/Bottom Up Design Methods

• Bottom Up Design Process– Design individual lowest-level parts first– Implement and test the parts– Connect the parts together to form bigger parts until the

system is built

Top Down/Bottom Up Pros and Cons

• TDD (pros)– Really big designs can be decomposed down to brain-

sized pieces– Each task clearly defined, clear team/individual

responsibility– Simultaneous, independent efforts possible– Major bugs exposed earlier– Reusability of modules possible– Modules can exist at different levels of abstraction

Top Down/Bottom Up Pros and Cons

• TDD (cons)– Delays testing of functional parts– Some decisions can’t be made without first coding– Custom modules can be difficult to reuse– Duplication of effort can result

Top Down/Bottom Up Pros and Cons

• BUD (pros)– Early testing of critical (crux) parts– Code reusability

• BUD (cons)– New parts may not fit in the system– Loss of overall direction of the design

Top Down/Bottom Up….Which to Use?

• Primarily Top Down (85+%)– Most of the work will go on here– Eventually must have complete system understanding– Build the right system… don’t build the wrong system

right.

• Bottom Up when it makes sense– Critical system components (crux parts)– Intellectual property (check early)

Practical Implications to TDD/BUD

• Concurrency– 9 women can’t give you 1 baby in a month– Communications difficulty and intensity grows quickly– Limited parallelism may exist (linear processes)

Practical Implications to TDD• Interface definition– Vitally important between design modules– Interface implies communication– Designs break at the interfaces• Modules always work on their own….but don’t when

connected!

We can work on our designs separately only if we agree on the interfaces between them.

Architecture/Partitioning

• Architecture comes first, but not exclusive of partitioning

• Usually done by the grey hairs• The bigger system “sees” your architecture• Architecture questions must be answered first – (pay me now or pay me dearly later)– Ask many questions– Lots of false starts– Many possibilities, explore them– Experience here is unbeatable

Architecture and Partitioning

Architecture -clock speed -voltages -max power -die area -partitioning -throughput -latency -cost -price -vendor/library -time to market

Partitioning - modules needed and their function -bus width -clock domains -pipelined, non-pipelined -ripple carry, lookahead, carry save -state machine partitioning -one fast memory or two slower interleaved

Partitioning

• It’s a aid to help you think about your design• Co-developed as the architecture takes form• Evolves over time• Partitioning solidifies before coding

Partitioning - Where and How

• Data and Control• Clock Domains• Power (Vdd) Domains• These main three divisions make the 1st cut

partition for you. • You must partition between these three.

Partitioning – Data and Control

• Data paths are established first– Ask: From input to output, how must the data be transformation?– Then: Determine what structures are required to perform the

transformation.– Structures used are: adders, incrementers, multipliers, ALUs,

MUXes, registers (FF’s), data buses.

• Control is established second– Ask: What sequence of steps are required to make the data

transformation happen?– Then develop the state machines to implement the movement of

data as required.– Structures used are: state machines, opcodes to ALUs, select pins

on MUXes, enable pins on FFs.

Partitioning – Data and Control

• Partition into clearly defined functions– Register file, ALU, 32x32 adder, FIFO, shift register, counter,

state machines– Name the function for what it does. If you have trouble

naming it, you have not partitioned well.• Do not mix functions together – (automatic rejection of your code by me)– E.g.: state machines embedded in counters– Control imbedded within data paths

• Don’t go too low in the details, stay in RTL– No individual gates, FF’s, unless…it is necessary to provide

clarity as to what you are doing.

Partitioning – Data and Control

• Look for replication of function and exploit it– Example: reuse of an ALU to compute operands and also

to compute next address to fetch

• Your HDL code may not reflect the partitioning– This is normal and OK– Occurs more as you become proficient in HDL coding– You still must know what you are trying to create

structurally. HDLs infer structure. Learn the gates that different constructs produce.

Partitioning - Interface Definition

• All interfaces between modules must be completely and exhaustively defined– Protocols, voltages, pulse versus edges, cycle time, pulse

width, clock domain, signal meaning– Owners of the modules must often talk over the

meaning and intention of the interfaces.

• Designs break at the interfaces, therefore minimize the number of interfaces– This implies good partitioning and architecture

Partitioning / Architecture

• Design a digital circuit that takes 4, 8-bit data values in and computes their average. Use a register to hold the sum prior to doing the division and to provide the output data. Each input data is available a short time after a rising edge of the clock. The average must be available also just after a rising edge of the clock.– What questions should you be asking?– Concentrate on the data path first, simply leave dangling

wires for control to be added later.– You will need an adder, a MUX and a register.– Don’t forget reset and adder overflow conditions.

Partitioning – Data and Control

• One answer in VHDL:if (reset_n = ‘1’) then

acc_out <= X”000”;

elsif (clk’event AND clk=‘1’) then

if (select = ‘1’) then

acc_out <= data;

else

acc_out <= accout + data;

end if;

end if;

• What’s that look like?