System Complexity Estimation
Mark McDermott
Eric Swanson
EE197 June 12th, 2004
1
Can You Reach the Moon?
Not if you run out of time
Not if you run out of money
Estimating the complexity of
the system you’re building
is key
Your goal?
2
System Functionality
What are your system inputs and outputs?
How will the thing work?
How will you test it?
You can’t estimate complexity without a model
z what kind of model?
z who does it?
3
What Kind of Model?
Build a purely functional “golden model” of your
system.
z use C
Model your system’s response to all inputs and
outputs.
z including the on/off switch
The golden model becomes your system
specification.
The golden model provides the basis for your
system testbench [1].
4
Golden Models
Golden models are living models.
z customer inputs change them
z VC inputs change them
z design team inputs change them (as in when you
throw out features to save time and money)
A program manager writes and updates the model.
z this is the microsoft development approach [2]
How complex can this model be?…
5
Arnout’s Law
Engineering productivity is 30 things/day.
z 30 lines of C code/day
z 30 analog transistors/day
z 30 lines of RTL per day
z productivity is independent of what the thing is
Important corollary: Do as much of your design as possible
at the highest possible level of abstraction.
z Get the most out of each thing!
Guido Arnout, Chief Strategy Officer, Open Systems C
Initiative [3]
6
Golden Model Complexity
Lines of Code
100 lines = 3 days
z functionally incomplete
1000 lines = 33 days
z reasonable upper bound
10000 lines = 333 days
z exceeds the scope of a MSEE project
7
Golden Models
Golden models emphasize function, not implementation.
In some future, ideal world we may be able to compile a C-
language golden model directly into a world-class SoC with
z optimal embedded processors
z optimal hardware/software partitioning
z optimal intermacro communication
z proven library macroblocks
You will be grandparents before this happens.
z what do we do in the meantime?
8
Design Managers
A design manager will make the implementation
decisions.
Design space exploration tools won’t help at all.
Productivity issues will dominate the decision
process.
Let’s look at some of the implementation issues…
9
Embedded Processors
Custom processors are forbidden.
z processor reuse is mandatory
z software development tools drive this requirement
FPGA-based soft processors
z purists mock their performance
Î purists don’t build companies
z if a $500 PC can do your job in real time, an FPGA soft-
processor can do it without a PC
ÎMicrosoft overheads are tremendous
z proven reuse model
10
Hardware vs. Software
FPGA-RTL vs. DSP-software implementations
z FPGA-RTL raises performance by a factor α
z design effort also increases by α
z bigger α, more effort
Î optimized hardware comes at a huge
productivity cost [4,5]
The optimized hardware approach can be used at
most once.
z use your “one bullet” wisely or not at all
11
Hardware vs. Software (cont’d)
Software development isn’t cheap.
z ITRS 2001 estimates that software accounts for
80% of embedded system development cost [6]
z hardware-oriented SoC teams are likely to
underestimate the software effort
At least half of your team had better do software!
12
Intermacro Communication
The “single-shared bus” block-to-block
communication mindset reduces performance 50%
[7].
Reuse of library blocks provides time to optimize
communication between them.
Put together 30 IP blocks/day?
z processors, buses, peripherals, memories, etc.
z this will only happen in the FPGA world
13
Power Dissipation
Full-custom, hardware-based chips provide large
power savings [8].
z 30X over FPGA hardware
z 300X over DSP software-based implementations
Your prototype needs to store enough energy to
provide a ten minute demo to VCs.
z bring plenty of batteries on your road trips!
14
Verification
If your demo crashes once, you’re in trouble!
Twice, and you’re dead!
Microprocessor development teams have 2
verification engineers per design engineer [6].
Immature system development teams require at
least a 1:1 verify:design ratio.
15
Overall Design Productivity
Today’s SoC development teams achieve design
productivities of about 300K gates/man-year [9].
z using a complex mix of incompatible tools
z not including software!
An inexperienced but brilliant 10-person team of UT
student designers working in a 3 semester hour
project course can design and verify 100K-200K
total gates.
Today’s FPGAs hold lots more than that!
16
References
1. cadence, CoWare white paper, “ConvergenSC/Incisive Design Flow”, web document.
2. Michael Cusumano and Richard Selby, Microsoft Secrets, ISBN 0-02-874048-3, 1995, pp79ff.
3. Guido Arnout, Open Systems C Initiative, “OSCI Update’, web document.
4. Kevin Morris, “Aftermarket Avalanche: New Products Propel FPGAs into a Broader base”,
FPGA and Programmable Logic Journal, March 9, 2004.
5. Tavoularis, et al., “Accelerating VoIP Applications using Virtex FPGAs”, FPGA and Programmable
Logic Journal, March 2, 2004.
6. “Design Scope”, International Technology Roadmap for Semiconductors, 2001 edition.
7. K. Lahiri, et al., “Efficient Exploration of the SoC Communications Architecture Design Space”,
ICCAD Digest, 2000.
8. M. Michael Vai, “ASIC and FPGA DSP Implementations”, MIT Lincoln Laboratory report, 2003.
9. Jan Rabaey, “Design in the Late Silicon Age”, DesignCon 2004 presentation.
17
