TIE-50206 Logic synthesis - tuni.fiTIE-50406 DSP Implementations, 5 cr TIE-50506 System Design, 5 cr...

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”


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


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


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


Example: Game console SoCs http://www.anandtech.com/show/7546/chipworks-confirms-xbox-one-soc-has-14-cus


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)


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)


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


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


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


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


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


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


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


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


Project management

Top-12 reasons for SW project failure [Charrette]


[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


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.


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


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


High-performance SoC trend

ITRS 2006 update, http://www.itrs.net/Links/2006Update/FinalToPost/01_SysDrivers_2006UPDATE.pdf

DPE = data processing engine


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


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


System design phases Blocks are preferably re-

usable IPs

Blocks implemented as in earlier lectures with re-usable macros


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


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


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


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


ITRS 2006 update, http://www.itrs.net/Links/2006Update/FinalToPost/02_Design_2006Update.pdf


TIE-50206 Logic synthesis - tuni.fiTIE-50406 DSP Implementations, 5 cr TIE-50506 System Design, 5 cr...

Documents

Transcript of TIE-50206 Logic synthesis - tuni.fiTIE-50406 DSP Implementations, 5 cr TIE-50506 System Design, 5 cr...