Large System Designdifferent approaches needed

1
Large System Designdifferent approaches needed

• People Usage
• Dozens, 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

2
Large System Designdifferent 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

3
Top Down/Bottom Up Design Methods

• Top Down Design (TDD)
• Dominant in the late 70s and 80s (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

4
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.

5
Top Down/Bottom Up Design Methods

• Bottom Up Design
• Became established with OOP C, Java, the 90s,
  2k
• Emphasis is early coding and testing
• More often seen in revolutionary advances in
  hardware (Cray 3)

6
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

7
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

8
Top Down/Bottom Up Pros and Cons

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

9
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

10
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 dont build the wrong
  system right.
• Bottom Up when it makes sense
• Critical system components (crux parts)
• Intellectual property (check early)

11
Practical Implications to TDD/BUD

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

12
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 dont when
  connected!
• We can work on our designs separately only if we
  agree on the interfaces between them.

13
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

14
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
15
Partitioning

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

16
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.

17
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 (FFs), 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.

18
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
• Dont go too low in the details, stay in RTL
• No individual gates, FFs, unlessit is necessary
  to provide clarity as to what you are doing.

19
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.

20
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

21
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.
• Dont forget reset and adder overflow conditions.

22
Partitioning Data and Control

• One answer in VHDL
• if (reset_n 1) then
• acc_out lt X000
• elsif (clkevent AND clk1) then
• if (select 1) then
• acc_out lt data
• else
• acc_out lt accout data
• end if
• end if
• Whats that look like?