Design Partitioning Design Partitioning Chapter 3 HW SW

  • Slides: 28
Download presentation
Design Partitioning

Design Partitioning

Design Partitioning Chapter 3

Design Partitioning Chapter 3

H/W – S/W Partitioning • Why so much concern over the H/W – S/W

H/W – S/W Partitioning • Why so much concern over the H/W – S/W partitioning decision? • Because the lines between H/W and S/W are blurring making the decision seem “obvious”… • …which can lead to grave mistakes

H/W – S/W Partitioning • The partitioning decision has a significant impact on various

H/W – S/W Partitioning • The partitioning decision has a significant impact on various aspects of the project – Overall cost (development and production) – Overall time (development and production) – Overall success/failure (risk)

H/W – S/W Duality • Anything that can be done in digital hardware can

H/W – S/W Duality • Anything that can be done in digital hardware can be done in software • Anything that can be done in software can be done in digital hardware • Examples? • This “duality” is why the partitioning decision is such an issue • To make matters worse(? ), it’s getting harder and harder to define the line between hardware and software

H/W – S/W Partitioning • The decision space is multi-dimensional – – Microprocessor architecture

H/W – S/W Partitioning • The decision space is multi-dimensional – – Microprocessor architecture Algorithm complexity Physical space Development resources • • Available expertise Available time Available money Available tools – etc. • “In practice, the analysis of trade-offs for partitioning a system is most often an informal process done with pencil and paper or spreadsheets. ”

H/W – S/W Partitioning • If it’s so important, why is it delegated to

H/W – S/W Partitioning • If it’s so important, why is it delegated to an informal process? • Because it’s too hard (impossible? ) to formalize/automate the traversal of the multidimensional space – There’s just too much data affecting the decision – It’s a optimization problem and optimization problems are [in general] difficult to solve – Artificial Intelligence researchers have struggled with this type of problem for over 40 years!

H/W – S/W Partitioning • Generally accepted approach is to put off the final

H/W – S/W Partitioning • Generally accepted approach is to put off the final decision as long as possible • This way you will have gathered as much information as possible • “Path of least commitment” • This is the approach adopted by AI researchers – Consider the chess playing machines

Hardware Trends • H/W – S/W partitioning used to be easy – If you

Hardware Trends • H/W – S/W partitioning used to be easy – If you had a complex algorithm, you wrote software • Hardware design/implementation just took too long and designs were error prone • Silicon real estate was just too expensive

Hardware Trends • Then smart people like Carver Mead (Cal. Tech) came along and

Hardware Trends • Then smart people like Carver Mead (Cal. Tech) came along and spoiled things – His seminal book Introduction to VLSI Design [1980] made it look “simple” • Then along came Application Specific Integrated Circuit (ASIC) technology – Generic term but here we’ll use it to mean “programmable gate arrays” – Suddenly, you didn’t need a silicon foundry to create custom chips – you could do it in your office

Hardware Trends • Then along came Hardware Design Languages (Verilog and VHDL) – Programmer’s

Hardware Trends • Then along came Hardware Design Languages (Verilog and VHDL) – Programmer’s can be hardware designers with no additional training • And finally, the foundries (fab-houses) keep shrinking the “technology” (size of gates) on the silicon and increasing the wafer sizes – Higher density (transistors/unit area) provides smaller devices and faster circuits – More devices per wafer reduce processing costs

Programmer’s Can Be Hardware Designers? • Verilog HDL module simple; reg [0: 7] A,

Programmer’s Can Be Hardware Designers? • Verilog HDL module simple; reg [0: 7] A, B; // -- declare two 8 -bit registers reg C; // -- declare one 1 -bit register initial begin: stop_at #20; $stop; // -- run for 20 clock cycles end initial begin: Init A = 0; $display(“Time A B C”); // -- debug output $monitor(“ %0 d %b %b %b”, $time, A, B, C); // -- debug output end always begin: main_process #1 A = A + 1; #1 B[0: 3] = ~A[4: 7]; #1 C = &A[6: 7]; endmodule

Verilog HDL • The two initial blocks and the always blocks run concurrently –

Verilog HDL • The two initial blocks and the always blocks run concurrently – The initial blocks run once – The always block loops until the simulation stops • The variables/functions preceded by $ are simulation variables/functions (not part of the circuit) • The #1’s in the always block are 1 time-unit delays

Verilog HDL • Simulation output: Time A B 0 0000 xxxx 1 00000001 xxxx

Verilog HDL • Simulation output: Time A B 0 0000 xxxx 1 00000001 xxxx 2 00000001 1110 xxxx 3 00000001 1110 xxxx 4 00000010 1110 xxxx 5 00000010 1101 xxxx 7 00000011 1101 xxxx 8 00000011 1100 xxxx 9 00000011 1100 xxxx 10 00000100 1100 xxxx 11 00000100 1011 xxxx 12 00000100 1011 xxxx 13 00000101 1011 xxxx 14 00000101 1010 xxxx 16 00000110 1010 xxxx 17 00000110 1001 xxxx 19 00000111 1001 xxxx Stop at simulation time 20 C x x x 0 0 0 1 1 1 0 0 0 Note: the $monitor only produces output when a register value changes

Verilog HDL • Two key points here: – First [and most obvious] the “hardware

Verilog HDL • Two key points here: – First [and most obvious] the “hardware design” looks an awful lot like “C” code • And it’s run through a compiler that acts an awful lot like a “C” compiler – Whereas a “C” compiler generates assembly language statements targeted for a specific computer architecture, a Verilog compiler generates commands used in creating a circuit on the target device

Verilog HDL • Two key points here: – Second, the design was run through

Verilog HDL • Two key points here: – Second, the design was run through a hardware simulator – This means that the design can be debugged prior to spending time and money fabricating the device!

How Does It Help? • Since – the H/W and S/W development tasks are

How Does It Help? • Since – the H/W and S/W development tasks are starting to look similar, – and their designs are developed/simulated on the same workstation platform – bugs can be caught earlier • Rather than write S/W to simulate the hardware (as a means of testing the software) we can link the actual software to the hardware (Verilog) simulation – This also eliminates the possibility of bugs in the test software

Goal • The goal is to find design bugs early!!! System specification and design

Goal • The goal is to find design bugs early!!! System specification and design Hardware and software design/debug Cost to fix Design cycle Prototype debug System test

The Moral of the Story • Even though hardware is developed by writing software,

The Moral of the Story • Even though hardware is developed by writing software, the cost to fix it as time goes on is still tremendous – Eventually, it ends up on a piece of silicon that is manufactured by someone else • Within another part of your company • By an outside vendor in the case of “fab-less design houses” – Especially true as systems get more and more highly integrated (system on chip) – Many design teams will budget resources for multiple “chip spins” to alleviate the pain of bugs

What’s the Catch? • But all of these worries go away since we now

What’s the Catch? • But all of these worries go away since we now have hardware and software environments that can be merged together, right? • Wrong! – Even the simplest of Verilog hardware simulations can take hours to run – Simulation tools are expensive – Exhaustive testing is very difficult

What’s the Payoff? • If you can afford the tools… • and you can

What’s the Payoff? • If you can afford the tools… • and you can tolerate the simulation time… • and everything works as planned… • then the hardware software/software integration phase is [almost] trivial • This is referred to as “co-verification” – The hardware and software being verified concurrently

The Two Co’s • Co-design – The process of developing the hardware and software

The Two Co’s • Co-design – The process of developing the hardware and software simultaneously – We almost always do this, albeit the software is often untested w. r. t. the actual hardware • Co-verification – The process of verifying the correctness of the complete hardware/software system as a single unit including actual interfaces between the two

Risk Management • Hardware is the biggest risk • Hardware testing as a means

Risk Management • Hardware is the biggest risk • Hardware testing as a means of risk management – Test vectors – literally vectors of 0’s and 1’s that exercise all of the functionality of the hardware – Designers specify the input and expected-output pairs

Risk Management (cont. ) – Testers then run the inputs, the simulation generates the

Risk Management (cont. ) – Testers then run the inputs, the simulation generates the outputs, and the compares them to the expected-outputs • Testers may be part of the design team • Testers may be employees of the fabrication facility – Fabrication facility requires this because they want your business!

Risk Management • Realistically, you won’t exhaustively test the hardware • Realistically, the parts

Risk Management • Realistically, you won’t exhaustively test the hardware • Realistically, the parts you don’t test are the parts that fail

Test Vectors • In some cases you may be able to generate these automatically

Test Vectors • In some cases you may be able to generate these automatically – The HDL compiler can be used to generate test vectors by creating I/O functions – You just write a little bit of code that exercises the circuit code • In some cases you may only have time to check the “extreme cases” – You assume that if those work then all the cases in between will also work

Co-design/Co-verification • As useful (mandatory? ) as these techniques seem, there’s still issues –

Co-design/Co-verification • As useful (mandatory? ) as these techniques seem, there’s still issues – Cost of the tools – Time to learn the tools – Execution time of the tools • While us programmer’s can now design hardware using the tools, the bottom line is that if you want “good” hardware, have a hardware designer design it • An analogous statement goes for software development • Hardware/software integration remains a problem – “We’ll fix it in software” is a common industrial cry

And now… • …on to the lab • Interfacing to the outside world

And now… • …on to the lab • Interfacing to the outside world