MODES Route - 27may98

ESPRIT PROJECT 20.592
OMI/MODES
Modular MicroElectronic-System Design
- OMI/MODES-
The ModesRoute Method
Written By: Ian Phillips
Mitel Semiconductor
Issued By: Colin Tattersal
Mitel Semiconductor
Project Coordinator
Delivered By: Colin Tattersal
PMC Chairman
Mitel Semiconductor
Deliverable id: TR:1.2.4
Document code: RDS/ESG/008-20
Issue Date: 27 May 98
Availability: Public
This is an unpublished work the copyright of which vests in the Author. All rights reserved.
The information contained herein is the property of the Author and is supplied without liability
for errors or omission. No part may be reproduced or used except as authorised by contract
or other written permission. The copyright and the foregoing restriction on reproduction and
use extend to all the media in which this information may be embodied.

Esprit Project No 20.592 OMI/MODES
Mitel Semiconductor
RDS/ESG/008-20.x1 Page No 2
Print Date: May 31, 2013
Change Summary:
Issue No Description of Changes
.x1 (x1) First Pre-Issue : Released for discussion by ModesRoute Work-Group.
Issue number .x1
Number of pages
Author I Phillips
Date 27 May 98

Mitel Semiconductor
Table of Contents Page No
1. Purpose................................................................................................................................. 4
2. References & Related Documents ........................................................................................ 4
3. Abbreviations ........................................................................................................................ 5
4. Introduction ........................................................................................................................... 6
4.1 Silicon Capacity - The Motive Force ................................................................6
4.2 The ModesRoute Method.................................................................................7
4.3 System-Level Products ....................................................................................7
4.4 Development....................................................................................................7
5. ModesRoute Scope............................................................................................................... 9
5.1 Systems and Components...............................................................................9
5.2 Unique features of Systems...........................................................................10
5.3 Short TTM......................................................................................................13
5.4 Productivity ....................................................................................................14
5.5 Right-First-Time .............................................................................................15
5.6 ModesRoute Scope … Summary...................................................................15
6. The Design Process.............................................................................................................. 16
6.1 Products and Aspects, Components and Elements.......................................16
6.2 The Development-Cycle.................................................................................17
6.3 The Design-Step............................................................................................18
6.4 Hierarchy in Design........................................................................................20
6.5 Formalised Design-Steps...............................................................................22
6.6 Formalised Implementation............................................................................24
6.7 Formalised Verification...................................................................................25
6.8 Design For Verification...................................................................................26
7 Formalised Requirements ..................................................................................................... 28
8 Partitioning and MacroFunctions........................................................................................... 30
8.1 The 'Minimal Hardware' MacroFunction.........................................................30
8.2 The 'Normal Hardware' MacroFunction..........................................................32
8.3 The 'Highly-Capable Hardware' MacroFunction.............................................33
8.4 Autonomy in MacroFunctions.........................................................................33
8.5 Architecture in MacroFunctions......................................................................34
9 The need for Debug .............................................................................................................. 35
10 Re-Use.................................................................................................................................. 36
10.1 Aspects of Reuse...........................................................................................37
10.2 Intellectual Property .......................................................................................38
11 Configuration Control ............................................................................................................ 40
12 The ModesRoute Diagram .................................................................................................... 41
13 Tool Mapping to ModesRoute ............................................................................................... 43
Appendix A : Quality Gateways ........................................................................................................ 45
Appendix B : ModesRoute Stages.................................................................................................... 48

Mitel Semiconductor
- OMI/MODES-
The ModesRoute Method
1. Purpose
This document is the consolidation of the ModesRoute Modular Micro-System Design Methodology. It is the
consolidation of the work carried out in the OMI/MODES Project (20.592), and the discussions and workshops that
have occurred within the framework of the project.
This is an open document provided to be (the basis of) an agreed route for the development and introduction of
MicroElectronic-System products, which because of its acceptance will be used by tool vendors as a road-map for
the required functionality and integration needs of future tools and interfaces.
2. References & Related Documents
[1] Modular MicroElectronic-System Design, V 1.0 15 Sept 95, Project 20.592, Technical Annex - Part 1 & 2
[2] ModesRoute Steering Document, TR1.2.1
[3] ModesRoute Steering Document, TR1.2.2 v1
[4] ModesRoute Steering Document, TR1.2.3
[5] SLI to dominate ASIC Market by the 2000, Dataquest report, Dec 95.
[6] Moore's Law. Attributed to Gordon Moore - Chairman of Intel Corp. 1965
[7] Joint MCC/OMI Hardware/Software Codesign Study Report - OMIMO
[8] Moose Document - User Manual v3.0
[9] RASSP Web pages http://rassp.scra.org
[10] EDA Industry Standards Roadmap - Sep 97
[11] System Designers Road Map to Million-Gate ASICs - Dataquest, Jul 96
[12] Patterns of Software Systems Failure & Success - Caspers Jones, ISBN 1-850-32804-8
[13] Dr L Hatton, Software Failures Follies and Fallacies. IEE Review March 97
[14] Software Engineering Book 3 : Open University : ISBN 0 7492 2199 2
[15] Mitel Semiconductor 2M transistor, SLI with two process engines & memory.
[16] Pentium II, 9.6M transistor (200 men 1 year quote in Microprocessor Report)

Mitel Semiconductor
3. Abbreviations
Architecture The outline of a likely implementation (High or Low level), which makes use of historic
and commercial judgement.
Component (See section 5)
Concurrent Development Development of Aspects/Components & the Product in parallel (ie not waiting for
components to be completed before working on the level above).
Development Process The repeatable act of developing an item. Development is seldom a true process,
which involves a large number of repetitions of the identical process.
Documentation The complete set of documents necessary for a Product. Including the commercial,
product support, design, quality and reference documentation
Deployment Support Tools Tools which support the subsequent use of a product, which, though not directly a part
of that product, enable the product to be deployed and thereby facilitate it reaching its
full market potential.
End-Product The item which is sold to the end-customer (Normally a consumer) and which results in
a prime revenue stream to the supplier.
Formal Methods Mathematical technique for proving the absolute equivalence between two items. In this
instance a high-level functional description and the description of a lower level of
implementation.
Functional Verification The act of verifying that the implemented functionality matches that required (designed).
MacroFunction A functional object, whose make-up is of hardware and software in variable proportions.
Manufacturing Test The act of confirming that the manufactured item is the same (or close enough) as the
one that was functionally verified.
MicroElectronic-System A System-Level Product whose functionality is implemented in a 'few' Micro-Electronic
devices (solid-state integrated circuits).
Product The item which is designed and which is subsequently to be reproduced and sold for or
in support of prime revenue
Quality An abstract concept encapsulating customer (end user) satisfaction.
Quality Gateways Standardised quality levels for the release of information with regard to the stages of
development of a Component / Aspect or Product (or Capability).
Solid-State-System (SSS) A System-Level Product whose functionality is implemented in a 'few' solid-state
integrated circuits.
Sub-System (See section 5)
System (See section 5)
System-Level-Integration (SLI) An IC which incorporates one or more processor engines, significant amount of on-
chip memory and >100k used gates (DataQuest '95). This may be considered as (one
of) the hardware platform of the SOC … without the software component it cannot be a
complete System, but even with it, it might only be a Sub-System or Component.
System-On-Chip (SOC) A 'chip' which incorporates within itself the core functionality of the end System-
Level Product.
TTM Time from identification of a market opportunity, until the closing of the associated
(valuable) market entry window. Also used to indicate maximum time for Product
Development.
Use-Cases The examples of use and misuse of an object that will be used as pass-fail criteria for
the acceptance of its functionality against requirement.
Use Methods The (documented) way that the Product is intended to be used.
Views (of an object) The different descriptions of the same object, deployed individually
different tools or processes forming the Development Process.
VSIA The Virtual Socket Interface Association.

Mitel Semiconductor
4. Introduction
The ModesRoute is the result of a three year programme of co-operation between six European organisations,
each of which is involved in System-Level product development in their own, different, context.
Mitel Semiconductor
Cheney Manor
Swindon
SN2 2QW
United Kingdom
http://www.gpsemi.com/
Etnoteam SpA
Via Adelaide Bone Cairoli, 34
I-20127
Milano
Italy
http://www.etnoteam.it/
TAC AB
Jägershillgatan 18
S-213 75
MALMÖ,
SWEDEN
http://www.tac.se/
UMIST
Dept of Computation
Sackville Street
PO Box 88
Manchester
M60 1QD
United Kingdom
http://www.umist.ac.uk/
Universitá degli Studi di
Milano
Dipartimento di Scienze …
… dell'Informazione
Via Comelico 39
I-20135
Milano
Italy
http://www.unimi.it/
Visual Tools
Almansa, 62
E-28039
Madrid
Spain
http://www.vtools.es/
By bringing together these disparate organisations and through watching each-other work, the OMI/MODES
project has been uniquely positioned to gain an overall perspective of System-Level design in a MicroElectronic
context, appreciating the differences between us and the commonality of approaches and problems. Accordingly
the ModesRoute represents a unique System-Level view on that process …
4.1 Silicon Capacity - The Motive Force
Nearly 30 years ago Gordon Moore gave us Moore's Law [6], a yardstick for the Integrated Circuit industry
stating that silicon logic capacity would double every ~18 months for the foreseeable future … Over the
years this has shown to be true. A factor that he missed, was that clock speed would also increase,
combining to produce a doubling of functionality every ~12 months.
This has lead to a ~1000 fold increase of functionality in Integrated Circuits (ICs) during the least decade
… and the indications are that we should expect similar expansion in the next.
On the immediate horizon, 0.18u IC technology will make 120M transistors [10] available for product
application, raising the question, just what they can all be used for ? The reality seems to be that many of
the things that we currently recognise as systems could be implemented on 120M transistors … or the 1B
transistors that a 'small-handful' of devices makes available !
The opportunity that this provides is truly awesome … but so is the challenge of design. "MicroElectronic-
Systems" are much, much more than just bigger chips ! ("System-On-Chip" and "Solid-State-System" are
terms that have emerged into common usage … they are of similar meaning and may be considered as
synonymous).
Evidence available from several sources, indicate that today's 2-10M transistor component designs 'take' ~
50-200 my to implement. Even linearly interpolating (optimistic) this equates to 2000 my at 100M
transistors ! However, by the time that the Systems aspects of Software, Architecture and Validation are
included this is unlikely to be less than 6000 my. The impact on TTM and cost is also going to be severe.
Clearly using our existing 'component-based' and 'incremental' design methods, is not going to be
adequate ; The motive for finding a System-Level Product development method, and thereby achieving
orders of magnitude improvement in productivity, is high !

Mitel Semiconductor
4.2 The ModesRoute Method
Using the divide-and-conquer approach that has been shown to be successful throughout history, the
MODES project chose to address the methodology of System-Level design separated (at first) from the
implementation tools. Of course to do this means observation of how people address the problem today
… inevitably using tools to achieve their ends. The trick is to look beyond the implementation at the
underlying method.
The ModesRoute is a Method, a procedure which if applied, will result in the achievement of an objective
… in this case the development of a MicroElectronic-System. The ModesRoute is a 'diagram' which
separated from the Implementation, can be optimised in isolation from the Tool(s) that do/will supports its
needs.
Subsequently the Tools can be assessed for their ability to perform the required functionality and then set-
up appropriately to deliver that functionality to the user. In this way, the raw-facilities of the tool are not
confused with the functional objective to which it is deployed.
To draw this diagram, we must first comprehend the characteristics of a MicroElectronic-System and also
the scope of the Development task …
4.3 System-Level Products
The concept of System is one that is conceptually appreciated by everybody … and yet its definition is not
readily subject to analysis. It is very difficult to define a system, in any fixed context as practically
everything can be described as both a system and also as a component in differing contexts. And yet,
perversely, there is sufficient difference that the words and meaning still persist.
In the search for clarity the following definitions (though apparently being humorous) are quite central to
the theme …
• A System can be defined as an entity that is too complex to get right first time !
... quote at DAC 1996
• An entity suspected to depend on the operation of interacting objects !
... interpreted from J Korn INCOSE 1997
… Essentially a System is a complex product. We can surmise that it is the result of development
activities across the full 'sphere' of experience … involving hardware, software, and human interface
issues … and their acceptable interplay.
4.4 Development
The role of development is to move a product from an idea to a, customer satisfying, manufacturable
reality, in a timely cost-effective manner.
For a Component, the product may be completely described by a simple algorithm, the Requirement
Specification. Its implementation in a single, fixed function, chip is readily verified as achieving the
requirements … thus satisfying the customer. Its implementation is readily verified for manufacturability as
it either works or does not. Because of its regularity, ASIC approaches may be deployed to manage cost
and time.
For a System-Level Product however, it is much more difficult to define the requirements, establish
customer satisfaction and quantify manufacturability. Firstly, the full details of the requirement are not
known at the start of the development. Secondly, that it is not easy to verify that the object that was
created is the one that was specified … and even more important, it is what the end-customer wants.
Finally, its manufacturability is difficult to assess, because all of the product is likely to be broken in some
respect, yet most of it is perfectly acceptable to the end-customer. The uncertainty of the product and its
wide scope will effect the control of both cost and timescale.
… The role of Development is unchanged, yet the methods for achieving it for a System-Level
Product are significantly different.

Mitel Semiconductor
This outlines the context of the MODES Project and the ModesRoute, and the themes outlined here
are returned to and elaborated upon, several times in the text that follows …

Mitel Semiconductor
5. ModesRoute Scope
Before the ModesRoute can be 'drawn' it is necessary to have a good understanding of its span of authority. To
have a clear understanding of what is within its scope and what is not !
5.1 Systems and Components
At first appearance, the prospect is onerous … if a System can by 'anything' then surely we are talking
about the development method for anything ! It takes an act of faith to say that the design process for
'anything' is essentially the same (Which I believe to be the case) … but to be on the safe-side, it is
reasonable to restrict it to Systems which are targeted at MicroElectronics (ICs), for implementation.
Similarly if we acknowledge that development is the process of taking a System from concept (idea) to full
manufacturing readiness, then it includes techniques beyond our frame of reference (eg: Conveyor belt
and flow soldering techniques !). So again if we acknowledge the wider sphere, but are prepared to
restrict our selves to the MicroElectronic context, then we can usefully proceed.
Fig 5.1: Architecture of a MicroElectronic System
A useful and generic definition of a System is :-
1. A System is a complex entity which contains Components or Sub-Systems within it and is complete
in its context, delivering complete functionality to its interface.
2. A Sub-System is a System which though complete in its context is identified as forming a part of the
higher-level System which is the focus of attention.
Equally important is the definition of its 'partner', the Component :-
3. A Component is in some way functionally incomplete or is an encapsulation of 'atomic' behaviour.
Accordingly, MicroElectronic Systems :-
4. MicroElectronic Systems are Systems where the Core Functionality (That part of the functionality
which is not mechanical or simply functional) is implemented in a 'few' Microcircuits …
… More important than the actual number of devices involved is that, at the time
of development, its System-Level functional requirement is the guiding constraint, and the
achievement of it, is the indication of completion.
… The MicroElectronic System will normally have an overall architecture consisting of a Central
Processor, Instruction and Data Memory, one or more Co-Processors and an External Interface. It will
have Temporal constraints and deliver complete-in-context functionality at the interface. (See Fig 5.1)
Main
Execution
HW
Co-ProcessingExternal IO
Interface
Main
Program &
Workspace
(Memory)
Temporal
Constraints
Delivers Complete Functionality

Mitel Semiconductor
Undoubtedly there is scope for all of these definitions to be refined and improved, they do exhibit a good
match with 'common understanding' of the terms and their application, so are believed good enough for
use at this time.
5.2 Unique features of Systems
From these definitions it is possible to make some observations about systems and see how they match
with reality … and indeed to see what valuable observations may be extracted at this time.
The first observation is completion in context. That an object recognised as a System does the job
expected of it completely. A MicroElectronic-System would differ from this only in that when the physical
interface is taken away, that the 'system-functionality' is provided by the MicroElectronics within it. This is
easy to appreciate in the case of a portable telephone, the case, keypad, microphone, battery, etc, do not
directly contribute to the system functionality, only peripherally … it would be readily possible to change
them for others without changing the operation of the phone. It is possible to imagine systems where this is
not the case. A car is such an example, when you take away the mechanics, the object loses its
functionality.
However, though the microphone may be considered as a Component or Sub-System to the portable
telephone designer, it is a System in itself to the microphone designer ! The same argument applies to the
portable phone, which is a system to the phone designer yet is a Component or Sub-System to the
network provider. So in the case of the microphone, we might reasonably expect that it is a Sub-System
itself … principally because it is complete in its context, it is designed to be a part of a larger system.
Fig 5.2.1: The changing focus of the MicroElectronic Product
A Component on the other hand is always incomplete … though to prevent the case of attributing physical
properties to it, the specific 'atomic behaviour' is excluded. Thus a resistor is a component as is the plastic
case of the portable phone. Interestingly a microprocessor without program memory and code is also a
component !
The notable implication of this is that many of the most complex MicroElectronic Products we design and
produce today are Components, not Systems ! Products like PentiumPro, the huge DRAMs, 3D
Rendering Engines and MPEG encode/decoders are components … which means that the drivers being
used for the technology and the design tools are not the drivers that System-Level needs !
The difference between Component Design and System Design must therefore be that with System-
Design, there is no further Product Development nor further opportunity to 'get the product right'.
Accordingly the design process for System-Level Products must start with a definable End-Product
functional need and, end with the implementation of an economically viable, manufacturable, customer

Mitel Semiconductor
satisfying End-Product reality … If we start any lower, or deliver any less, then our Product it is only a
Component !
It is currently fashionable to think that a System-Level MicroElectronic product consists of Hardware and
Software components. Whilst this may be an adequate observation of a System-Level product, it is not
enough to describe the elements that have gone into its development ! Architecture, Documentation,
Deployment Support Tools, Use Methods, Functional Verification, Manufacturing Test, Quality, TTM and
Cost are all elements of the design process. It may be argued that these are also elements of a
Component design process as well, but the scale of many of these are significantly different between the
two examples.
CUSTOMER
requirements
analysis
specification
system design
CUSTOMER
acceptance testing
system test
system integration
user needs
specification
user
requirements
system architecture
and subsystem
specification
module
specification
delivered
system
integrated
system
validated and
verified system
tested
subsystem
tested module
module
code
subsystem
integration and
test
subsystem
integration and
test
subsystem
integration and
test
detailed designdetailed designdetailed design
module
implementation
module
implementation
module
implementation
module testmodule testmodule test
delivered system
meets user needs
system meets
user requirements
system agrees
with specification
subsystem agrees
with specification
module agrees
with specification
Fig 5.2.2: The V software development life-cycle from a testing viewpoint
Take for example the Architectural aspects of a NAND gate … they are all physical and they are readily
captured. The architecture of a Multiplier is significantly more complex and must take into account
additional features of performance, test, power and size. Similarly the task of Verification of functional
conformance (establishing that it does what it is supposed to do under all combination of inputs) is hugely
different … as Intel will undoubtedly remember with their Pentium problem in 1996.
… If anything, the fact that Components exhibit the same design elements confirms the concept
that development of 'anything' involves the same process steps … just that they are not always the same
size !
Fig 5.2.1 is extracted from the MCC/OMI CoDesign report [7]. It is overlaid with the increasing silicon
capacity with time and serves to illustrates the problem … that as the silicon capacity increases with time,
the scope of the design process expands from the lower-levels of implementation details, to include the
Architectural issues … previously the domain of our System-Integrating customers.
It is significant to note, that despite the increased capacity of silicon, the actual low-level implementation
tasks have become significantly smaller in magnitude … This is attributable to the improvements in tools
and methods in this area. It is valuable to note however that the additional 'bubbles' are also becoming part
of the design task … and most notably the System-Level ones are growing larger ! The need to focus on
these areas is now paramount as further attention to the lower-levels will now lead to significantly
diminished returns in the larger context of System-Level design.

Mitel Semiconductor
Though Figure 5.2.1 apparently 'says it all', in reality it only illustrates 'half' of the problem. The task is
considered to be demonstrably completed following the (silicon) implementation stage … It includes at-a-
stroke all of the verification, qualification, test and reproducibility issues that may be a formality for simple
digital designs, but are certainly not for the more complex system-level products. In the 'software world'
[14], it is quite common to refer to a products Life-Cycle, and a popular illustration is the 'V-diagram' (Fig
5.2.2). This has a progress from left to right, and top to bottom to top. The first part of which is concerned
with the identification of a products Requirement and the increased detailing of the proposed
implementation. The second part is concerned with the progressive Verification and release (and
maintenance) of the product … The actual Implementation, (module code) is a 'point' at which a
compilation process (or formalised translation to another existence) is done.
The V-Diagram encapsulates development 'responsibility' for Product creation from its basic origins
through to and including the delivery of the end product. It identifies the progressive Detailing and
Verification phases, and the Implementation singularity between a 'modelled' world and 'reality'.
We should ask why Fig 5.2.1, the traditional hardware view, does not recognise the 'back-end' tasks ? And
we would expect a MicroElectronic System to be any different to a Software System, simply because its
origins are in the increased functional capacity of Silicon ? The answers are respectively ; That the
omission is from history, where gate-level functionality was the measure of completion ! … There is no
difference between the systems !
Fig 5.2.3: Product Life-Cycle … with a hardware 'angle'
So Fig 5.2.3 is particularly valuable, being an independent rendition of the 'V-diagram', given an 'IC
hardware' flavour by its author, a Mitel engineer, M Dunk. Though its exact interpretation is open to
discussion, it does demonstrate the requisite features though some of the terminology is different.
Interestingly, it is already the case for the higher-level System-Hardware world (Eg:TAC), that the V-
Diagram is already in use … seemingly the IC hardware has been something of an exception until now.
Perhaps most important from a Si context, it shows that no matter how complex the actual Design
(Detailing-Phase) task , that the 'Implement' stage is only 'half way' though the process of development !
Overall, it illustrates two important messages …
1. That the Product delivered is expected to be the product Specified !
This is fairly obvious, but I will spell it out … If you Request a gate-level design, then you are
happy with a gate-level implementation. The ASIC world has been dominated by this level of
development. The customer specifies a netlist, the ASIC house delivers a functioning
equivalent of the netlist on silicon, verified by a logic tester. The customer accepts all
functional responsibility and all 'higher level' architectural and debugging problems.
For higher level products, however, if they are specified at Behaviour level and above, then
the end product must be delivered at the same level ! It is not acceptable to specify a

Mitel Semiconductor
'Calculator' requirement and deliver a logic circuit … the circuit must have been Verified to be
a 'Calculator' by the design authority and the correlation between the Functionality and the
Manufacturing Test established and agreed.
… The implication of specifying and delivering a System-Level Product is significantly
different to that of the Component-Level product
… The ovals, added later, illustrate another important message, that the increasing
'capacity' of silicon ICs lead to the inevitable inclusion of increasing System-Level context into
the products.
2. That the current improvements in Design Automation Tools only addresses the 'Specification
side' of the Life-Cycle … the Detail-Phase.
This is very significant, because it illustrates the fruitful-opportunity for optimisation of overall
aspects … and the limited returns for continuing a narrow-focus of the Detail-Phase alone.
… Of course we can and should examine the scale of the two parts of the Life-Cycle, especially
with regard to the System-Level product, to establish that our half-way premise is a true reflection of
reality. Evidence shows that for Component-Level Product, the Detail-Phase is larger than the Verification-
Phase; However, there is grounds for belief that for System-Level Product, though the Detail-Phase is
undoubtedly a larger task in itself, the Verification-Phase is of at least equivalent magnitude !
… The 'mix' of tasks in the development of System-Level Products are clearly changing, and
continued improvement of limited aspects in isolation will not significantly improve the overall development
process. The need for the identification of a System-Level Product Development & Introduction Life-Cycle,
the ModesRoute, is thus identified.
5.3 Short TTM
The traditional view of a System-Level Product has an implicitly complex introduction history. Systems
usually (always) evolve, from their first primitive roots to their (current) level of sophistication. Their life-
cycle completes when the product is no-longer necessary and further evolution becomes unnecessary.
The typewriter is one such product. The first implementations were complex and costly, the later models
involving significantly higher technology content were more costly to develop, but cheaper to reproduce.
They are now largely displaced by the PC.
We are surrounded by System-Level Products and most of them are in this loop somewhere ! Few items
are at the end of their evolution (and about to die-out) few are in their first iterations … most are in their
iterative improvement cycles.
Unfortunately the entry cost to enter a product market which is already iterating, is prohibitive, as the first
one (or two) products will inevitably be loss-leaders, prior to establishment of competitive technology.
Accordingly 'everybody' is looking for the valuable, new market opportunity with no established
competition. As most developers use the same market research organisations, it is inevitable that when a
product is identified, that the developer will not be alone, meaning that TTM and Competitiveness
(performance, cost & quality) are frequently the most important criteria … even where there is apparently
no competition !
… However, as even the best predictions of new markets are notoriously unreliable, then the risk
of success of the market associated with such developments is high, even if all other parameters are right !
In general, an existing company, who wishes to have a reasonable chance of 'hitting' a moderately
successful product must be prepared to start as many as ten developments. There are no reliable figures
available for this, but it is my impression that about 10% of architecturally new product developments
started are moderately successful, and about 1% very successful. For product evolution's, there is an
~70+% probability of achieving the same level of business ; ~10% probability of a significant increase of
business ; and 1% probability of achieving a very significant increase of business. Implicit in this is the
~20% probability of a reduced level of business … even greater if the evolutionary product does not
happen at all.

Mitel Semiconductor
The development of new systems has traditionally been a very protracted, ISDN has been over 20 years
getting to a competitive technology, GSM telephony has taken 10. DVD looks like it is going to achieve full
competitive supply in about 5. This can be considered as True TTM, the time from first product concept
identification to competitive market supply.
Clearly the longer True TTM's allow plenty of time for iterative improvement, but even the 5 year can be
effectively utilised with an aggressive market entry strategy. Assume a 3 year gestation period and utilising
a pipeline scheme. The 1
st
product arrives after 3 years and is delivered to an unready market. A 2
nd
generation product, started after ~18 months, benefiting from the lessons learned in the first development
and arriving at the market 18 months after the 1
st,
, just as the market starts to build. The first team, starts
on the the 3
rd
generation product which is delivered at year 4.5 into an established market … but now with
competition. Positive cash-flow may not occur until the 2
nd
generation is launched. A successful 3
rd
generation product is the gateway to longer term success in the market and may represent the first
Positive ROI … Slow, or sub-optimal, and you do not make a positive ROI, and die !
… The problem is that True TTM is reducing and will continue to do so until it hits the 1
Development-Cycle-time limit of 2-3 years, and at current rate of time-erosion, this will happen within the
next 5 years. In this scenario, no supplier will have any market to himself even the first time, so competitive
product has to be developed the first time. Further, because the market is (by definition) new, engineers
with appropriate 'background' cannot be bought-in, so the architectural skills have to be provided by the
use of appropriate tools. The evolutionary pipeline must still be established, but ~90% of players can
expect to fall at the first product generation.
… The pain for development of a speculative product must be minimal and the ability to reuse
components, even whilst they are being developed must be slick. With shortening True TTM, and need for
multiple and continuous simultaneous evolution's, productivity must reach an all-time high.
5.4 Productivity
The driving force for the System-Level Products and their development is the exponentially increasing
capacity of silicon ICs. Logic density is doubling every 18 months … functional density (including speed)
every 12 months. On the immediate horizon, 0.18u IC technology will make 100M transistors [10] available
for product application. Assuming that System-Level Products based on this capability will be designed as
an entity and will comprise between 1 and ~10 devices (the 1G transistor product is at hand). Though Si
capacity is the enabling technology, many of the transistors will be used for 'software' functionality or
memory. Here there is significant history which demonstrates that size (bytes) of software in any product is
also doubling on a 12 month cycle.
Though these System-Level Products when they are analysed (retrospectively), will be seen to consist of
only 'hardware' and 'software'. The correct conclusion to draw from this, is not that that hardware and
software is all that needs to be designed, but that those are the only parts of the development which are
explicitly included in the product shipped. TTM, manufacturability, architecture, quality, reliability, cost,
support tools, documentation, (etc) are invisible, but very real, elements of the Product which also had to
be designed, before the product earned its place on the PCB !
Evidence available from several sources, indicate that today's 2-10M transistor Component-Level Products
(ICs) 'take' ~ 50-200 my to implement, even linear interpolation (which is optimistic) leads to 2000 my
projections for 100M transistors devices. By the time 'Systems' aspects of Software, Architecture and
Validation are included this is unlikely to be less than 6000 my. Using conventional approaches, the impact
on TTM and the cost will be severe !
The necessary productivity will not come about through evolution, revolution is necessary ; System-Level
Products need System-Level design methods, supported by appropriate tools. The Method must cover the
complete span of product development and must encourage the use of reuse in all aspects of a products
life-cycle. To achieve 6000 my products measured against today's methods, from the order of 10 my of
effort requires ~600 fold improvement of productivity … reuse must pervade all aspects ; the complete
development process must be supported by competent tools … nothing less will deliver !

Mitel Semiconductor
5.5 Right-First-Time
The need to develop System-Level development of (relatively) optimised solutions in short time periods
essentially demands right-first-time performance. Is this a reasonable expectation for a System-Level
product development ?
This area is very tricky to quantify, but software systems have been designed in the past and the results of
these have been quantified … and there is grounds for believing that the lessons learned are applicable to
the development of systems involving hardware [12][13].
Dr Hatton [13] illustrates that for existing software products it is unusual for residual functional errors to be
less than about 5-10 errors per thousand lines of source code (5-10 /KLOC). This result, amongst many
others, is confirmed by Mr Jones [12]. This result is reflected in our own experiences of the use of PC's
and cars (etc), there are residual errors, which may or may not significantly effect the use of the system.
Indeed there can be errors which cause problems in 'your' use pattern which do not cause problems for
others. The practical implication of this is that we cannot expect a System-Level Product to be right, but
only to be acceptably right ! The consequence of this on the whole product release process and
manufacturing will be profound.
Whilst it is reasonable to expect that many of the errors will be convergent (effect tends to 'fade out') and
only a few directly divergent (effect tends to escalate, leading to major failure) ; convergent errors can
combine with each other in the huge state-space of a system to produce divergent behaviour. Because
errors are not intentional, their behaviour is not predictable, accordingly the use of large Alpha and Beta
trials are required to establish the error-content and nature by 'experimental' methods … Design by
iterative steps.
This situation was wryly encapsulated in a quotation at 1996 Design Automation Conference (DAC96) …
"A System can be defined as an entity that is too complex to get right first time ! "
… Though I would suggest deletion of the last two words !
The Software-System development world has moved on [13] and in an attempt to control the scale and re-
works involved in the Alpha/Beta cycle, has introduced 'formalised' design and 'code-reviews' which
combined with much smaller Alpha and Beta trials (An initiative lead by IBM and Bell , but now being
followed by Microsoft !), are proving a much-more effective tool … not to improve the overall residual
errors, but to get to the product end-point more quickly by reducing the iterations ! The 'formality' consists
of analysis-based design and step-by-step release and control, documented procedures and methods,
carefully and honestly followed.
It would seem to be reasonable that our system-level development must incorporate these best-practice
techniques if a right-first-time unified-methodology is to develop. It must also accept that the product (or
components thereof) whilst being less than perfect, yet may be perfectly acceptable in the end product's
functional context !
… Close enough is good enough !
5.6 ModesRoute Scope … Summary
1. Stars at System-Level Requirement Development …
2. … Ends at System-Level Product Delivery
3. Supports all-pervasive reuse.
4. Supports concurrent development pipelines.
5. Offers opportunity for huge productivity increase (x100 to x1000).
6. Concerns itself with Hardware & Software but also all of the 'invisible' components of a System-
Level Product and its development.
7. Recognises the hierarchy in System-Level Products.
8. Is focused on, but not restricted to, MicroElectronic Systems development.

Mitel Semiconductor
6. The Design Process
Closer examination of the design process of the System-Level Product identifies some concepts which are
elaborated upon in the following sections …
6.1 Products and Aspects, Components and Elements
When we look at System-Level Products we find that they have Aspects, which represent significant items
of development in themselves, and which may be in orthogonal technologies. For a typical programmable
Product, these Aspects would typically be (amongst other things) : The Silicon, The Boot-Code, The
Application Code, The Demo PCB, The Development Tools and The Design Manuals. Aspects are often
Sub-Products in their own right, and may be sold independently … they are not (often) sold together as a
fixed-kit, and there may be one Aspect (Eg: The silicon) which is the main target revenue-earner, yet the
others are a part of achieving that revenue. (See Fig 6.1.1)
Fig 6.1.1: Product & Aspect, Component & Element
Looking closely at individual Aspects, we find that they are made of Components which themselves have
Aspects (Which for clarity we will call Elements) and that the Elements of the Components contribute to the
different Aspects of the Product.
There is no definitive list of Aspects of a Product, nor Elements of a Component. Product evolution will
continue to introduce new Aspects and Elements as features previously outside of today’s product become
part of tomorrow’s deliverable.
The implication of this is that Aspects and Components are pseudo products in their own right and are
used in the higher-levels of the Product development. Accordingly their quality-status has to be established
and recorded before they can be released for use by those higher levels, and that quality-status must be
understood by the user (Take particular note, there is no requirement that the quality is ‘perfect’ only that it
is understood by both parties involved in the transaction).
Product
(Eg: Butterfly)
DevTool-Asp.
(Eg Compiler)
Si-Aspect
(Eg: SA024)
Doc'n-Aspect
(Eg: User Manual)
PCB-Aspect
(Eg: MAP Board)
Component
(Eg UART)
Component
(Eg ARM7)
CLA Hardware
Software
Audit Report
Elements - Of a Component
RTL Hardware
Documentation
Test Bench
SW-Aspect
(Eg: Drivers, SIFs)
Component
(Eg DMAC)
Component
(Eg MPC)
Aspects - Of a Product
Components - Of an Aspect

Mitel Semiconductor
The implication of this is apparently onerous layers of release stages and sign-off’s, which unless it is
supported by a Configuration Control Tool will become a major organisational headache.
6.2 The Development-Cycle
If we consider a Complex Product as comprising (many) Aspects, with each Aspect being composed of
Components each with (many) Elements (Fig 7.1.1.), then a hierarchy of design and release processes
must be involved. The good news is that despite their differences, the same general Method can be used
for their creation. This is illustrated in Fig 6.2.1. The Development task is entered with a specification,
which triggers a series of closely related development-tasks. The development-tasks are integrated and
tested against the requirements of the specification. Where it fails to meet the requirement, the
development tasks are ‘continued’ until conformance is achieved. Occasionally, the act of development will
uncover fundamental limitations with the specification and lead to its modification.
Fig 6.2.1: The Development-Cycle
During the course of development of a Complex Product, the component parts will be developed
concurrently with the products hierarchy, demanding information flow from the lower level items from the
'earliest stages', through to 'full-release'. Further, in optimised development environments, there will be
requirements for components to be designed for deployment in more than one higher-level product (in their
first implementations). This practical Concurrent Design and the methodology must recognise its
implications. By formalising the states and the quality implicit, information can be exchanged with the
confidence that it is what it claims to be … This data may be anything from none-functional to fully-
compliant (‘rough’ to ‘ready’) to support different functional and none-functional needs of the level above
(With care). The grades of the releases can be established universally as Quality Gateways (See Appendix
A), to be applicable to the development of all items, whatever technology is involved.
Figure 6.2.2 illustrates how 'quality' flows through a component based development. Quality Gateways are
used to extract data from a component development, before it is used at the next level (above). The quality
levels illustrated at L1 to L5, where L1 is minimal, and L5 is excellence. The hierarchical Product is of
overall status equal to the lowest of its component. Using the scheme, hierarchical users of information will
be in no doubt about the quality of the data that they are using from their suppliers … and by implication
the release status of the Product (or Aspect) itself.
… Of course all of this needs close monitoring and control to be effective.
(It is worth mentioning that this situation applies equally to the development of Capabilities, which can be
shown to have Aspects also constructed out of Components, with Elements. Indeed, the Components of a
Capability in many cases will be the same as those used in the development of Products !)
Integration
& Verification
Development-
Task
Release Audit
Release Criteria
* Specification
* Development
* Alpha
* Beta
* Version
'External'
Data
Specification

Mitel Semiconductor
Fig 6.2.2: The Waterfall of Quality
The Development-Cycles illustrated in 6.2.1 need closer examination to apply to the V-Diagram of System-
Level Design, to do this it is beneficial to develop some new symbols for the Development-Cycle itself, so
we can consider them in a bigger context. Figure 6.2.3 is a rotation and translation of 6.2.1 … and
incorporates an 'iconic' version for use in subsequent diagrams. The various forms will be used, as
appropriate, in the analyses that follow.
Requirement
Specification
Expansion /
Detailing
(Design)
Conformance
Testing ?
Implement'n
Description
N
Y
Fig 6.2.3: Alternative representations of the Development-Cycle
6.3 The Design-Step
Hierarchy is necessary because of the necessity to partition a task into smaller units. The size of the
smaller units may be determined by the need for productivity or the inability of a single engineer, or closely
co-operating group, to readily comprehend a greater one. In reality both of these are the same as the time
for implementing an object increases rapidly as it approaches the limits of comprehension. Accordingly we
introduce the idea of the Conceptual-Span, as representing the size of a task which is convenient to be
handled. A Complex Product (System Level) will inevitably comprise several (many) of these working
together to deliver the required functionality. The 'size' of a Development-Cycle is naturally that of the
Conceptual-Span, Fig 7.3.1 (Though this does not have to be a limitation, it helps to understand the needs
of hierarchy if it is assumed to be the case).
ProductAspect 1Component
Component
Component Aspect 2
L1
L4
L2 L5
L1 L1

Mitel Semiconductor
Fig 6.3.1: The Conceptual-Span & Development-Cycle
It is significant to remember that tool developments supporting this need to expand productivity this in line
with the rate of product complexity expansion ... currently doubling every ~12 months. Clearly this
demands introduction of increasing Conceptual-Span along with productivity of the Development-Cycle
itself. Overall, it is convenient to call the combination of a Conceptual-Span sized Development-Cycle (ie:
one which is not trivial) as a single Design-Step.
As most (all) System-Level products will exceed the Conceptual-Span of a single body, then task division
is inevitable … partitioning of tasks into smaller more readily comprehended and managed units. The
concept is easy … but the devil is in the detail.
When a task is partitioned, it must be understood well enough for the interfaces to be specified and
agreed. Frequently this is impossible, solely because the high-level functionality of the Product has not
been understood completely (!), a situation which is understandable because of our history, but is not
excusable ! Additionally, although the interfaces may subsequently be modified, it will impact all of the
occurrences of its use (especially if it is in any way universal). Also it may make sense that the partitioned
object has additional functionality added, to make it more suitable for re-use or re-deployment.
… Such partitioning rigor is the creation of Components, the behaviour, specification and use of
which is largely understood by common practice.
Requirement
Specification
Expansion /
Detailing
(Design)
Conformance
Testing ?
Implement'n
Description
N
Y
Conceptual
Span

Mitel Semiconductor
6.4 Hierarchy in Design
Fig 6.4.1: Hierarchy of Concept-Spans
Figure 6.4.1. illustrates the first two levels of a typical hierarchical product development. The output of the
first (highest) stage of analysis, leads into further (lower) stages of analysis ; the fist stages will be
architectural, the lowest stages will be implementational. A typical product, will comprise many lower
stages, as a single Concept-Span/Design-Step will frequently result in 3 to 5 lower-level requirements and
have 3 or 4 Concept-Spans of hierarchy … On this basis, a typical 4 Concept-Span deep product will
involve several hundred Design-Steps in total !
Many of the Design-Steps will be dedicated, but some will be considered valuable in a reuse context.
Figure 6.4.2 illustrates this. The output from a higher-level Conceptual-Span (the top one) is a group of
Elements (or Aspects), which are effectively requirements for the performance of a Component (by the
Customer), such that when they are all combined the functional requirements of the product (level) will be
met. The Component implementer also follows the same Conceptual-Span / Development-Cycle as a way
to achieve his objective … though he adds other things to make his Component more suitable for his own
purposes (principally ; manufacturability, quality, re-use and re-deployment). The result is that the
functionality of the Component is at-least that required by the Customer… or to put it another way, the
Component has features which are not specifically used by the Customer. Accordingly, the component
must have a test specification for its self, which is more extensive than the acceptance specification of the
Customer. As the Customers acceptance specification is his Requirement Specification, the Requirement
Specification that the Component developer uses is more comprehensive, and must incorporate the
Customers Requirement Specification as a sub-set within it. And the Component Requirement
Specification, becomes the Test-Bench used for determination of the completion of the development task.
Requirement
Specification
Expansion /
Detailing
(Design)
Conformance
Testing ?
Impl'n
Desc'n
N
Y
Conceptual
Span
Requirement
Specification
Expansion /
Detailing
(Design)
Conformance
Testing ?
Impl'n
Desc'n
N
Y
Conceptual
Span
Requirement
Specification
Expansion /
Detailing
(Design)
Conformance
Testing ?
Impl'n
Desc'n
N
Y
Impl'n
Desc'n
Conceptual
Span

Mitel Semiconductor
Fig 6.4.2: Inclusion of Additional Requirements
… For this reason, the Requirement Specification at the entry of a lower-level Conceptual-Span
are seldom the same as the ones at the exit of the higher-level (Customer) ones.
Figure 6.4.2 illustrates the growing complexity of a hierarchical product development. The higher level
(functional) Design-Steps result in a series of Requirement outputs, which feed into one or more 'lower-
level' Design-Steps. The Requirements from the higher step are included into the Requirements for the
lower-level item. In turn the lower level item produces Requirement Specifications … etc. etc.
If we look at the nature of the Requirement Specifications produced by the Design-Steps, they are of two
classes. Those that have an (already) identified translation to a physical implementation (C-Code, Gate-
Level, Resistor, etc), and those that do not. These are illustrated in the diagram as 'R' - Unrefined
Requirement, 'S' - Software, 'H' - Hardware. Where S & H are the identified translation and R, the
unidentified. It can now be seen that the process of Detailing involved in the Design-Steps stops when a
translation is identified for all Design-Step Requirements. After which it is 'just' a case of doing the
translations, combining the pieces, and the Product comes into being !
… Well … right to a degree ! We have implemented the Detailing-Phase of the V-Diagram, and
the 'singularity' of implementation … but we have not started on the Verification-Phase. Is it necessary ?
Well if everything was perfect, no, but in reality there are Requirement omissions and Transitional errors to
be evaluated !
Conformance
Testing ?
Implement'n
Description
N
Y
Additional
Requirements
* Additional Features
* Re-Use Parameters
* Standards
* Business Politicies
* Manufacturing Issues
Component
Requirement
Specification
Expansion /
Detailing
(Design)
Hardware
Description(s)
Software
Description(s)
Requirement
Description(s)
Customers
Requirement
Description
Implement'n Description

Mitel Semiconductor
Fig 6.4.2: Hierarchical Design-Steps
To examine the effects of this we must look more closely at the formality of the Design-Step.
6.5 Formality in Design-Steps
History shows that the way we design is to complete the 'creation step' using ad-hoc methods, then 'test'
the result against expectation to establish that it is achieved. Clearly the ends justify the means if the
result is what was expected … this is the source of the 'difficulty with design' as it is based upon the use of
gurus and advanced techniques.
If the Design-Step concept is right then it should be applicable to this model … and it is. Figure 6.5.1
shows what we expect to deploy at each of the stages of the Desin-Step. Figure 6.5.2 shows how formality
may be applied to this, illustrating how the Expansion/Detailing task, may deploy Heuristics and
Experience, yet the output can still be formalised. But it also shows that the other stages must be
formalised if the Conformance Test (and subsequent Implementation Description) is to be meaningful.
It also shows that if the Expansion/Detailing task is done formally (using Formal Methods), then there is
no specific need for the Conformance Test to be carried out at all (To be precise, there is no need at this
stage of the development cycle, though there is still a need for it at a later stage ; See 6.7). Indeed Formal
Methods can be shown to be significantly better than a Conformance Test, which no matter how thorough
will not test every combination of correct and incorrect stimulus and response.
HW / SW
Model
Co-Simulation
R H S
R H
H S
R R S
H S
LogicalDesign

Mitel Semiconductor
The use of Formal Methods is very interesting and should not be prohibited within this context, we should
anticipate that it will be deployed in certain Design-Steps, whilst others must continue with the Heuristic
and Experience based approaches … in particular at the 'forefront of technology' where by-definition, the
approaches to be deployed cannot be formalised, because they are not understood. Indeed, even the
Libraries may be in a state of flux.
Clearly there remains an issue of how well the Conformance Testing can establish compliance with the
requirement, and the exercising Test-Cases should be selected very carefully to achieve maximum
confidence … but if the Conformance Testing approach is used, then the output from the Design Step will
never be strictly formal, only formalised … and of course this reflects onto the System-Level development
as well which cannot then be formal either.
Fig 6.5.1: Needs of the Stages of a Design-Step
As the selection of Test-Cases is so important, it is worth a little more attention. They would be in effect the
examples that are specified for the verification of the behaviour of the object of the Design-Step, a
simulate-able summary of the Requirement Specification. This in turn specifies that the nature of the
formality of the Requirement Specification, that it should not contain things that cannot be simulated …
however this is an unreasonable restriction as many parameters are reasonable to specify and difficult to
prove. Accordingly the specific Test-Cases will inevitably be a functional and none-functional sub-set of
the Requirement Specification, the Use-Cases. As the Use-Cases can only ever (in all but the simplest
cases) represent a small subset of all possible behaviour, the resulting Conformance Testing can only be
good, not perfect ! So careful selection of Use-Cases to demonstrate the range of normal operation and
miss-operation, is an important part of the Design-Step …
Requirement
Specification
Expansion /
Detailing
(Design)
Conformance
Testing ?
Implement'n
Description
N
Y
* Experience
(Intelectual Property)
* Libraries (History)
* Methods
* Tools
* Heuristics
* Methods
* Tools
* Standards
* Methods
* Tools
* Standards
Design Step
* Data Base
* Configuration Control
* Documentation
* Standards

Mitel Semiconductor
Fig 6.5.2: The Formalised Design-Step
… But it is important to realise, that use of Use-Cases as the basis for Conformance Testing is not
adequately rigorous to constitute a Formal Design-Step, even if all of the other formal requirements are
met (which could be imagined). It is practical to achieve a Formalised Design-Step but not a Formal
Design-Step ! So as we are left with the conclusion that some errors can remain in the output of a Design-
Step, any practical System-Level design Method must work with this constraint !
6.6 Formalised Implementation
Until we have encompassing Formal Methods, we will not have the ability to complete the Formal Design-
Steps, and without the Formal Design-Steps we can never complete a product design formally. However,
even if we were able to complete a design formally, would it be the same as the implementation ?
Looking back to the V-Diagram, the act of implementation is a translation from the 'modelled' world to what
passes as 'reality' in an implementation context. This is perhaps better described as Architectural Mapping,
mapping the detailed requirement onto a pre-determined architecture of gates & processes or bytecode &
compute architecture. As the conclusion of the Design-Phase is when a Product is completely described
through its hierarchy to a level where a suite of formalised (or formal) translation is identified … such
mappings will occur for all parts of the design (For all Design-Step ends).
Is this step formal or only formalised ? Even though the Design-Phase may result in description of a
specific 2 input NAND function with timing, there is approximations taken about its actual performance
which may under some circumstances effect its behaviour … Similarly in a compiler, there are translation
and optimisation processes being run concurrently. In most substantial jobs will these tasks being
executed in an order or with data pattern that has never been seen before. Accordingly the result could be
unpredictable. Accordingly, even at the end of the Design-Phase, the act of translation itself introduces
uncertainty.
Requirement
Specification
Expansion /
Detailing
(Design)
Conformance
Testing ?
Implement'n
Description
N
Y
Requirement Specification
The formal description of the expected behaviour
of the item being designed. It will be used to judge
satisfactory performance of the end product or
(component) once implemented.
· Must be a formal Process.
· Must be a formal Output
Expansion / Detailing (Design)
The process of elaborating requirement details
into implementation details. Extensive use of
abstract models allows for behaviour simulation.
Heuristic approaches may be deployed to achieve
the required objective.
· Need Not be a formal Process.
Conformance Testing
Formal establishment that the proposed
implementation will meet (or exceed) the needs of
the Requirement Specification. Failure will trigger
re-design or (less frequently) modification of
Requirements Specification
Implementation Description
The output data from a Design Step is a Verified
Implementation Description Data-Base containing
one or more of the following :-
* Component Req't Spec.(s)
* Abstract Software Description(s)
* Abstract Hardware Description(s)
(Formal)
Design Step

Mitel Semiconductor
… So the answer would appear to be no, the act of implementation itself introduces errors from at
least two mechanisms (but probably many more ! ).
6.7 Formalised Verification
So because we cannot guarantee conformance in the translation process, we must propagate the
Conformance Testing after the Implementation translation stage …
Fig 6.7.1: Architectural Mapping
Indeed it can now be seen (Figure 6.7.1) that the Use-Cases must be specified in such a way that they can
be applied to the 'reality' of the implementation, to support the necessary Implementation Verification
tasks.
… Not too complex for a single Design-Step, but a lot more complex when we look at the
implications of a multi Design-Step, System-Level Product Development as shown in Figure 6.7.2. (The
partner to Fig 6.5.2) showing how the Use-Cases should be re-deployed to verify the actual physical
implementation (Which also concurs with the horizontal 'arrows' on Figure 5.2.2).
… As and when, formal systems do emerge, the model is still correct and useable, just that the
verification stages become a formality, a null-task. In the meantime, the resulting Product will have been
progressively and thoroughly tested ; as well as it is reasonably practical to do so.
Requirement
Specification
Expansion /
Detailing
(Design)
Conformance
Testing ?
Theoretical
Impl'n
Description
N
Y
Conformance
Testing ?
Actual Impl'n
Description
N
Y
Architecture
Mapping
Design Step Verification Step
Implementation
Step
LogicalDesign
Implementation

Mitel Semiconductor
Fig 6.7.2: Hierarchical Verification
But there are implications of this on tool requirements and it is as well to point them out here. Figure 6.5.2
and 6.7.2 identify the need for Co-Verification … a tool (or tools) which support concurrent simulation of
Requirements, Hardware & Software in the Design Phase, with the additional facet of Reality in the
Verification Phase. This is the specification of the necessary Co-Design tools (it is not enough simply to
model HW and SW !).
… Additionally, it has an impact on implementation architecture, which should allow the access of
individual blocks for verification, with the substitution of arbitrary parts with their functional-model
equivalents ! It is no-longer enough that (IC) designers chant the 'design for test' mantra, now they must
also chant 'design for verification' !
6.8 Design For Verification
In the same way that design-for-(manufacturing)-test has many different implementation paths, so too will
design-for-verification.
The main lesson learned in the design-for-test era, was that the designer must consider test and testability
as a part of the thing that is being designed, right from the first stages. As a result, certain types of
R H S
R H
H S
R R S
H S
Implement
H S
H
H SMAP
H SMAP
SMAP
Requirement Product
or *
or *
or * .
or *
Real HW / SW
Co-Verification
Real HW / SW
+ Model.
Co-Verification

Mitel Semiconductor
functional implementations (Eg: FSMs, pseudo-static logic, etc) which were easy to design with, but
difficult to test, have fallen out of favour. In addition specific techniques like scan-path, JTAG and built-in-
self-test have been introduced. In effect, the requirement for adequate manufacturing testability has had
an architectural effect on the implementation methods.
Design-for-verification will require a similar mind-set adjustment, and will also have architectural
consequences. In the same way, it will not be possible to provide one solution for all cases, and a range of
methods will be deployed, the most appropriate one (or two) being chosen in specific development
instances.
An example of the approach that could be applied is that with knowledge that a Hardware Component of a
Product is going to become part of a System-Level Integration (SLI), that the test-bench used to develop
the component in isolation, is also able to be applied to the same cell once it has been realised in silicon !
Is this possible ? Yes, but some ways are better than others !
… For example, if the Component's design test bench was the patterns (stimulus and response)
that was applied by the host (embedded) processor in the IC, then those same patterns could be applied
once the device was implemented in silicon … However this approach is cumbersome for the Design-
Phase. An alternative is to use a normal test-bench and capture the 'patterns' at the interface between the
test-bench and the Component, then to use a hardware architecture which will allow those patterns to be
applied to the Component, as if it were the only thing on the SLI. This could be achieved using scan-path
around the Component, or by use of an appropriately capable, bus-based modular assembly architecture,
which would also offers a significantly improved unify-able pattern extraction interface. Further, by using a
consistent interface (The bus), it improves the prospect of Components designed in isolation correctly
interfacing.
…Undoubtedly there are many other approaches that could be deployed, once it is recognised that
Verification is a significant part of the Product Development task.

Mitel Semiconductor
7 Formalised Requirements
Figure 6.4.2 and 6.7.2 identified the need for a Co-Verification tool where Formal Methods could not be
deployed, to support the need for Conformance Testing in the Modelled and Real world. To achieve this
such a tool needs to be able to simulate Requirements, Hardware & Software in the Design Phase, with
the additional facet of Reality in the Verification Phase. This need to include Requirements arises, because
the Requirement Specification is really the 'customers' test-bench … the criteria that he has decided will
apply to a successful product development.
To be simulate-able, the Requirements need to be formally captured, using a notation that is complete
enough be used as a descriptor to a simulation engine. This can be very difficult, because the traditional
Market/Customer lead view of the product's functionality has limitations, because the customer does not
always (ever ?) understand the product he will want, ahead of time.
The traditional approach to this is to use Marketing engineers to act as intelligent filters, on behalf of the
customer. But even they have limitations, as they do not understand the customers market as well as he
does, even if they have a better understanding of the technology that they are able to deploy. The most
effective method applied in reality, is that the Requirement develops alongside the Product … until, ideally,
when the development is complete, the Requirement and Product match. But this is a process of iteration
and should be discouraged if we are to achieve the tight TTM's required in the future. Looking more closely
at the process, it is possible to say that in principle at least, the iterations of the Requirement Spec are only
the addition of details … though there are instances where the exposure of detail in the Design-Phase
does mandate the fundamental change of requirement … but as these also call the future of the
development into question, they would class as serious changes.
Unnecessarily requirements also have the effect of causing serious changes to requirement specifications
for no truly justifiable reason, so must be discouraged.
So the need to develop good quality Requirement Specifications and to extend them down through the
levels of hierarchy in a System-Level Product development is clear … and as they become the test-
benches for the acceptability of the component and product development then they should be agreed with
the customer and be simulate-able and be capable of having detail added later without influencing the
basic functional specification.
There are two major problems with this approach …
1. The customer does not know in detail what he wants.
2. The customer does not know when he is asking for something unreasonable (against laws of
physics or against another requirement).
The first point can be addressed by the simulation environment itself. It must be possible to give the
customer a model of his product to enable him to establish that it truly is what he wants it to be. Further,
that it should be easy to modify, so that he can amend it until it does what he needs … this includes the
situation where the customer refines his requirements as a result of seeing the modelled behaviour of his
original requirements.
Clearly to be useful, the model must be provided with an interface to enable the customer to exercise it in
the way intended … indeed its use may require the provision of modelled support-tools, all of which will
comprise Aspects of the end Product. As a warning, it is easier to imagine and provide the simulated user
interface to a GSM telephone, but it is a lot more complex to provide it for a product which only has a
digital or programmable interface, these lower-level requirements will need to be encapsulated for the
Aspects/Components of a product.
A special case worthy of note is the specification of Interfaces. Though not a specific Component in
themselves, they are the mechanism by which users are able to 'guarantee' the interconnection of the
Components being developed. By agreeing on interfaces, the overall task is more readily partitioned …
and the operation of the Component may be tested as conforming to that interface, in isolation from the
rest of the system. This is particularly important where the rest of the system does not (yet) exist. The use
of agreed Interfaces is a very powerful approach for modularity and reuse and where common interfaces

Mitel Semiconductor
can be agreed, then powerful 'tools' to test conformance to the interface, and to source and sink data
significantly assist with productivity. It has to be remembered however, that the definition of Interfaces and
any support tools is additional to the principle task at hand … they are not Components nor Aspects of the
product. But their use should be encouraged from a quality and accuracy point of view, and their reuse
encouraged from an efficiency point of view. One example, is an on-chip bus, another C++, but others may
be agreed optimised for other application needs. Clearly there is a requirement for a minimum, but
comprehensive set of interfaces, ideally unified at an industry level, to maximise portability.
The second point is difficult to support quantitatively, and something knowledge-based (either machine or
human) is required to make a continuous assessment of the requirements. One way of achieving
meaningful feedback is to automate the entire Design-Phase below the capturing of Requirements,
enabling the 'cost' of individual requirements to be immediately assessed. Although this can be imagined,
as the automated route cannot (in general) anticipate Additional Requirements to be added into
Hierarchical Design-Steps, it can only ever provide guidance. The special case where the Additional
Requirements are a null-set may be logical and predictable for certain types of design (architecture) and
thus it could become the entire Design-Phase. But recognising that it is a guide, will enable approximations
to be made in the name of speed. Focusing on rapid, approximate feedback to assess product architecture
is felt to be much more valuable, as there will be many more 'architectures' for which useful feedback is
obtained, than there will be architectures for which an automated and complete design-process can be
applied !

Mitel Semiconductor
8 Partitioning and MacroFunctions
It becomes clear that in the process of hierarchical decomposition that the Design-Steps result in definition of
requirements for Functional Objects. First at a high (abstract) level, but later at lower levels of detail … ultimately
decomposing to ByteCode or Boolean. The problem is that at some stage the decision has to be made to commit a
Functional Object to a hardware or software implementation … and yet such a Partitioning decision is not an easy
one to make, as it depends upon many system variables, as well as the Partitioning decisions that have already
been taken.
Some Partitioning examples ...
• A 'software' FFT Function is free if it fits into an available ROM and use available MIPs in a host
processor, but is slow and has a relatively high power consumption.
• A 'hardware' FFT is low-power and fast, but always takes (expensive) room on silicon.
• Although the FFT code fits into the available ROM, there is insufficient processor power to handle it,
without effecting the operation of another function … This may be acceptable or may not !
The examples illustrate the difficulty with Partitioning, because even when the hard parameters are all known, the
soft parameters (the last case) are difficult to quantify. It probably doesn't matter in an vehicle management
system, if the active suspension system has to wait a moment, whilst the anti-lock breaking, air-bag control,
traction control and power-steering are all working overtime in a crash scenario !
Accordingly it is desirable if the analysis stage can maintain descriptions of Functional Objects until the last
possible 'moment' in the Design-Phase, such that the Partitioning can be handled as a 'last' task.
The direct consequence of this is the MacroFunction. The MacroFunction is a concept (Perhaps wrongly named)
which encapsulates functionality, whose implementation is a mixture of 'hardware' and 'software' working together.
The ratio of hardware / software is not prescribed, except that a MacroFunction Functionality should be capable of
being implemented mostly in hardware or all in software. A MacroFunction can (theoretically) consist of 100%
Software & 0% Hardware, through-to >99% Hardware & <1% Software (As the interface to a MacroFunction will
always be software, it must have at least a small software interface component). In the vein of reaching the end of
the Design-Phase, the MacroFunction may be considered to be a an identified formalised translation to
implementation … without prescribing the actual hardware / software Partitioning required.
This is a very usefull model from an analysis point of view. MacroFunctions do not have to be available for every
end-point in the Design-Phase, but where they are, they enable the hardware / software partitioning to be delayed.
And thereby a more optimal hardware / software implementation constructed. As a MacroFunction is accessed
from the Application Program by the same function call, irrespective of its internal implementation, trade-off
between hardware and software (on the grounds of performance, power, availability, TTM, functionality, flexibility,
etc) can be left until the last part of the Design-Phase. Further, the use of MacroFunctions introduces a layer of
formal isolation which improves the probability of producing right-first-time code in highly complex embedded
systems, as such MacroFunctions are a key System-Level ReUse and TTM support vehicle.
So the concept is valuable, but what are the implications ? How is a MacroFunction created to meet these needs ?
The MacroFunction must be analysed and created using a layered model, and that the layers, below arbitrary
levels, must be implementable, interchangeably, in hardware or software. Further, to maintain independence from
the Application program that will use it, that the MacroFunction (and maybe parts of it) must operate or be capable
of operation in an isolated, autonomous environment (eg: As a task under an RTOS).
8.1 The 'Minimal Hardware' MacroFunction
To be implementation independent there some rules and concepts to which the MacroFunction must
conform. These are encapsulated in the functional components, SIFs and Stubs, Layer ‘N’ Functions and
their Interfaces, which the following diagrams illustrate.

Mitel Semiconductor
Fig 8.1.1: Minimal Hardware adapting to Functional Layers
Figure 8.1.1 serves to introduce the conceptual MacroFunction implemented largely in software. The
concept expects the Application Code to access the MacroFunction by the interface provided at the Layer
5 Interface (The five layers shown is for illustration purposes only).
This implementation has all of the functionality of the MacroFunction implemented in software. The
Software Interface Functions (SIFs) provide a none-functional translation from the software to the
hardware domain. The process of analysis will reveal the natural functional layers, layers that are of similar
class, providing it starts at an adequately high functional level. At the same time, meaningful interfaces to
those functions will also be identified. In this specific case, all layers and interfaces are all implemented in
software, using 'appropriate' techniques. The lowest layer, is largely the same, but some of the
functionality may be included in the SIFs (or their sequenced access), so the whole functionality of the
Layer 1 is only partly achieved in software … so the layer is implemented as an adaption layer … or stub.
Layer 5 Functions
Layer 4 Functions
Layer 3 Functions
Layer 2 Functions
SW - HW
Boundary
Layer 1 Stubs
L1 Interface
L2 Interface
L3 Interface
L4 Interface
L5 Interface
SIFs
SIF Interface
Host Application
Minimal HW
User

Mitel Semiconductor
8.2 The 'Normal Hardware' MacroFunction
The extreme case of Figure 8.1.1 is unusual, and a more normal circumstance is where the hardware
component is reasonably functional in itself, and this is illustrated in Figure 8.2.1.
Fig 8.2.1 : Normal Hardware adapting to Functional Layers
Some hardware functionality is included because of the performance improvement that can be achieved.
Other functionality is included because it is easy to incorporate into the hardware and for no other reason.
What is most significant is that some functionality of Normal Hardware will be of a class higher than Layer
1 and some higher than Layer 2. However, it is unlikely that the hardware will be fully capable of
supporting the functionality of the respective layers and their interface calls. So, as before, the SIFs
provide a none-functional interface to the hardware, and the functional deficiencies are made-up by Stubs
… adapting the deficient hardware functionality to the appropriate layer interface, where the software
implementations can carry-on to support the layers above.
SIFs
Layer 5 Functions
Layer 4 Functions
Layer 3 Fns
L.2 Fns
SW - HW
Boundary
L1
Stub
L2
Stub
L3
Stub
L1 Interface
L2 Interface
L3 Interface
L4 Interface
L5 Interface
SIF Interface
Host Application
Normal HW
Functionality
User

Mitel Semiconductor
8.3 The 'Highly-Capable Hardware' MacroFunction
Figure 8.3.1 illustrates the extreme case, where the hardware has a high degree of intelligence (this might
be the case if the hardware is actually a processor sub-system in its own right). In this case the lower
Level’N’ Functions are not supported at all on the main host processor, but are interfaced to the hardware
through the Stubs and SIFs at higher levels only. The lower Levels Functions and Interfaces may be
considered as Virtual, having no software identity in this specific implementation of the MacroFunction,
even though their functionality will be present 'inside' the hardware, or may be implemented in-full in a
separate (second) processor.
Fig 8.3.1 : Very-Capable Hardware adapting to Functional Layers
This model shows an interesting characteristic. The 'Virtual' layers, though they may exist inside the
hardware implementation are inaccessible to the Host Application. Accordingly, even in the 'minimal
hardware' case, where all the layers are implemented in software, the lower levels must not be directly
accessed by the host application … if the freedom to flexibly partition hardware and software is to be
maintained. For that reason, the complete functionality of the MacroFunction must be accessible at the
interface to its highest level of analysis (L5 Interface in this case) … Logically, there is no need to mandate
a specific layer for an interface, except that it must be a layer sufficiently high, that its interface will always
be in the software domain.
As a footnote, it is quite in order that higher level MacroFunctions may be constructed out of lower-level
MacroFunctions. The only constraint is that the lower level MacroFunctions must exist entirely within the
higher level ones.
8.4 Autonomy in MacroFunctions
One of hardware’s striking features is parallelism, the independent/concurrent operation of circuitry.
Accordingly the environment of the MacroFunction must emulate this 'autonomy' if it is to offer true
freedom of interchange-ability. The facility for autonomy is provided in the software domain through the
use of Tasks and an operating system. Logically, for an embedded system with real-time constraints, this
should be a Real Time Operating System (RTOS). However, though the use of an RTOS emulates it, it
should be remembered that in its implementation, the actual Tasks are actioned serially on the single host
processor, so are not absolutely independent of one another as one Task may influence the run-time of
another.
Whilst it is clear that Tasks and an RTOS are necessary part of the practical deployment of
MacroFunctions. And that each MacroFunction should exist within a Task, it is not clear if a MacroFunction
may/should contain multiple Tasks within it … after all a hardware implementation may consist of several
Layer 5 Functions
Layer 4 Functions
SW - HW
Boundary
L4
Stub
L3 Stub
L1 Interface
L2 Interface
L3 Interface
L4 Interface
L5 Interface
SIFs
SIF Interface
Host Application
Very Capable .
HW .
Functionality
User

Mitel Semiconductor
autonomous hardware-processes ! The answer is, that providing the Tasks are entirely within the
MacroFunction, that a MacroFunction may consist of many independent Tasks (or Threads) … However,
there is significant evidence, that suggests that the high degree of autonomy in hardware implementations
is not strictly necessary, but is included because it is easier to think in these terms when it is designed …
and costs nothing ! Accordingly, the MacroFunction designer should look at the necessary autonomy and
model that alone. (Experience to date indicates that a single Task is all that is necessary … but this must
not be a restriction in the methodology).
One effect of this is that to operate as a Task, the MacroFunction must be self-aware ... it cannot simply be
a library of function calls, but must have a 'Functional-Core' , aware of its external functional responsibility.
This Functional-Core must be awoken by the RTOS at appropriate times, and be responsible for
administering the MacroFunction housekeeping (Reset, Error handling, Setup, etc) as well as the bi-
directional functional communications. And through the rules of MacroFunctions already defined, it will be
the only mechanism to access the lower levels of functionality within the MacroFunction itself.
… Although a MacroFunction specification, this task-based approach is equally applicable to any
Objects of Functionality which have been implemented using any structured or none-structured approach,
providing the Functional Interface is agreed before hand.
8.5 Architecture in MacroFunctions
The use of MacroFunctions (and analysis that leads to them), tends to create a control centric architecture
of product functionality. In this architecture there is always a Master in control ; like a conductor in charge
of an orchestra. The master administers tasks to the 'outstations', which may in turn administer more
removed outstations. Although in control, the Master may only have a notional 'turn-on', 'turn-off''
mastership to one outstation … whilst having a significant role feeding and removing data in another …
much like a conductor who also plays the piano (Yes, it does happen ! ). The main thing is that a
communication mechanism must exist between the processors and this is best (generically) supported via
an RTOS … although for the 'turn-on', 'turn-off'' mastership, the minimal command interface could be
supported by manual code, it is still desirable to plan for full RTOS interface for the future.
This architectural model better supports the concept of MacroFunctions, where the choice between
hardware and software implementation (or software on a 'slave' processor) is deferred until the resource
availability is understood.
As systems get more complicated it will become difficult to plan resources with fixed time-schedule plans
at the start, and dynamic task scheduling will become a part of the design process, complemented by
tasks that are aware of their time access and warn in the event of time-starvation is important … The future
role of the RTOS in all of this is along with emulation models guaranteed.
Although this architecture is attractive for a number of reasons, (not least of which is that Debug and
verification are better supported in this way) there are still believers in peer-group architectures though
these tend to be more difficult to analyse and manage … and whose results are less predictable. As the
ModesRoute must coexist with both it should not prohibit either, though it may favour one.

Mitel Semiconductor
9 The need for Debug
We have established that providing the Requirement is formally defined, each Design-Step is formal, that
the specification for the next Design-Step is formally linked to the preceding Design-Step, and that the
implementation is a formal translation from the 'last' Design-Step … that debugging of an implementation is
unnecessary, as it will, by definition work as specified.
… However we are along way from that situation today, and errors will occur at every step. Errors
of incorrect specification, errors of translation, and errors of implementation. The practical result of this is
that debugging is a necessary part of the System-Product Development Cycle, and its support must be
included into the methodology and design steps.
In the same way as it is necessary to include the 'design for verification', 'support for debug' must also be a
fundamental consideration … at all levels and throughout the design process. As with design for
verification, it will have architectural consequences and it may be that the same solutions will offer support
for debug. For example, we have already expressed the value of using an on-chip bus to facilitate modular
design, and that the bus (by appropriate use of features) should support the verification of individual
objects connected to it. It is logical to extend the facility of the bus to include debug support features such
as Address/Data watch-points/break-points. A debug mode, allowing objects to be accessed in a debug
mode … allowing access to hidden registers or preventing read-once data destruction. Etc.
If we recall the hierarchical modelling argument, then the debugger should be useably on Emulation-
Models and Implementation-Reality in a freely-interchangeable manner (though it is reasonable to expect
there are trade-offs in this) … hardware and software.
With the need for multiple processor systems, and MacroFunctions, the need to extend this to debug to
tasks on an RTOS, and to support the communication of RTOS's on the different processors, such that
one can debug the other.

Mitel Semiconductor
10 Re-Use
Remember, the motivation for System-Level Products is the exponentially increasing capacity of Silicon ICs !
Surprisingly, it was nearly 30 years ago Gordon Moore gave us Moore's Law [6], a yardstick which subsequently
become popular in the Integrated Circuit industry. It stated that silicon logic capacity would double every ~18
months for the foreseeable future … Over the years this has shown to be true. However, at the same time system
clock speed has been doubling every ~24 months, combining to produce a doubling of functionality every ~12
months. This has lead to a ~1000 fold increase of functionality in Integrated Circuits (ICs) during the least decade,
and we can expect similar expansion in the next !
On the immediate horizon, 0.18u IC technology will make 120M transistors [10] available for product application,
raising the question, what they can (all) be used for ? Consider for a moment that the logic for the average set-top
box can be implemented in about 2.4M transistors and the problem of understanding the architecture of the 120M
transistor IC … or 1Billion transistors available in a 'small-handful' of devices ! We undoubtedly will have products
of that complexity, but the problem is that although the technology is on the horizon, the products are not. This will
force us into a situation of very-short TTM as the 'silver bullet' product emerges in the next few months … as it
surely will !
We have already said that we cannot rely on the availability of engineers with experience of markets before we get
into them … we must substitute methodology and engineering, for experience. And we can already see that we will
be operating in a fiercely competitive situation as soon as the product is identified.
Evidence available from several sources, indicate that today's 2-10M transistor component designs 'take' ~ 50-200
my to implement. Two examples are [15][16]. Even linearly interpolating which is likely to be severely optimistic,
this equates to ~2000 my at 100M transistors ! However, by the time that the Systems aspects of Software,
Architecture and Validation are included, then this is unlikely to be less than 6000 my and may be several times
more … an seriously alarming prospect ! Just think, a 6000 my project with 200 engineers working on it, will need
30 years to complete … we only have ~2 years before the 0.18u capacity is generally available, so we should have
started the design 28 years ago, to complete it in time !
… Clearly there must be something wrong with this model (at least we must hope that there is !), it cannot
possibly be such a large task !? Well lets find some reasons why it will be smaller …
"We never start from scratch with a design, we always reuse libraries and things ! " … but then the 50-200
my projects referenced, did not either ! Having said that we (the industry) are very bad at reusing
anything, even cell libraries. Tools and methods could be reused, but the temptation to do something a bit
better means that new tools and methods are always being introduced, usually piecemeal. Probably the
largest reuse factor is the intellectual property in the minds of the experienced designers.
"System and Software aspects cannot be that big ! " … the fact is that when we make a system-level
product the 'smart bit' is not the development of the IC, there is a much larger task in the software that
makes it into a product. A system-level product is a custom computer with custom software, a 'UART' is a
simple block of a computer or a custom computer. The huge state-space of a computer program makes
the development and debugging process more complex (and never absolute), adding customised
computer hardware to this and the problem gets bigger as functional assumptions can no longer be made.
Getting the architecture of the whole product right becomes a major issue. Finally, bear in mind that history
shows that the size of computer programmes are doubling every 12 months, faster than silicon logic
density.
"Most of our designs are completed in days, what is the big deal about sub 0.25u ! " … for an ASIC
supplier then this is true and can be expected to remain the case in the future. However, look at what is
happening here. All of the front and back-end work is removed from your grasp, leaving the purely
mechanistic '(Synthesis), gate-layout, fabrication & logical-test' … this is a process for creation of physical
silicon from a standardised description … it is standardisable and available will be (is) available from many
sources. The choice of vendor will be (is) purely on the basis of Performance, Cost, Cycle-Time and
Quality. If Performance is predominantly a function of the Si geometry, and Quality is assumed … then we
are left with Cost and Cycle-Time … classic factory parameters. With direct competition, Cost will come
under direct pressure and margins will be reduced to minimum … and lower … to maintain full fab's. This

MODES Route - 27may98

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie MODES Route - 27may98

Ähnlich wie MODES Route - 27may98 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

MODES Route - 27may98