semiconductor development in ireland: reducing development...

Semiconductor Development inIreland: Reducing Development

Stress Caused by DigitalHardware and EmbeddedSoftware Team Interaction.

Ivan J. Griffin

Ph.D. Thesis 2010

1

Semiconductor Development inIreland: Reducing Development

Stress Caused by DigitalHardware and Embedded Software

Team Interaction

Ivan J. GriffinB.Eng., The University of Limerick, 1995M.Eng., The University of Limerick, 1997

A thesis submitted in fulfilment of the requirements

for the degree of Doctor of Philosophy

Supervised by Dr. Ita Richardson

Submitted to the UNIVERSITY of LIMERICK, April 2010

Declaration

Title: Semiconductor Development in Ireland: Reducing Development Stress

caused by Digital Hardware and Embedded Software Team Interaction.

Author: Ivan Griffin.

Award: Doctor of Philosophy in Computer Science

Supervisor: Dr. Ita Richardson.

I hereby declare that this thesis is entirely my own work, and does not contain material

previously published by any other author, except where due reference or acknowledgement has

been made. Furthermore, I declare that it has not previously been submitted for any other academic

award.

21st April 2010 17h25

Except where excerpts from the contributions of others are explicitly noted, this text is copyright ©

2004-2010 Ivan Griffin.

i

Abstract

Semiconductor Development in Ireland: Reducing Development Stress caused by

Digital Hardware and Embedded Software Team Interaction.

Ivan J. Griffin

TODAY’S consumer electronic products are complex, multi-discipline systems, far beyond justphysical gates on a semiconductor chip. Their development involves a delicate mix ofengineering disciplines and technologies such as analog hardware, digital hardware, software, boarddesign, semiconductor physics and chemical engineering.

The research presented in this dissertation examines the specific relationship between theintegration of digital hardware and software development activities and the successful creationof modern consumer electronics devices and embedded computing platforms, to determine whichaspects of inter-discipline development caused the most difficulty to a semiconductor device for theconsumer electronics market as it progressed in life-cycle through from design to tape-out/massproduction.

As of 2010, Semiconductor Fabrication techniques continue to (broadly) follow Gordon Moore’sLaw (Moore, 1965), which states that the number of transistors on a chip doubles approximatelyevery two years. In addition, incremental improvements in fabrication techniques has resulted insuccessively smaller chip geometries—greater functionality requiring less silicon area and consuminglower power than the previous generation. Embedded computing devices are omnipresent inconsumer electronics in modern society. Consumer desire and expectations of product improvementhas lead to rampant innovation in the consumer electronics market, with terrific pressures to be firstto market with a new innovative feature or design. Along with this increase in capability comes anunfortunate but necessary increase in complexity.

Consequently, the semiconductor devices (Application Specific Integrated Circuit (ASIC),System-on-Chip (SoC), System-in-Package (SiP), modules) that power consumer electronic productsrequire significant resource investments in both hardware and software design, implementation andtest—investments that are increasing in direct relationship with the device complexity.

The research presented in this thesis is a grounded theory which shows various categories ofinteractions that occur between Irish digital hardware and software development teams who worktogether in SME organisations on such product. The contribution of this research is in six parts:

(a) it identifies that digital IC hardware engineering is very similar in many respects to softwareengineering;

(b) it illustrates that the business models that survive in the ecosystem rely on engineering that issufficient to meet market needs;

(c) it shows that the social and geographical degrees of separation play a more significant role inadversely affecting and impeding performance than technical or techno-cultural issues betweenthe two groups;

(d) it acknowledges that there is a growing separation of technical mindset between software anddigital IC hardware;

(e) it provides strong evidence for the applicability of Agile methods in the development ofconsumer electronics SoC devices;

(f) it presents a list of patterns of organisation and workflow for semiconductor projects that mayhelp in the development process.

Expert opinion and comparison against existing literature was used to validate the results. Scopefor potential future work in the area of digital hardware and software team interaction is alsopresented and discussed.

Supervisor: Dr. Ita Richardson.Keywords: ASIC Semiconductor SoC Digital IC Hardware Software Grounded Theory

ii

Acknowledgements

I would like first and foremost to thank my supervision, Dr. Ita Richardson, for all her support,advice and encouragement during my research. A Ph.D. is a difficult endeavour at the best oftimes. Dr. Richardson has a subtle yet profound knowledge and understanding of social sciences

techniques which she was generously willing to share with me. My circumstances changed quite

significantly during the course of my research—I got married, became a father, changed to an

employment with considerably more responsibilities. . . As a result, I occasionally found myself

lacking in free time, and direction when pursing this goal. I also on occasion experienced the

self-doubt described in Miles and Huberman (1994): ‘we have encountered many students launched on

qualitative dissertations or research projects who feel overwhelmed and under-trained.’ Nevertheless, Dr.

Richardson kept me on the straight and narrow, academically speaking. She was a true source of

inspiration and ideas when I had become lost in my research; and she was equally a source of great

confidence to me when I had become concerned with the uncertainty in direction my work often

experienced, particularly in comparison to my starting point.

I sincerely appreciate the contribution of Professor Emeritus Eamonn McQuade in proof-reading

and providing valuable suggestions and recommendations for the improvement of this dissertation.

I would also like to offer special thanks to my former lecturer, M.Eng. supervisor, and

engineering manager in Parthus Technologies, Dr. John Nelson, for both professional and academic

encouragement over the last decade or so. I consider him very much a mentor who helped me to

shape my entire career to date.

Indeed, all my colleagues and ex-colleagues of Parthus deserve credit for educating me in the

real-world antics of embedded software and custom ASIC design—as well as some great fun and

antics along the way:

• To the old ‘Wireless Business Unit’ of Parthus Technologies, particularly the ‘Drua’ crew, and

the ‘UPF Pack-Horse Gang’—having accidentally started with a platform that we thought was

25MIPs (but in actuality was closer to 7MIPs), we ended up with a great lightweight Bluetooth

Solution;

iii

http://www.ceva-dsp.com/

• To Alan Donnelly, for teaching me more than I ever intended, or wanted, to know about

RF devices, Field Programmable Gate Array (FPGA) devices and boards—especially how to

accidentally pour hot, steaming, coffee over them;

• To Jerry O’Brien for showing me the light—there is no money to be made in engineering—for

our drives across Route 101 in California with a GPS navigation unit that kept speaking in

Japanese, and our tour of the Hollywood sign in Los Angeles;

• To Pat Lehane for his consistent brilliance, as an engineer, as a Verilog hacker, as a project

manager—and for listening when the software guys insisted that there was definitely a problem

with a particular hardware clock;

• to Damien Nolan for his immaculately safe pair of hands when it comes to a chip tape-out,

for his meticulous attention to detail, and for, unknownst to him, confirming to me that

TEX and LATEX are by far the most appropriate tools to typeset a thesis—based primarily on

his grumblings over the inadequacies of Microsoft Word and its master book feature when

compiling the Paradiso chip functional specification;

• To David Moloney for his foresight, his unparallelled ability at systems architecture, his

anticipation of market evolution, and his unbridled enthusiasm—one of the few true geniuses

I know;

• To Niall Ó hEarcáin and Roger Maher for giving me the opportunity to lead an embedded

software development team through a few interesting and challenging projects, and most of

all for being very decent chaps to work for;

• To David Airlie, ‘our man down under’, for sticking to his guns on open source software, and

for ensuring the Fedora desktop on which I pulled this document together had sufficient 3D

eye candy;

• To Peter Flynn and Marc van Dongen for LATEX help, allowing me to automatically generate

CSV logs of codes versus quotations from the LATEX typesetting run;

• To the late Martin Mellody (1975–2009), a true friend, entrepreneur and engineering

brilliance—how sad it is that you didn’t live to see the fruits of your labour.

I would not be permitted to return to work without offering some recognition of my colleagues

and friends in Frontier Silicon, especially the Shannon firmware team and Dublin SoC and DSP

teams.

iv

http://www.fedoraproject.org/http://www.frontier-silicon.com/

Finally, an acknowledgement is due to advice I came across when pursuing this endeavour—after

a prolonged period of inertia, frustration, and procrastination:

• Firstly, Tveit (2008) had some genuinely useful tips on finishing a Ph.D., but the one that I

appreciated was:

. . . ‘doers’ are more likely to finish their Ph.D. than ‘smarties’. Thinking doesn’t create yourthesis, but writing might!

• Secondly, Lamott (1995) offers some sage-like wisdom and advice in suggesting:

The first draft is the child’s draft, where you let it all pour out and then let it romp all over theplace, knowing that no one is going to see it and that you can shape it later. You just let thischildlike part of you channel whatever voices and visions come through and onto the page.

In typically engineering fashion,Young and Raymond (2001) explains this as being due to

the fact that ‘you often don’t really understand the problem until after the first time you implement a

solution’, and Brooks, Jr. (1995) echoes this advice in ‘plan to throw one away: you will, anyhow’.

This research is partially supported by the Science Foundation Ireland funded projects, Global Software Development

in Small to Medium Sized Enterprises (GSD for SMEs) grant number 03/IN3/1408C within Lero—the Irish Software

Engineering Research Centre (http://www.lero.ie/).

Funding for portions of this work was generously provided by Science Foundation Ireland / Enterprise Ireland through

the B4Step Project—‘Building a Bi-Directional Bridge Between Software Theory and Practice’ grant number 02/IN1/I108.

v

http://www.lero.ie/

This thesis is especially dedicated in loving memory of

my late parents, John and Marie Griffin.

Both my sister Yvonne and I miss you dearly.

You always encouraged me to make the effort to pursue a Ph.D.

so mum and dad, this is for you. . .

also to my wife Triona,

for her support, love and kindness,

and especially for keeping me sane. . .

vi

Glossary of Terms

Acronyms

ASIC Application Specific Integrated Circuit

ATS Abstract Test Suite

BoM Bill of Materials

CSV Comma-Separated-Variables file

DSP Digital Signal Processing

EDA Electronic Design Automation

FPGA Field Programmable Gate Array

GDS-II “Graphics Data System revision II”, the industry de-facto file format standard for IC

layout data exchange

GSD Global Software Development

HDL Hardware Description Language

IC Integrated Circuit

IP Intellectual Property

LT Lower Tester

MPW Multi Project Wafer

OEM Original Equipment Manufacturer

ODM Original Design Manufacturer

PCO Point of Control and Observation

QDA Qualitative Data Analysis

vii

RF Radio Frequency

UML Unified Modeling Language

UT Upper Tester

VHDL VHSIC Hardware Description Language

VHSIC Very High Speed Integrated Circuit

SiP System-in-Package

SoC System-on-Chip

Definitions

Block Test The testing of a hardware component in isolation, equivalent to a unit test in software

terminology

Blog A web diary or commentary (contraction of ‘weblog’)

Design Flow The series of steps that combine the use of Electronic Design Automation (EDA) tools

to design an Integrated Circuit

Fab Silicon wafer fabrication facility

Hardware Simulation Modelling of the hardware at different levels of abstraction (functional, gate

level, etc.) for the purposes of hardware verification

Mask A tool that contains a single pattern image that is applied to an entire wafer to define the

integrated circuit

Reticle A tool that contains a pattern image that needs to be stepped and repeated across a wafer

to define the integrated circuit

Shuttle Run A periodic engineering lot of MPW silicon wafers, containing designs from numerous

customers which has transferred through the use of a reticle

System-on-Chip A System-on-Chip is a complex IC device which integrates the major functional

elements of a product into a single chip—for example, processor, on-chip memory, custom

acceleration logic etc.

viii

Unit Test Testing of a software component in isolation

Wafer A silicon wafer is thin round slice of a single crystal (highly pure) semiconductor substrace

(usually silicon) that used in the fabrication of integrated circuits and other microelectronic

devices.

Wiki A wiki is a web-based content management tool designed to enable those who access it to

contribute and easily modify its content, using a very simple markup language.

Tape-Out Tape-out is the last phase of the design of a new chip, where the design is sent to the

semiconductor foundry for manufacturing. The term dates back to when physical paper tapes

were sent, whereas nowadays the transfer is electronic.

ix

Contents

1 Introduction 1

1.1 Embedded Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Electronic Devices Everywhere! . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2 Business Models and Market Interception . . . . . . . . . . . . . . . . . . . 2

1.1.3 Coping with Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.4 Embedded Software Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.5 Architecture of an SoC device . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1.6 Software in IC Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Summary of Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.2.1 Outline of Thesis Structure and Content . . . . . . . . . . . . . . . . . . . . 9

1.3 My background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

I Initial Literature Review 14

2 Semiconductor Ecosystem 15

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Semiconductor Market . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.1 Intellectual Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.2 Chip Manufacture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.3 Product Design Companies . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.2.4 Characterisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.5 Embedded Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.6 The Global Marketplace—and Global Competitive Landscape . . . . . . . . 26

2.2.7 Maintaining a Competitive Edge in the Marketplace . . . . . . . . . . . . . . 29

2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3 Etymology of Hardware and Software 33

x

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.2.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.2 Digital Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.2.3 Design Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.4 Coding as an Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 Duality of Computing Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3.1 The Techno-Philosophical Argument . . . . . . . . . . . . . . . . . . . . . . 44

3.3.2 Hardware Design Language as a Variant of Software . . . . . . . . . . . . . 46

3.4 Cognitive Effects of Modelling and Abstraction, Linguistics and Culture . . . . . . . 48

3.4.1 Psychological Aspects of Logic Modelling . . . . . . . . . . . . . . . . . . . 49

3.4.2 Scientific Advance through Abstraction . . . . . . . . . . . . . . . . . . . . . 51

3.4.3 Linguistic Relativity Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.4.4 Mediation of Culture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.4.5 Computer Programming Languages . . . . . . . . . . . . . . . . . . . . . . . 56

3.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.5.1 Research Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4 Digital Hardware Flows vs. Software Development Processes 62

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.2 Technical Discipline Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4.2.1 History of Hardware Development Approaches . . . . . . . . . . . . . . . . 64

4.2.2 Design Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.3 Highlevel SoC Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.4 Computational Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.5 Testing: Validation and Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.6 Abstraction Breakdown . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

4.6.1 Trend towards Higher-Level Synthesis and Functional Programming . . . . . 78

4.7 Detailed Integrated SoC Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

II Research Design 82

5 Research Design and Investigation 83

xi

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

5.2 Conceptual Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

5.2.1 Conceptual Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.3 Method of Investigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

5.3.1 Qualitative versus Quantitative versus Mixed Methods . . . . . . . . . . . . 88

5.3.2 Philosophical Perspectives of Research Paradigms . . . . . . . . . . . . . . . 89

5.3.3 Selection of Interpretation Methodology . . . . . . . . . . . . . . . . . . . . 92

5.3.4 Grounded Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.3.5 Phases of Grounded Theory Research . . . . . . . . . . . . . . . . . . . . . . 98

5.4 Data Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.4.1 Data Collection Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

5.4.2 Interviewing Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

5.5 Data Reduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.5.1 Open Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.5.2 Axial Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

5.5.3 Selective Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

5.6 Data Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

5.7 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

5.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

III Theoretical Model and Solutions 121

6 Emergence of Theoretical Model 122

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.2 Theory Building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

6.3 Business Realities: Impact on Technical Flow . . . . . . . . . . . . . . . . . . . . . . 124

6.3.1 Consumer Electronics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

6.4 Risk: Approach to it . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

6.4.1 System Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

6.4.2 The influence of discipline specialisation on inter-team cultural differences . . 135

6.5 Social/Geographical Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

6.5.1 Social Factors Independent of Location . . . . . . . . . . . . . . . . . . . . . 137

6.5.2 Social Factors that are Exacerbated by Geographical Separation . . . . . . . 141

xii

6.6 Techno-cultural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

6.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

7 Emergent Toolbox of Patterns for SoC Project Organisation 150

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

7.2 What are Patterns? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

7.3 The Pattern Groupings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

7.4 Patterns of Social Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

7.4.1 Mitigate tacit knowldge loss through Social Networking Tools . . . . . . . . 153

7.4.2 Actively Seed Social Interaction amongst Groups . . . . . . . . . . . . . . . . 154

7.4.3 Provide Project-level Focal Point through Core Team Structure . . . . . . . . 156

7.4.4 Drive continual progress through Daily Calls during Crunch Issues . . . . . . 157

7.4.5 Manage IP Deliveries Efficiently . . . . . . . . . . . . . . . . . . . . . . . . . 158

7.5 FPGA Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

7.5.1 Automate FPGA Design Traceability through Version Tracking . . . . . . . . 159

7.5.2 ASIC Synthesis Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

7.5.3 Automate FPGA Programming . . . . . . . . . . . . . . . . . . . . . . . . . 162

7.5.4 Implement Best Practises for FPGA Development . . . . . . . . . . . . . . . 163

7.5.5 Keep ASIC/SoC team involved in FPGA Development . . . . . . . . . . . . . 164

7.6 Development Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

7.6.1 Perform Regular Builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

7.6.2 Share Code across Test Platforms and Technical Disciplines . . . . . . . . . . 166

7.6.3 Minimum Working Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

7.6.4 Keep the Firmware Design Simple . . . . . . . . . . . . . . . . . . . . . . . . 169

7.6.5 Keep the Firmware team involved in C code for simulations . . . . . . . . . 170

7.6.6 Consider Agile Methods, Test-Driven Development . . . . . . . . . . . . . . 171

7.6.7 Communicate in Diagrams Early On . . . . . . . . . . . . . . . . . . . . . . 172

7.6.8 Implement Recovery Mechanisms for Boot ROMs . . . . . . . . . . . . . . . 173

7.6.9 Provide Software Test Plans Early, Hardware Features Early . . . . . . . . . 175

7.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

8 Validation of Theoretical Model 178

8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

8.2 Business Themes in Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

xiii

8.2.1 Commercial Realities of Software Development . . . . . . . . . . . . . . . . 182

8.3 Risk Themes in Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

8.4 Socio-Geographic Themes in Literature . . . . . . . . . . . . . . . . . . . . . . . . . 185

8.4.1 The Sociology of Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

8.4.2 Globally Distributed Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

8.5 Technical Themes in Literature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197

8.5.1 Techno-Cultural Perspective Differences . . . . . . . . . . . . . . . . . . . . 198

8.5.2 Technical Determinism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

8.5.3 A Language Convergence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

8.5.4 Importance of Mixed Skill Sets . . . . . . . . . . . . . . . . . . . . . . . . . 211

8.6 An Opportunity for Agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

8.6.1 Agile Manifesto versus Agility . . . . . . . . . . . . . . . . . . . . . . . . . . 217

8.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222

9 Conclusions 223

9.1 Overall Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

9.2 Research Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

9.2.1 Implications for Practitioners . . . . . . . . . . . . . . . . . . . . . . . . . . 229

9.2.2 Implications for Educators . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

9.3 Scope for Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

9.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

IV Appendices 235

A Interviewee Biographies 236

B Interview Guides 238

B.1 Initial Interview Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

C Historical Roots of Computational Logic 242

C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

C.2 Advances in Mathematical Logic, and the Entscheidungsproblem . . . . . . . . . . . 242

C.3 Computing Advances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

D Digital Hardware Toplevel Design 248

xiv

D.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

D.1.1 Digital Toplevel Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

E Interview Codes 252

E.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

E.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

E.2.1 Coding through Typesetting . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

E.2.2 Visualisation of the Ontology . . . . . . . . . . . . . . . . . . . . . . . . . . 254

E.2.3 Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

E.3 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

E.3.1 Coding Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

E.3.2 GraphViz graph description input file generation . . . . . . . . . . . . . . . . 264

F Academic Papers 267

F.1 Academic Papers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

F.1.1 Globally Distributed Development of Complex Systems for the Consumer

Electronics Semiconductor Industry . . . . . . . . . . . . . . . . . . . . . . . 267

F.1.2 Other Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

Bibliography 269

Index 293

xv

List of Figures

1.1 High Level Abstraction to Physical Layout . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Generalised SoC Block Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Thesis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Semiconductor Ecosystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 8-inch silicon wafer during manufacture. . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3 Wafer is cut into separate silicon die, which are then individually wire-bonded and

packaged . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4 65nm Digital Radio ASIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.5 Decapped ASIC in QFN package, showing bond wiring . . . . . . . . . . . . . . . . 20

2.6 65nm ASIC—bare silicon die . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.7 Embedded Software Market—2003 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.8 IC Complexity - Moore’s law for memory and microprocessors . . . . . . . . . . . . 27

3.1 A Perspective on Engineering Endeavour and its Relationship to Systems Analysis

and Science . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2 Boolean Logic is Instantiated as Hardware, Firmware and Software Models . . . . . 46

3.3 Design Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1 The Cycle of Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.2 Naïve Digital Hardware Flow/Software Process Comparison . . . . . . . . . . . . . 65

4.3 ASIC Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.4 Gajski-Kuhn Y-chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.5 Gajski-Kuhn Y-chart showing levels of abstraction . . . . . . . . . . . . . . . . . . . 68

4.6 Gajski-Kuhn Y-chart showing Design Methodologies . . . . . . . . . . . . . . . . . 70

4.7 High-level ASIC Design Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.8 FPGA-based Verification Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . 76

4.9 Detailed SoC Flow Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

xvi

5.1 Initial Conceptual Framework for the Study . . . . . . . . . . . . . . . . . . . . . . 86

5.2 Reasoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.3 Components of Data Analysis: Iterative Model . . . . . . . . . . . . . . . . . . . . . 93

5.4 Hermeneutic Circle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.5 Representative Memo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.6 Grounded Theory Method employed in this research . . . . . . . . . . . . . . . . . 101

5.7 Model of Symbolic Interactionist View of Question-Answer Behaviour . . . . . . . . 110

5.8 Visualisation of Open Codes as Tag Cloud . . . . . . . . . . . . . . . . . . . . . . . 113

5.9 Early Selective Coding Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6.1 Theoretical Model of Influence on Hardware / Software Interworking . . . . . . . . 123

6.2 Axial Coding of Business Reality Concepts . . . . . . . . . . . . . . . . . . . . . . . 126

6.3 Emergence of Business Realities Theme . . . . . . . . . . . . . . . . . . . . . . . . . 127

6.4 Competing Influences of Time, Quality and Cost . . . . . . . . . . . . . . . . . . . . 127

6.5 Radar Plot of Market Pressures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

6.6 Perceived Consequence Effect of Influencing Factor contribution to Total Project Risk 131

6.7 Axial Coding of Risk Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

6.8 Emergence of Risk Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

6.9 Axial Coding of Social Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

6.10 Emergence of Social Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

6.11 Axial Coding of Techno-cultural Theme . . . . . . . . . . . . . . . . . . . . . . . . 147

8.1 Influence of Business Themes in Theoretical Model . . . . . . . . . . . . . . . . . . 179

8.2 Gartner ‘New Technology Hype Cycle’ . . . . . . . . . . . . . . . . . . . . . . . . . 180

8.3 Components of the Hype Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

8.4 Influence of Risk Themes in Theoretical Model . . . . . . . . . . . . . . . . . . . . . 184

8.5 Influence of Social Themes in Theoretical Model . . . . . . . . . . . . . . . . . . . . 186

8.6 Domain Bounds of Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

8.7 Layered Behavioural Model of Software Development . . . . . . . . . . . . . . . . . 191

8.8 Wilson’s Concept of (Social) Interface in SoC Design . . . . . . . . . . . . . . . . . . 192

8.9 Refined Model of Trust (from Literature) . . . . . . . . . . . . . . . . . . . . . . . . 196

8.10 Influence of Techno-Cultural Themes in Theoretical Model . . . . . . . . . . . . . . 197

8.11 Triadic Reciprocal Causation of Social Cognitive Theory . . . . . . . . . . . . . . . 199

8.12 Modified Concept of (Social) Interface in SoC Design . . . . . . . . . . . . . . . . . 201

xvii

8.13 Influence of Technical Determinism Themes in Theoretical Model . . . . . . . . . . 202

8.14 Naur’s Symmetrical Relation between Tools, Problems and People . . . . . . . . . . 203

8.15 System Architecture: HW/SW Boundary . . . . . . . . . . . . . . . . . . . . . . . . 214

8.16 The Embedded Software Education Gap . . . . . . . . . . . . . . . . . . . . . . . . 215

8.17 Cornerstones of Agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

8.18 The C.HI.D.DL typology of Organisational Cultures . . . . . . . . . . . . . . . . . 220

8.19 Implications of Agility for SoC Development . . . . . . . . . . . . . . . . . . . . . . 221

C.1 Timeline of Fundamental Developments in Computational Logic . . . . . . . . . . . 245

C.2 Turing Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

D.1 Digital Hardware Toplevel Design Flow . . . . . . . . . . . . . . . . . . . . . . . . . 249

E.1 Qualitative Data Analysis (QDA) Workflow . . . . . . . . . . . . . . . . . . . . . . 252

E.2 Typesetting Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

E.3 Typesetting Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

E.4 Visualisation of Open Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

E.5 Visualisation of Axial Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

E.6 Axial Coding of Business Realities Theme . . . . . . . . . . . . . . . . . . . . . . . 257

E.7 Axial Coding of Risk Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

E.8 Axial Coding of Social Theme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

E.9 Axial Coding of Techno-cultural Theme . . . . . . . . . . . . . . . . . . . . . . . . 260

xviii

List of Tables

2.1 Semiconductor Market Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 12 inch Integrated Circuit (IC) Mask Costs—2008 . . . . . . . . . . . . . . . . . . . 21

2.3 IC Technology Evolution 1971–2008 . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 The Tasks of Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1 Key difference in Grounded Theory approaches . . . . . . . . . . . . . . . . . . . . 96

6.1 Emergent Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

6.2 Digital Hardware vs. Software Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 145

7.1 Toolbox of Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

7.2 Example FPGA Naming Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

A.1 Biographies for Interviewees . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236

E.1 QDA Open Codes for Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

E.2 QDA Open Codes and Interview Excerpts . . . . . . . . . . . . . . . . . . . . . . . 261

xix

List of Research Statements

Research Problem

Statement of Problem and Definition of ‘Development Stress’ . . . . . . . . . . . . . . . . 31

Fundamental Terms

Definition of ‘Software’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Definition of ‘Hardware’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Research Questions

Question 1—‘Frame of Reference’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Question 2—‘Effects due to Intrinsic Qualities of Discipline’ . . . . . . . . . . . . . . . . 61

Question 3—‘Effects due to Technical Specialisation’ . . . . . . . . . . . . . . . . . . . . 61

Question 4—‘Relieving Development Stress’ . . . . . . . . . . . . . . . . . . . . . . . . . 61

Research Contribution

Research Contribution (Summary) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Question 1 addressed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227




xx

Chapter 1

Introduction

“There is nothing more difficult to take in hand, more perilous toconduct or more uncertain in its success than to take the lead in theintroduction of a new order of things. ”— NICCOLÒ DI BERNARDO DEI MACHIAVELLI

1469–1527, Italian Diplomat, Political Philosopher, Musician and Writer

1.1 Embedded Systems

CONSUMER electronic devices are developed through the output of two main technologicaldisciplines—electronic hardware and software. Whilst it is important in many marketsegments that the devices look attractive, and have form factors and skins (“plastics”) that are fit for

purpose, it is primarily the feature sets enabled by advances in hardware and software technology

that fuel the continuing consumer appetite and desire for such devices.

Device and technology convergence is well documented in the industry (Wilson, 2004), and

disruptive technologies such as the 2007 Apple iPhone (Ranger, 2008) have encouraged a renewed

vigour for “featuring-up” market entry-level mobile devices.

Park (1998) mentions the need for highly integrated System-on-Chip (SoC) devices in order to

remove cost and reduce the size of high volume electronic devices:

‘With the marketplace hungry for smaller, faster and cheaper products, highly integrated systemson a chip (SOCs) are a practical necessity.’

Lavagno et al. (1999) additionally noted that:

‘in the near future, most objects of common use will contain electronics to augment theirfunctionality, performance, and safety.’

1

1. INTRODUCTION 1.1. EMBEDDED SYSTEMS

1.1.1 Electronic Devices Everywhere!

Indeed, semiconductor devices are ubiquitous in our modern day world. They are used to enable

practically every single electronic device we use—from our digital cameras, games consoles and

mobile cellular phones, to the ignition and traction control systems of our cars, to the avionics in

our aircraft.

The computing power of a smartphone device in 2010 (for example, Apple iPhone 3G S

600MHz ARM Cortex-A8 processor / Google Nexus One 1GHz Qualcomm Snapdragon

processor), or of a portable games console in 2008 (for example Sony PSP, 333MHz R4000

processor), is equivalent or even superior to that of a desktop computer of even desktop computing

of 10 years ago (for example, Intel® Pentium® III 1GHz in 2000). Home games console processing

power has unleashed tremendous potential for scientific computing (Williams et al., 2006) and

mainframe development (Ferguson, 2007).

In these devices, digital hardware and embedded software systems combine to provide the logic

that provide their basic functionality, with analogue hardware components interfacing the world of

digital logic to the outside environment.

1.1.2 Business Models and Market Interception

The semiconductor business that provides these highly integrated systems depends on tight margins

and large volumes. Paul Otellini, Chief Executive Officer of Intel Corporation1, describes the

semiconductor business very well in the following:

‘Our business model is one of very high risk: We dig a very big hole in the ground, spend threebillion dollars to build a factory in it, which takes three years, to produce technology we haven’tinvented yet, to run products we haven’t designed yet, for markets which don’t exist.

‘We do that two or three times a year.’ (BBC News, 2008)

Semiconductor designers need to anticipate an early market requirement two to three years

hence, estimate what will still be a competitive technical solution at that time period (in other words,

an extremely aggressive and challenging solution at the current time) and aim for this—hoping to

intercept a rising market with the right technology and feature set at the right time at some point in

the future.

1As of 21st April 2010.

2


As if this wasn’t a difficult enough undertaking, two eponymous adages conspire together to

impart ever greater complexity to the system designs. Moore’s Law states that the number of

transistors on a silicon design doubles roughly every 18 months (Moore, 1965), whereas Wirth’s

Law (‘Software is getting slower more rapidly than hardware becomes faster.’ (Wirth, 1995)2) deals

with the increasing software complexity that Moore’s devotees enable.

Coudert (2002) notes that ‘designs keep getting bigger and more complex’. These elaborate

and intricate designs require significant investment of designer time to ensure they are correctly

validated and verified. Due to the severe market pressures and the rampant pace of improvement,

it is not surprising, perhaps, that very often consumers end up dealing with slightly under-cooked

products—the rise of the so called “Beta culture” (Boran, 2009) where product is rushed to market

and the initial early adopters form part of the extended beta test phase.

1.1.3 Coping with Complexity

Coveney and Highfield (1995) describe the exploration of manifestations of complex process and

systems:

’Within science, complexity is a watchword for a new way of thinking about the collectivebehaviour of many basic but interacting units, be they atoms, molecules, neurons, or bits withina computer. To be more precise, our definition is that complexity is the study of the behaviour ofmacroscopic collections of such units that are endowed with the potential to evolve in time.’

Semiconductor projects, with multi-million lines of HDL and software code, and even larger sizes

test bench code, definitely qualify as complex systems. Those tasked with developing, integrating

and debugging these systems into existence as devices fit for the end consumer can certainly attest

to the difficulty in comprehending complex systems:

‘Their interactions lead to coherent collective phenomena, so-called emergent properties that canbe described only at higher levels than those of the individual units. In this sense, the wholeis more than the sum of its components, just as a van Gogh painting is so much more than acollection of bold brushstrokes’. (Coveney and Highfield, 1995)

As Michael Fister, President and CEO of Cadence Design System put it:

‘Development is not only about having a billion transistors on a chip but also about having themall work.’ (Banks and Fister, 2008)

2Wirth, for his part, attributes the saying to Martin Reiser in Wirth (1995).

3


In order to deal with this increasing complexity, it was necessary for engineers and scientists to

raise the level of abstraction to cope. This precipitated the eventual specialisation into the disciplines

of hardware engineering and software engineering:

• Initially, analogue electrical circuits were used to model calculus, trigonometry and complex

number theory;

• Analog circuits became digital with the use of valves enabling the use of Discrete Logical

Algebra to raise the abstraction to the new digital level;

• Values were replaced with transistors over time;

• Software changed from punch-tape instruction sequences to bit patterns stored in computer

memory;

• Assembler mnemonics were abstracted from the binary machine code to program the machine;

• Higher level languages such as C and Pascal allowed greater productivity (Brooks, Jr., 1995;

Davis et al., 1998), simplifying common tasks to language constructs (if...else etc.) and

allowing greater portability;

• Early computer hardware had a significant influence on software, with high-level languages

‘strongly influenced by the von Neumann architecture: they were sequential and imperative at the

beginning. Writing such a program was guided by the capabilities the machine offered, instead of by the

ideas on how to solve the particular problem’ (Kloos, 1987);

• Hardware engineers use logical circuit elements of digital metaphor to raise the abstraction

bar beyond the electrical physics transistor or semiconductor level: digital hardware design

evolved from transistors to Boolean logic, from logic cells to to HDLs capable of describing

logic blocks and of algorithmic expression, and to system level design—Figure 1.1 illustrates

the abstraction of working in a HDL language (Figure 1.1(a)), and the ultimate schematics

that end up being generated for fabrication (Figure 1.1(b));

• Languages evolved into object oriented, dynamically typed, virtual machines running byte

code, and subsequently into higher level domain specific languages.

Current (~2010) 45nm fabrication technology is actually below the wavelength of the laser

light used, and so immersion lithography is now—purified water or other liquid replacing air as

the medium as it reduces the effective wavelength (Owa and Nagasaka, 2003). For the purposes

4


(a) Source VHDL Fragment (b) Layout of Complex Digital Media ASIC, 65nm lowpower process (without metals)

Figure 1.1: High Level Abstraction to Physical Layout

of comparison, 45nm transistors are 2,000 times smaller than a human hair (Intel Corporation,

2007a), and 400 or so would fit on a human red blood cell3 (Intel Corporation, 2007b).

Vannevar Bush noted that the benefits of specialisation are not without consequences:

‘. . . there is increased evidence that we are being bogged down today as specialization extends.The investigator is staggered by the findings and conclusions of thousands of other workers—conclusions which he cannot find time to grasp, much less to remember, as they appear. Yetspecialization becomes increasingly necessary for progress, and the effort to bridge betweendisciplines is correspondingly superficial.’ (Bush, 1945)

1.1.4 Embedded Software Skills

There are differences in skill sets and differences in mindset and approach required in the

development of software for embedded systems versus desktop software. For instance, (Anderson,

2008) remarks that:

‘Embedded systems are frequently resource-limited. These systems have low-power processors,possible battery operation, and limited memory and storage. And yet, there are increasingdemands from consumers for high-end features. . . ’ ‘. . . virtually all embedded system developers

3Red Blood Cells, RBCs, have a mean diameter of approx. 8µm (Hillman et al., 2005)

5


need an intimate knowledge of the hardware and how the software will interact with it. Thisknowledge is often times down to the hardware-register level of the device.’

Wolf (2006) describes the growth of the embedded computing profession, including some of its

growing pains. Wolf states that:

‘Many consumer devices now run millions of lines of software code to support the range of servicesand connectivity that consumers demand. An increasing number of devices also allow loadingand running of third-party software. In addition to creating a demand for new application-levelsoftware, this also makes the foundational software in the device more complex.’

Keating and Bricaud (1998) concurs with this viewpoint, stating:

‘System-on-a-Chip designs have a significant software component. . . Software plays an essentialrole in the design, integration and test of SoC systems, as well as in the final product itself.’

The International Technology Roadmap for Semiconductors is a fifteen-year assessment of the

semiconductor industry’s future technology requirements. It is sponsored by the semiconductor

industry associations in the five leading chip manufacturing regions in the world: Europe, Japan,

Korea, Taiwan and the United States. The ITRS Update (2008) recognises the trend of increasing

software importance in the industry, confirming ‘software as an integral part of semiconductor

products, and software design productivity as a key driver of overall design productivity’.

Additionally, it notes that ‘embedded software. . . has emerged as the most critical challenge to SOC

productivity’.

There are a number of reasons why this is the case: for example, Goldman (2009) mentions

platform based designs (one chip, many products customisations in software), bug risk avoidance,

extending the hardware lifecycle, and general product differentiation.

1.1.5 Architecture of an SoC device

Figure 1.2 illustrates the blocks that might be found in a contemporary (~2010) SoC device for

the consumer electronics markets (e.g. cellular, digital home multimedia etc.) This includes a boot

ROM (and possibly ROM libraries with a patch table in RAM), various types of RAM, a micro-

processor, function-specific core logic, general purpose I/O, a variety of transport peripherals for

talking to other chips and devices, and a variety of hardware accelerators.

All of these blocks require individual verification, and the entire SoC design needs validation to

ensure blocks can be used in tandem to implement the product’s market use cases—to ensure, for

instance, there is sufficient bus bandwidth, that there are no resource conflicts in the system, that all

interlocking and signal handshaking is correct.

6


TCM RAM,System RAM

ROM

NAND Flash

E2PROM

Micro-Processor(possibly multi-core)

Function-Specific Core

JTAG

GPIO

DMAC

PLL

Clock & PowerManagement

Crypto Accelerator

Transport Peripherals(e.g. USB, I2C, SPI, UART,SDIO, WiFi, Bluetooth, . . . )

ADC / DAC

PDM / PWM

2D/3D Accelerator,TFT Control

Figure 1.2: Generalised SoC Block Structure

Semiconductor programmes, and particular SoC designs, typically require large quantities of

deliverables to be managed in parallel with very tight timescales, with cross functional teams, on

multiple sites, and with limited project management resource.

1.1.6 Software in IC Design

The software aspects of semiconductor Intellectual Property (IP) design are often overlooked, and

yet end up contributing disproportionately to the perceived quality of the end product. Many of

the design flaws and oversights from the earlier hardware phase are left for resolution by software

workaround.

Additionally, tight market opportunities mean that whilst hardware teams possibly run late,

software teams must deliver on time and to changing customer specifications. To some degree,

semiconductor IP design is, by virtue of the very marketplace demands, an extreme example of an

agile system development industry (Beedle et al., 2001).

Meanwhile, system architects and hardware design teams face the significant problem of trying

to predict the pace of technology 2–3 years out, and to achieve what is called the market intercept

7

1. INTRODUCTION 1.2. SUMMARY OF RESEARCH

point—making sure the technology is competitive and relevant at time it becomes available in mass-

production.

1.2 Summary of Research

The research presented in this thesis is concerned with investigating the environment and factors

which influence system-on-chip development in this industry, with a specific focus on inter-discipline

team interaction that occurs between digital hardware and embedded software, and with the

development of process patterns that address the particular problems faced.

The aim of this research is the development of a grounded theory showing various categories

of interactions that occur between the digital hardware and software development teams that work

together on complex semiconductor product. The contribution of this research is in six parts:

(a) it identifies that digital IC hardware engineering is very similar in many respects to software

engineering.

(b) it illustrates that the business models that survive in the consumer electronics semiconductor

ecosystem rely to a tailoring of engineering work that is sufficient to meet market intercept

windows;

(c) in contradiction to the original premise of the research, it shows that the social and

geographical degrees of separation play a more significant role in adversely affecting and

impeding performance than technical or techno-cultural issues between the two groups—

specifically, it indicates that geographical separation of design teams is the greatest detraction

of productivity potential in complex consumer electronics semiconductor projects;

(d) it acknowledges that, despite the shared ancestry, there is a growing separation of technical

mindset between software and digital IC hardware;

(e) it provides strong evidence for the applicability of Agile methods in the development of

embedded devices, specifically for consumer electronics semiconductor devices;

(f) it presents a list of patterns of organisation and workflow for semiconductor projects that may

help in the development process.

8


1.2.1 Outline of Thesis Structure and Content

In presenting an outline of the structure of this dissertation, it is helpful to first identify the separate

phases that constitute empirical research4 (Creswell, 2003):

• Identification of a research problem;

• Review of the existing literature;

• Specification of a purpose;

• Collection of Data;

• Analysis and Interpretation of data;

• Reporting on and evaluating data.

This introduction chapter provides for the identification of the specific research problem. With

a view to matching with the remaining phases presented op. cit, the remainder of this dissertation is

divided into five parts, as illustrated in Figure 1.3:

• Part I (“Initial Literature Review”) presents a literature review to describe the semiconductor

market place, compare the disciplines of digital hardware and embedded software, and

formulate research questions to tackle the identified research problem;

• Part II (“Research Design”) describes the steps employed to plan and conduct the research;

• Part III (“Theoretical Model and Solutions”) describes the outcomes of the research, presents

my validation of the research—through post-mortem pre-existing literature review—and

identifies scope for future work;

• Part IV (“Appendices”) provides some ancillary information, in the form of a set of

appendices.

Part I—Initial Literature Review

Literature in qualitative study is commonly employed a deductive manner, as a basis for advancing

and framing the research problem, and for validating the results. Bearing this in mind, the use of

scholarly literature serves three distinct aims within this thesis:

4Research in which the knowledge or theory derived from it is as the result of observations or experiments.

9


Chapter 1: Introduction

Chapter 2: Semiconductor Ecosystem(identifies and introduces Research Problem)

Chapter 3: Etymology ofHardware and Software

(formulates Research Questions)

Chapter 4: Digital Hardware Flows vs. Software Development Processes

Part I: Initial Literature Review

Chapter 5: Research Design and Investigation

Part II: Research Design

Chapter 6: Emergence of Theoretical Model

Chapter 7: Emergent Toolbox of Patterns for SoC Project Organisation

Chapter 8: Validation of Theoretical Model

Chapter 9: Conclusions

Part III: Theoretical Model and Solutions

Figure 1.3: Thesis Structure

• Firstly, as this research is an exploratory qualitative analysis of digital hardware and software

team interaction, literature is used at the outset to set the scene (as opposed to any direct

hypothesis construction) and to establish the ecosystem of semiconductor market.

In this regard, Chapter 2 (“Semiconductor Ecosystem”) provides some background

information on the ecosystem of semiconductor development, including detail on the various

business models that are present. It describes the semiconductor market place, especially

market dynamics.

• Secondly, literature is used to provide a basis for the comparison of digital hardware and

software activities as very closely related manifestations of computational logic.

10


Chapter 3 (“Etymology of Hardware and Software”) presents an etymology on embedded

systems to clarify what constitutes digital hardware and software. It traces the historical

roots of computing science in order to further highlight the common ancestry between these

disciplines.

Chapter 4 (“Digital Hardware Flows vs. Software Development Processes”) compares

and contrasts software and hardware development flows, and presents some conceptual

similarities between the various process stages.

• Thirdly, literature is used to validate the outcomes from the research. This is presented later, in

Part III (“Theoretical Model and Solutions”), Chapter 8 (“Validation of Theoretical Model”).

Part II—Research Design

Chapter 5 (“Research Design and Investigation”) discusses the conceptual framework used in

designing the research. This framework is used to choose and develop a suitable research strategy,

based on the inputs of what is known about the topic, what the intent of the study is, and the specific

scientific methods applicable. It presents a discussion of the strategy used in the research. The

methods employed for data collection and analysis are examined in detail. It describes the selection

of candidates, the interview process, and the coding of data collected during the interviewing of field

experts.

Part III—Theoretical Model and Solutions

Chapter 6 (“Emergence of Theoretical Model”) describes how the codes obtained from data

analysis were subsequently used in the construction of a grounded theory illustrating the areas

of development stress and impediment in digital hardware and software team interaction.

Chapter 7 (“Emergent Toolbox of Patterns for SoC Project Organisation”) presents a toolbox

of semiconductor project design patterns, which emerged through analysis of the data collected. It

is my contention that these patterns of management and project organisation, evolved during the

course of the research, are viable techniques for empowering team and project productivity.

Chapter 8 (“Validation of Theoretical Model”) validates the results of the research, with

reference to pre-existing literature—mainly sourced from other areas of study within software

research—for example, the phenomenon of Global Software Development (GSD).

11

1. INTRODUCTION 1.3. MY BACKGROUND

Finally, Chapter 9 (“Conclusions”) summarises this work, provides conclusions to my identified

research questions, implications for practitioners and educators, and also proposes potential

opportunities for follow-on research.

Part IV—Appendices

Appendix A (“Interviewee Biographies”) presents biographies for the main individuals interviewed

in the collection of data for this thesis.

Appendix B (“Interview Guides”) presents the initial interview guides, used initially to frame

and semi-structure discussions.

Appendix C (“Historical Roots of Computational Logic”) describes the evolution and

development of computing, placing the (relatively) recent specialisations into the disciplines of

Hardware and Software Engineering in an historical context, and is useful background reading

for Chapter 3 (“Etymology of Hardware and Software”).

Appendix D (“Digital Hardware Toplevel Design”) looks at the steps involved in digital

hardware toplevel design, for the purpose of better understanding the tasks involved—in particular,

the additional considerations that bear an impact upon digital hardware design.

Appendix E (“Interview Codes”) describes how the coding of collected data was converted

through subsequent analysis into various facts.

Appendix F (“Academic Papers”) presents some of the work contained in this thesis, as published

in other forums during the course of the work.

1.3 My background

The role of the researcher as the primary data collection instrument within a study requires careful

treatment, in order to transparently convey any personal biases or opinions at the outset of this

work. Locke et al. (2000) suggests that the researcher’s individual viewpoints and effect on the

research environment can contribute positively to the research.

As my role in this dissertation is that of the active researcher, I will now present my background

in order to address any concerns of ‘strategic, ethical, and personal issues’ (Creswell, 2003; Locke

et al., 2000).

I graduated from the University of Limerick with a Bachelor of Engineering in Computer

Engineering in 1995, and a Masters of Engineering in Computer Engineering by Research and

12

1. INTRODUCTION 1.3. MY BACKGROUND

Thesis (Griffin, 1997). During these studies, I was exposed to a mixture of analog and digital

hardware electronics theory, although I chose to specialise in software. From 1997, I worked as a

research officer in the University on a variety of telecommunications related projects.

From 1999 through to 2005, I worked in an IP creation company, developing wireless

communication stack software for mobile devices. I was particularly involved at the hardware /

software interface: working on such tasks as hardware abstraction layer development, low-level

real-time state machines, device drivers.

More recently, from 2005 to 2010, I have worked as IC Firmware Manager in a fabless

semiconductor company, where we have been concerned with the integration of third-party

intellectual property, the development of firmware for Mobile Digital TV, Digital Radio and Internet

Radio/Connected Audio receiver chipsets, and the verification of complex ASIC designs.

Bolker (1998) suggests that ‘Some people seem always to have known what they want to write their

dissertations about . . . ’ Whilst not entirely true in my case, my métier is semiconductor firmware, and

I have a very deep professional interest in better understanding how to get digital hardware and

embedded software teams working effectively towards a common goal. As such, Bolker (op. cit)

might term me one of:

‘. . . the lucky ones who have a burning question that they want to spend time answering . . . Youfollow your curiosity, and, if you’re lucky, your passion.’

13

Part I

Initial Literature Review

Chapter 1: Introduction

Chapter 2: Semiconductor Ecosystem

Chapter 3: Etymology of Hardware and Software

Chapter 4: Digital Hardware Flows vs. Software Development Processes

Part I: Initial Literature Review

Chapter 5: Research Design and Investigation

Part II: Research Design

Chapter 6: Emergence of Theoretical Model

Chapter 7: Emergent Toolbox of Patterns for SoC Project Organisation

Chapter 8: Validation of Theoretical Model

Chapter 9: Conclusions

Part III: Theoretical Model and Solutions

14

Chapter 2

Semiconductor Ecosystem

“ . . . when they were first invented, nobody could have imaginedthe possible applications of shrinking transistors down until theywere almost invisible—in slabs of processed sand!—and then wiring

millions of them together into a circuit. Turing, von Neumann,

Shannon and Shockley couldn’t possibly have anticipated many of the

modern-day applications of their work—WiFi and the web, iPods and

the Internet. ”— MARTYN AMOSTaken from ‘Genesis Machines: The New Science of Biocomputing’, Atlantic

Books, London, 2006

2.1 Introduction

THIS chapter discusses the ecosystem of the consumer electronics marketplace for semiconductordevices. The reason for doing this is to establish a view of the competitive landscape within thisindustry, and to clearly identify the distinct business models involved and their related commercial

pressures and requirements.

First, I describe the various functional roles in the ecosystem, and how they correspond to

business models. Then, I present an insight into semiconductor manufacture, and the proliferation

of embedded semiconductor software. Finally I discuss the global landscape for semiconductor

development in which Irish semiconductor companies compete.

2.2 Semiconductor Market

Semiconductors are tiny devices made from silicon. The semiconductor industry produces

microchips, or integrated circuits (“ICs”) that are required to build most common electronic

products.

15

http://en.wikipedia.org/w/index.php?title=Special%3ABookSources\&isbn=159020039X

2. SEMICONDUCTOR ECOSYSTEM 2.2. SEMICONDUCTOR MARKET

These devices have enabled tremendous changes to modern society—improving the safety and

comfort of our standards of living, and providing us new forms of interactive entertainment. Writing

in Byte magazine on the 25th anniversary of the microprocessor, Wayner (1996) describes how, after

the arrival of devices ‘small enough and cheap enough to fit inside business machines, toys, appliances, tools,

and entertainment devices’, the ‘world hasn’t been the same since’. The same article predicts that its

analysis of the microchip’s ‘impact on society is only a snapshot in time. The revolution continues’.

The market for semiconductor products is endemic in the value chain of the electronics industry.

The virus-like connotations associated with the word endemic are deliberate—as silicon capacity

has increased and expectations of functionality have swollen, developers have relied more and more

on ever-mode sophisticated components of software logic for reasons of time to market, risk and

flexibility. Kumar (2008) describes how:

‘The semiconductor industry has been a fertile ground for the nurturing electronics industry. Overthe last 40 years, various different markets have driven the growth of the industry and haveprovided the impetus for innovations.’

The market for semiconductors has expanded by 14% per annum on average between 1960 and

2002, while the cost per function have historically fallen by approximately 25% (Wojahn, 2002).

Sales for semiconductor amounted to US $143 billion in 2001, and US $272 billion in 2007—as

shown in Table 2.11.

Table 2.1: Semiconductor Market Size

Year % Growth Amount(US Dollars)

2007 — $272.0 billion

2008 -2.0% $266.6 billion

2009 -9.4% $241.5 billion∗

2010 6.4% $257.9 billion∗

2011 10.8% $284.8 billion∗

∗Figures for years 2009 through2011 are forecasted estimates.Taken from LaPedus (2008a,b).

1For up to date figures, the Semiconductor Industry Association (http://www.sia-online.org/) publishes its GlobalSales Report, a three-month moving average of sales activity.

16

http://www.sia-online.org/


IP Creation

Chip Manufacture

Product Design

Sales Channel

Design Services Intellectual Property Provider

Brand

Design House

Packaging House

Foundary Partner

ODM

OEM

ASIC Design

Figure 2.1: Semiconductor Ecosystem

The semiconductor market growth rate, having been impacted in recent years since the global

economic downturn, represents roughly twice that of the electronics industry in general. The reason

for this faster growth rate is the increase in semiconductor content in end electronic products.

Semiconductor manufacturing processes are very sophisticated and there is a significant capital

investment in plant and equipment. The semiconductor fabrication plants (“fabs”) require larger

and larger quantities of production to break-even.

In order to achieve this, they need the new product designs that will excite and entice the end

markets. As these designs become increasingly intricate, the investment in doing the design work

internally quite often becomes prohibitive. To address this, a very sophisticated ecosystem has

emerged around the development of semiconductor systems—my own interpretation of which is

illustrated in Figure 2.1. In the ecosystem, each oval represents a functional aspect/role, and not

necessarily a discrete organisation. Depending on their business models and technical competencies,

companies may take take on many roles, or specialise in as few as one.

Wolf (2006) states that:

17


‘The embedded computing application space is growing and will continue to do so for quitesome time as we figure out better ways to design new microprocessors and better ways to designembedded software.’

2.2.1 Intellectual Property

Intellectual Property (IP) creation is the function of generating hardware and software designs to

address market requirements. With more discerning consumer markets comes the demand for

more sophisticated featureful product, in tandem with shortening market windows. This results in

potential competitive advantages to being first to market2. To address this demand for accelerated

design cycles, the chip manufacturer has a few choices: either develop the intellectual property for

the design internally, out-source it to an intellectual property provider (paying a license fee and

potentially a royalty per unit volume), or underwrite its development via a bespoke design services

company. Many companies are providing semiconductor IP—essentially reference designs for what

are anticipated to be large volume consumer devices and peripherals. Intellectual property can

consist of analog hardware, digital hardware, and software—all in either formats of source code,

obfuscated source code, or libraries.

2.2.2 Chip Manufacture

The chip manufacturing function has a number of distinct aspects to it. With modern sophisticated

System-on-Chip products, IP from a variety of sources (internal, from IP, open source, etc.)

providers is integrated into a single design. This design is validated and verified through various

techniques. It is floor-planned in terms of the placement of various functionality in silicon, and a

final layout created. The layout is in the form of a vector graphics file format (GDS-II) that the

foundry uses to create the silicon masks and wafers.

Once the design reached a sign-off as being fit for purpose, it is “taped-out”. Tape-out is a

historical term, with its roots from a time when the design was stored on magnetic tape. Tape-

out today involves in the layout vector image of the silicon being transferred electronically to the

foundry.

Semiconductor ASIC devices are incrementally created as a number of layers—some of which are

the actual chemical dopings for the transistors, the rest of which are various layers of insulator and

2Although serial-entrepreneur Jason Calacanis remarked that ‘the first guy up the hill gets the arrows’ whendiscussing early mover advantage in business (Calacanis et al., 2008).

18


Figure 2.2: 8-inch silicon wafer during manufacture.Image courtesy of Taiwan Semiconductor Manufacturing Co., Ltd.

Figure 2.3: Wafer is cut into separate silicon die, which are then individually wire-bonded and packaged

19

http://www.tsmc.com/


Figure 2.4: 65nm Digital Radio ASICSilicon die encased and wire bonded in a QFN plastic package.

Image courtesy of Frontier Silicon Ltd.

Figure 2.5: Decapped ASIC in QFN package, showing bond wiringThe silicon die is approx. 18mm2, and the plastic package is approx. 100mm2.

Image courtesy of Gavin Marrow

20

http://www.frontier-silicon.com/


logic in metal. A mask set corresponds to the collection of masks required to create each of these

layers through some form of ultraviolet etching / acid washing. Creating a mask set requires very

precision engineering. Current state of the art technology is 32nm, in which the track widths are

below the wavelength of the ultraviolet light. This requires some innovating diffraction techniques

in order to successfully etch the tracks at the required tolerance levels. As a result, it is a very

expensive process. The cost of a mask set varies depending on the process technology, but the

figures in Table 2.2 are a rough approximation for 2008:

Table 2.2: 12 inch IC Mask Costs—2008

Technology Mask Cost Wafer CostProcess (US Dollars) (US Dollars)

130nm $500,000 n/a

90nm $800,000 $1,000

65nm $1,000,000 $4,000

SOURCE: Interviewee David, personalconversation, April 2008.

The cost of a 12-inch wafer is approximately $4,000, so the main upfront costs are the mask set.

Subject to anticipated volumes of chip sales, the mask set may or may not be the significant portion

of the overall project cost.

Depending on the size and shape of the integrated circuit being etched, each mask will yield

a number of individual silicon ICs, called die. Each die needs to be tested, as the process usually

performs to a certain level of expected yield. Good die is then packaged at a Packaging House in

plastic with bond wires added. This is the visual form factor that people are most familiar with when

silicon or computer chips are mentioned. Packaged parts are tested again to ensure the packaging is

okay. There are various packaging format options, but the rule of thumb is the smaller the size, the

more sophisticated and costly the packaging technology.

Prototype hardware may often be scheduled for a shuttle run, to lower costs, as only small

quantities are required. Shuttles are a mechanism by which the fabrication plants fill temporary

gaps in their production lines. Each shuttle wafer may contain silicon from a number of vendors.

Due to the extra organisation overheads involved, shuttle runs cost slightly more than a full wafer,

but each vendor shares proportionally in the cost thereby reducing the individual outlay and risk.

For example, one tenth of a 12-inch shuttle wafer (90nm) could cost $90,000 whereas a full wafer

could cost $800,000 (SOURCE: Interviewee David, personal conversation, April 2008).

21


Another consequence of the additional organisational overheads of shuttle runs is the inflexibility

on the date the shuttle “leaves”—if a company does not have its design ready in time, the shuttle

will leave without them.

With such high costs in the creation of the mask, it is important that every possible preventative

and anticipatory measure is taken to ensure the success of the design. The cost of the mask set is

typically apportioned across the anticipated market sales volume of the chip, so without a successful

product it is important to recoup this significant investment expenditure.

2.2.3 Product Design Companies

Successful packaged parts are either sold directly to product design companies (“chip-down” sales),

or, depending on the complexity of the part and its required external and ancillary circuitry, as

modules of chip components for ease of integration. The competitiveness of a particular part is

determined by a number of factors:

• Its technical competitiveness—can it compete with solutions from peers within the

marketplace?

• Its direct cost—which consists of silicon and packaging costs, amortised IP licensing costs and

royalties, patent pool licenses, and margin;

• Its size—size affects cost (wafer cost divided by number of chips per wafer determines the

silicon cost of the chip), and for certain market segments (e.g. small form-factor mobile

handsets) it also affects technical competitiveness;

• Its power consumption, particularly for mobile devices but also increasingly to address eco-

aware end consumers (SOURCE: Interviewee David, personal conversation, April 2008).

These factors and others are discussed in greater detail in Subsection 2.2.7.

The number of external passive and active components that a product design company must use

to successfully integrate SoC product into their design has a direct bearing on the bill-of-materials

costs of any product that incorporated it; and, with typical volumes in the millions for successful

chips, even a couple of cent per component adds up pretty quickly.

Hardware developers (and to some degree also embedded software developers) need to be

cognisant of the implications of their actions on the BoM cost through the realisation of the design.

Anderson (2008) elaborates further on this:

22


‘Due to the desire to keep costs down, embedded developers need to squeeze every last bit ofperformance from the hardware. . . So, at least some embedded designers need to understandthermal loading and MIPS/watt ratios.’

Chip-down designs are cheaper for larger volumes, but require greater technical acumen

on the part of the product manufacturer. Original Equipment Manufacturers (OEMs) take

product reference designs from a Design House and manufacture product from them, including

creating consumer facing plastics enclosures, and shrink-wrapped product with manuals etc.

Original Design Manufacturers (ODMs) are like OEMs, with the exception that they are

capable of taking semiconductor modules or chips, and creating product themselves. In general,

companies that sell mobile cellular phone devices are incredibly sophisticated and capable of

handling sophisticated levels of technology integration—whereas some other commodity consumer

electronics manufacturers are just about able to handle board manufacture.

Sometimes the large OEMs become well known consumer brands, such as Samsung, Sony, LG.

Othertimes, established brands buy devices directly from the OEMs or ODMs, and perform the

branding and marketing themselves.

2.2.4 Characterisation

Once silicon returns from the fab, it needs to be characterised for mass production across a variety

of metrics and measures:

• Correct functional operation—despite the rigorous level of testing, verification and validation

pre tape-out, there is no guarantee that what was taped-out is functionally correct;

• Power consumption in various operating use-cases (generally it is only possible to crudely

estimate power consumption values through the use of spreadsheet models pre-tape-out);

• Performance of any analog components, particularly analog-to-digital converters, RF tuners,

high-speed PHYs etc.;

• Operation across various temperature ranges;

• EMC emission testing.

At the same time, production testing procedures need to be established in order to quickly test

packaged parts on the production line. This testing is usually charged by the second, so the quicker

product can be tested for basic functionality and wiring, the better.

23


With all these new electronic features and components comes, of course, the need for extra

software (complexity) to control it.

2.2.5 Embedded Software

Embedded software is found throughout in the modern world. It is used to control many different

electronic products that are not normally considered “computer” products such as televisions,

DVD players, automotive systems, flight control and navigation systems, mobile phones and digital

cameras. The embedded software market is a large market, estimated to be worth around $23

billion in 2003, as shown in Figure 2.7.

Software has been described by the International Technology Roadmap for Semiconductors

(ITRS Update, 2008) as ‘an integral part of semiconductor products’, with software design productivity

recognised as ‘a key driver of overall design productivity.’ Furthermore, ‘embedded software . . . has emerged

as the most critical challenge to SOC productivity’ (ITRS Update, 2008).

Aart de Geus, chairman and CEO of EDA company Synopsys (as of 2009), noted that:

‘The growth of software has been faster than hardware and today (2008), semiconductorcompanies are hiring more software engineers than hardware engineers. This brings greatopportunities and huge challenges. Thinking that “software is great, because it’s easy to change” isa recipe for disaster when people make little changes and, before you know it, everything becomesvery difficult to verify . . . Very complex systems need (an) enormous amount of prototyping andverification.’ (Ben-Artzi, 2008)

Borgstrom and Gopalan (2009) explain that whilst ‘embedded software used to be a minor or

nonexistent deliverable for typical semiconductor devices’, at 45nm and beyond ‘software accounts for a

full 60 percent of total chip-development cost, with major implications on how chips and systems are verified’.

Wolf (2006) suggests between 500,000 and 800,000 people were employeed in 2006 as embedded

computing programmers. In addition, the increasing proliferation of electronic media within the

home (e.g. digital cameras, MP3 players, home media centers, mobile digital TV) is driving a new

wave of growth within the consumer electronics segment of the industry.

Wolf (2006) describes how:

‘Embedded computing sits at the intersection of computer science and engineering. It serves as thepillar that holds up the bridge connecting computer science with traditional engineering.’

Embedded software usually executes on internal micro-controllers or Digital Signal Processors

(DSPs) used to control other hardware components. These platforms are often difficult to develop

and test during the development cycle, and equally difficult to replace and repair when deployed in

the field—for reasons of cost, accessibility, etc.

24


Figure 2.6: 65nm ASIC—bare silicon die

semiconductor development in ireland: reducing development...

Documents