Large System Design…different approaches needed People Usage – Dozen’s, geographically...
-
Upload
julian-evans -
Category
Documents
-
view
217 -
download
0
Transcript of Large System Design…different approaches needed People Usage – Dozen’s, geographically...
![Page 1: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/1.jpg)
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
![Page 2: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/2.jpg)
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
![Page 3: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/3.jpg)
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
![Page 4: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/4.jpg)
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.
![Page 5: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/5.jpg)
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)
![Page 6: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/6.jpg)
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
![Page 7: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/7.jpg)
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
![Page 8: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/8.jpg)
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
![Page 9: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/9.jpg)
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
![Page 10: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/10.jpg)
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)
![Page 11: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/11.jpg)
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)
![Page 12: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/12.jpg)
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.
![Page 13: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/13.jpg)
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
![Page 14: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/14.jpg)
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
![Page 15: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/15.jpg)
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
![Page 16: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/16.jpg)
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.
![Page 17: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/17.jpg)
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.
![Page 18: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/18.jpg)
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.
![Page 19: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/19.jpg)
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.
![Page 20: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/20.jpg)
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
![Page 21: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/21.jpg)
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.
![Page 22: Large System Design…different approaches needed People Usage – Dozen’s, geographically distributed – Decompose problem per designer – Divide and conquer.](https://reader036.fdocuments.in/reader036/viewer/2022062322/56649f535503460f94c77487/html5/thumbnails/22.jpg)
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?