Lecture 13 - System design trends & challenges
Erno Salminen, TUT, 2015
TIE-50206 Logic synthesis
Outline and acknowledgements Challenges in digital systems
Introduction to system design
Most slides were made by Ari Kulmala
The International Technology Roadmap for Semiconductors http://www.itrs.net/
M. Keating and P. Bricaud, “Reuse Methodology Manual for System-on-a-Chip Designs, 3rd Edition”
Erno Salminen, TUT, 2015
http://www.itrs.net/Links/2009ITRS/2009Chapters_2009Tables/2009_SysDrivers.pdf
System drivers There isn’t any
“one size fits all solution”
Digital products have e.g. 6 different segments, all with with emphasizing different aspects E.g. security vs.
cost
Erno Salminen, TUT, 2015
System-on-chip (SoC) Integrated circuit (IC) that integrates most (all?) components of a computer or
other electronic system into a single chip Processors, memories, hardware accelerators, I/Os Interfaces to external memories, analog devices, etc
1990-1992 mobile phones included 15 ICs and 800 other discrete components and in 2002 3-4 ICs and 200 discrete components [Neuvo, 2004]
Texas Instruments’ OMAP chips have been used e.g. in many smart phones
[Y. Neuvo, Cellular phones as embedded systems, IEEE Int’l Solid-State Circuits Conference,Digest of Technical Papers, 2004. pp. 32-37.]
Development takes few years
Using SoC reduces system costs ($) and power
Two main SoC types:
1. high-performance (HP, later also CS – consumer stationary)
2. power-efficient (PE) for mobile
Erno Salminen, TUT, 2015
System-on-chip types1. Consumer stationary E.g. a high-end game machine
(like PS4, ) Performance is most important
differentiator. Wide application domain Many functions implemented
with software General-purpose processing
engines Has less processing engines
than mobile SoCs Relatively long life cycle Easy to add or modify functions
Die-size about 220 mm2
2. Power-efficient
E.g. mobile phone chips
Power consumption is strictly limited by the battery (lifetime)
High performance required nevertheless
Specialized application domain with rather predictable processing (e.g. channelcoding, video…)
Some general-purpose and many specialiazed HW units
Rapid progress and hence life cycle is short
Die-size about 64 mm2
Erno Salminen, TUT, 2015
Example: Game console SoCs http://www.anandtech.com/show/7546/chipworks-confirms-xbox-one-soc-has-14-cus
Erno Salminen, TUT, 2015
What variables define ”success” and ”failure”1. Scope and quality – user gets the job done
2. Schedule – it is ready on time
3. Budget – it is cheap enough
IT project statistics [Chaos 2009] 32% Succeeded - delivered on time, on budget, with required
features and functions 44% Challenged - late, over budget, and/or with less than the
required features and functions 24% Failed - cancelled prior to completion or delivered and
never used
[http://community.ca.com/blogs/theitgovernanceevangelist/archive/2009/05/04/understanding-project-failure-rates.aspx]
Challenges in digital system design High-level challenges, not taking into account physical and
manufacturing issues
1. Managing design complexity and verification
2. Minimizing power consumption
3. Economics
4. (optimizing chip area & performance)
Erno Salminen, TUT, 2015
Design challenge #1 :Complexity Good news: "Over the past ten years, reuse
leverage more than doubled, and more reuse tends to translates into less project effort, shorter cycle times as well as fewer spins and less schedule slip.”
Bad news: ”85%-89% of IC projects miss their original schedules… Schedule slip is 5-30% [Accenture’s report] or even 44% [Numetrics’ report]”
One reason is that re-usable components are not, after all, easy to integrate
[Eetimes] http://eetimes.eu/semi/showArticle.jhtml?arti
cleID=204702114 http://www.eetasia.com/ART_8800520301_4
80200_NT_68f71562.HTM
Fig. SoC size as function of time (CAGR= compound annual growth rate)
Erno Salminen, TUT, 2015
Design complexity Logic size increases over 10x per decade!
There will be lots of people, lots of files, lots of requirements…
All things must at least double-checked, hence all steps mustbe repeatable
Reuse and automation are crucial
Be extra careful with versioning and verification
Erno Salminen, TUT, 2015
New architectures: Intel Terascale/Polaris, 2007- Research processor with 80 homogeneous cores (small processors) Interconnected with 2-D mesh network-on-chip Stacked chip: to solve local memory problems
Parallel programmingbecomes mainstream
How to program itefficiently?
Fig 1.Die stacking improvesperformance Fig 2. Intel Polaris
Erno Salminen, TUT, 2015
Challenge #2: Power consumption Chip power consumption can be defined as
Pavg = Pdynamic + Pleakage
Traditionallly Pdynamic dominated in CMOS and Pleakage was very small
However, in 90nm and below, leakage has becomes an increasingly important factor (see fig)
Other factors, such short-circuit power when gateswitches state, are oftenignored
Power optimization done both at design time and a runtime
Lots can be with applicationdesign as well! Fig. Leakage vs. dynamic power
[http://asic-soc.blogspot.com/2008/03/leakage-power-trends.html]Erno Salminen, TUT, 2015
Additional constraints (power-efficient SoC)
ITRS 2005, http://www.itrs.net/Links/2005ITRS/SysDrivers2005.pdf
More performance, very
well…
Problem #1
Problem #2
Effort
Erno Salminen, TUT, 2015
Dynamic power consumption
K = average number of transitions of the output node every cycle divided by two (e.g. ½ means that there is a single transition each cycle) Glitches etc
Vdd = Supply voltage f = clock frequency Cout = output capacitance Note the square-law dependence of Vdd
Typically, higher the f, higher Vdd required
2dynamic out ddP K C V f
Erno Salminen, TUT, 2015
Power breakdown in mobile SoCLarger fraction of power is staticsince these devices are ”always-on”. Note also that memory’s static(leakage) power is larger thandynamic.
Dynam
ic PS
tatic P
Erno Salminen, TUT, 2015
Challenge #3: Economics Rapid technology change shortens product life cycles and makes
time-to-market a critical issue
Margins are very small in many business areas
Very high design productivity is needed Sure we can build the SoC but will anyone want to buy it with such a
price?
Maximizing volume reduces unit costs Speed binning – chips are priced according to their frequency
Note that many customers in consumer markets appreciatedifferent things than engineers…
Silicon fabs are very expensive, in the order of milliards of dollars
Erno Salminen, TUT, 2015
Simplified Electronic Product Development Cost Model
http://www.itrs.net/Links/2005ITRS/Design2005.pdfErno Salminen, TUT, 2015
Reuse, higher abstraction level anddesign automation are the intertwined cornerstones.
Lots of research needed in general.In many cases, adopting the existing good methods is already a step forward for many companies.
Major steps in design productivity
Erno Salminen, TUT, 2015
Design development costs Manufacturing non-recurring engineering (NRE) costs are in the order
of millions of dollars (mask set + probe card) for high-end chips Tens to hundreds of thousands for ”regular” ones
High non-recurring engineering (NRE) costs necessitate high volume Design errors can cause silicon re-spins that multiply manufacturing NRE
ASIC manufacturing cycle times are measured in weeks, with low uncertainty.
Design and verification cycle times are measured in months or years, with high uncertainty.
Test cost has grown faster than manufacturing costs Software can account for 80% of embedded-systems development cost Verification engineers outnumber design engineers on microprocessor
project teams Verification is top priority from day one, not the last phase just before
delivery
http://www.itrs.net/Links/2005ITRS/Design2005.pdfErno Salminen, TUT, 2015
Study further Our curriculum went toppsy turvy… Many courses merged or discontinued
Recommendations TIE-50406 DSP Implementations, 5 cr TIE-50506 System Design, 5 cr
TIE-21200 Software Testing, 6 cr TIE-11400 Seminar on Pervasive Computing, 3 cr TIE-10100 Bachelor'sThesis Seminar in Pervasive Computing, 0
cr
Erno Salminen, TUT, 2015
Project management
Top-12 reasons for SW project failure [Charrette]
Erno Salminen, TUT, 2015
[R.N. Charette, Why software fails [software failure],Spectrum, IEEE, Vol. 42, Iss. 9, Sept. 2005, pp. 42 - 49. ]
[N. Holmes, The Data Doughnut and the Software Hole, Computer, Vol. 39, Iss. 6, June 2006, pp. 100 - 99.]
Full version of slides [http://www.tkt.cs.tut.fi/kurssit/50200/K14/Kalvot/lect_14_project_management_k14_v01.pdf]
There is not exact formula for success However, there are quite exact predictors for failure
I. Project management –related1. Unrealistic or unarticulated project goals2. Badly defined requirements3. Poor project management4. Poor estimates of needed resources5. Poor reporting of status6. Unmanaged risks
Top-12 reasons for SW project failureII. Context–related
7. Poor communication8. Commercial pressure9. Stakeholder politics
III. Implementation-related10. Use of immature technology11. Sloppy development practices12. Inability to manage complexity
Erno Salminen, TUT, 2015
Productivity factors Table shows the best and
worst differences to nominaldevelopment
Decrease factor is usuallylarger than increase It is much easier to mess
up than being extraproductive
E.g. trying reuse crappy SW is doomed, high requirementcreep drops productivity by77%, skipping inspections by48%...
From: P. Goldberg, Producing Production QualitySoftware - Lecture 14, New York Univ., 2005, onlinehttp://www.cs.nyu.edu/artg/Producing_Production_Quality_Software/Fall2005/
Summary Increasingly complex systems need new methodologies Hierarchical, gradual refinement Reuse evertyhing you can. Pay attention that your own work is
reusable Accessible, easy to start with, well commented, tool-independent…
Invest in executable specifications Several advances and active research required in order to keep on
pushing the technology in its limits Pedanctic and repeatable design approach is needed Realistic req. management and schedule Automation, version control Hofstadter's Law: It always takes longer than you expect, even when you take
into account Hofstadter's Law.
Erno Salminen, TUT, 2015
Course summary Most important things you must know (V)HDL basics: entity, architecture, process, signal, data types… What happens in simulation and synthesis Testbench and reuse concepts Clocking and synchronization FPGA technology
You made a great progress during the exercises! From simulated1-b adder to an audio synthesizer on FPGA
You can have 1 A4 sheet of your own notes in the exam See you on the otherTIE-courses! Thank you for your interest
Erno Salminen, TUT, 2015
Erno Salminen, TUT, 2015
Extra
High-perf example: IBM/Sony/Toshiba CELL BE, 2005-
Acronyms:synergistic processor elements (SPE)dual-threaded power processor element (PPE)element interconnect bus (EIB) (actually ring)
Commercial chip with multiple heterogeneousprocessors: 1 64-b PowerPC (32KB L1) + 8 128-b SPEs (256 KB scratch-pad mem) each with DMA, unified 512 KB L2 cache3.2 GHz, orig. 90 nm, 221 mm2, 240M transistors, theor. max 230 GFLOPS
Erno Salminen, TUT, 2015
High-performance SoC trend
ITRS 2006 update, http://www.itrs.net/Links/2006Update/FinalToPost/01_SysDrivers_2006UPDATE.pdf
DPE = data processing engine
Erno Salminen, TUT, 2015
SoC-PE Design complexity trends
#DPEs is 3-4x compared to SoC-HP
Memory dominates the areaErno Salminen, TUT, 2015
Power breakdown in Hi-perf Soc
ITRS 2006 update, http://www.itrs.net/Links/2006Update/FinalToPost/01_SysDrivers_2006UPDATE.pdf
Variability between devices and temperature effects will increase leakage notably
Power consumption of single DPE decreases but their number increases. Battery life is not an issue here, but chip packaging and cooling are.
Dynam
ic PS
tatic P
Erno Salminen, TUT, 2015
Note the difference in power: hi-perf SoC 40-500 W vs. mobile SoC 1-7 W (slide #15)
Impl 11: Sloppy development practices
No version control (see later slide) Some steps not repeatable by others than the orig. designer
Licenses, EDA tool setup/projetc files, local files, OS, undocumented tricks… Creates a single point of failure, e.g. due to long sick leave
Many manual, error-prone steps Automate as mush possbile, e.g. with scripts make, run test, analyze_perf…
Unrecognized vendor-lock Proprietary file format prevents moving to better environment/chip Design works only with certain (old) tool/OS version
Non-existing/outdated/poor documentation Poor link between docs and code No review process No headers in files (designer, purpose, project…)
Impl 11: Sloppy development practices (2)
Inadeqaute verfication/test suite Plain stupidity: ”What do you mean that price list must be correct? It’s an
estimate, get it?” – true story Ignoring the compiler warnings Dead code Inconsistent naming Not checking return values Not using assertions 25% of admin time spent going down blind alleys due to bad msgs
[Candea] Forgetting that code lives forever
Prepare that it will be read and modified many years after development
”I hope someone else will check it” ”I’ll code this first and test after that”
[Candea, http://resist.isti.cnr.it/free_slides/dependable/candea/Lecture-08_(Manageability).pdf]
Impl 11b: must use version control Use version control (Git, SVN, ...)
Works well with text: .txt, .c, .h, .vhd, .tex, .java, .html., xml, .csv, .py…
Teaches one to take logically consistent steps in a project Add files, update, commit, check log…
Not just for ”ready” files Very few things are ready ever. Most things are somewhat ready and always under
development Depends on company policy regarding continuous integration
Helps backup process
• Easy throw-away code prototyping• Keeps track of your work (how many changes
in a week?)• Keeps track who did what• One can go back to see any previous version• Write reasonable commit log messages• Do not mix sources with the generated files
and logs• Version control is must for all work
Impl 12: Inability to manage complexity
Limit the scope Divide-and-conquer, separation (orthogonalization) of
concers Separate computation and communication Separate function and architecture
Reuse everything you can Model-based design, model-driven engineering
Obtain early estimates and bounds Establish the critical choices early Automate the implementation via synthesis
Carry out a small pilot project first Remember it’s a proof-of-concept, not final implemtation!
Techniques for this challenge are addressed in TIE-50506 SystemDesign
Impl 12b: Inability to manage complexity Many projects have hundreds to thousands of files “The most important aspect of any design is how it is
partitioned. The second most important aspect of any design is its interfaces.” – M. Keating Minimize coupling between modules Try to make functionality obvious Try to make misuse hard (e.g. add checks and asserts to the code) Dst and source parameters always in the same order Similar naming convention Use consistent measurement units
If some function users meters as units, no function should use millimeters
Names should not be too long but they should also be to-the-point
System design process
Erno Salminen, TUT, 2015
System design phases Blocks are preferably re-
usable IPs
Blocks implemented as in earlier lectures with re-usable macros
Erno Salminen, TUT, 2015
System Design Process1. System specification Identify the system requirements (engineering, marketing) Formulate the preliminary specification
2. Develop a behavioural model and test environment Basic algorithms, their usability (e.g. good enough video encoding
quality) Executable specification, “golden reference”, e.g. C++/SystemC Develop environment for verifying the functionality and
performance of the design3. Model refinement Do not introduce too many details at first. Add them gradually. Try to discard definitely bad choices early E.g. floating point model -> fixed-point model -> cycle-accurate
and bit-accurate model
Erno Salminen, TUT, 2015
System Design Process (2)4. HW/SW partitioning (decomposition)
Largely a manual process guided by experience and understanding of tradeoffs (area vs. performance)
Define the interfaces between HW and SW, communication protocols5. Specify and develop a hardware architectural model
IPs, Memory architecture, interconnection structure… Bandwidth, latency… Start from high level models, transaction-level modeling Refine the architecture until it meets the requirements
6. Refine and test architectural model (co-simulation) A behavioural model of the HW A prototype version of the SW System-level test SW Key to success – efficient HW-SW co-design
Erno Salminen, TUT, 2015
System Design Process (3)7. Specify and implement blocks Reuse if possible E.g. HW specification: Basic functions
Timing, area, and power requirements
Physical and SW interfaces
Descriptions of the I/O pins and register map
Separate testbenches for all HW components!
8. Integration First small blocks together, then bit larger, then... Check the assumptions and estimations made in earlier phases
Erno Salminen, TUT, 2015
System design timeline
”Spiral flow” instead of waterfall
Maximum parallelism HW development
(prototypes, emulation) SW development Verification (verification
environment) HW/SW integration
Iterations after iterations Inevitable Gradual refinement
Physical issues taken into account early
Erno Salminen, TUT, 2015
ITRS 2006 update, http://www.itrs.net/Links/2006Update/FinalToPost/02_Design_2006Update.pdf
Erno Salminen, TUT, 2015
Top Related