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 Deliverable id: TR:1.2.4 Issue Date: 27 May 98

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



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



- 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)



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.



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 !

http://www.gpsemi.com/�

http://www.etnoteam.it/�

http://www.tac.se/�

http://www.umist.ac.uk/�

http://www.unimi.it/�

http://www.vtools.es/�



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.



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 …



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)

MainExecution

HW

Co-ProcessingExternal IOInterface

MainProgram &Workspace(Memory)

Temporal Constraints

Delivers Complete Functionality



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



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

requirementsanalysis

specification

system design

CUSTOMER

acceptance testing

system test

system integration

user needs

specification

userrequirements

system architectureand subsystem

specification

modulespecification

deliveredsystem

integratedsystem

validated andverified system

testedsubsystem

tested module

modulecode

subsystemintegration and

test


test


testdetailed designdetailed designdetailed design

moduleimplementation

moduleimplementation

moduleimplementation module testmodule testmodule test

delivered systemmeets user needs

system meetsuser requirements

system agreeswith specification

subsystem agreeswith specification

module agreeswith 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.



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



'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.



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 1st product arrives after 3 years and is delivered to an unready market. A 2nd generation product, started after ~18 months, benefiting from the lessons learned in the first development and arriving at the market 18 months after the 1st,, just as the market starts to build. The first team, starts on the the 3rd 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 2nd generation is launched. A successful 3rd 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 !



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.



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 HardwareSoftware

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



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



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.

RequirementSpecification

Expansion /Detailing(Design)

ConformanceTesting ?

Implement'nDescription

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



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.





N

Y

Conceptual

Span



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.




Impl'nDesc'n

N

YC

onceptualS

pan




Impl'nDesc'n

N

Y

Conceptual

Span




Impl'nDesc'n

N

Y

Impl'nDesc'n

Conceptual

Span



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 !



N

Y

AdditionalRequirements

* Additional Features * Re-Use Parameters * Standards * Business Politicies * Manufacturing Issues

ComponentRequirementSpecification


HardwareDescription(s)

SoftwareDescription(s)

RequirementDescription(s)

CustomersRequirementDescription

Implement'n Description



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 / SWModel

Co-Simulation

R H S

R H

H S

R R S

H S

Logi

cal D

esig

n



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 …





N

Y

* Experience (Intelectual Property)* Libraries (History)* Methods* Tools* Heuristics

* Methods* Tools* Standards

* Methods* Tools* Standards

Design Step

* Data Base* Configuration Control* Documentation* Standards



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.





N

Y

Requirement SpecificationThe formal description of the expected behaviourof the item being designed. It will be used to judgesatisfactory 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 detailsinto implementation details. Extensive use ofabstract models allows for behaviour simulation.Heuristic approaches may be deployed to achievethe required objective.· Need Not be a formal Process.· Must be a formal Output

Conformance TestingFormal establishment that the proposedimplementation will meet (or exceed) the needs ofthe Requirement Specification. Failure will triggerre-design or (less frequently) modification ofRequirements Specification· Must be a formal Process.· Must be a formal Output

Implementation DescriptionThe output data from a Design Step is a VerifiedImplementation Description Data-Base containingone or more of the following :-

* Component Req't Spec.(s)* Abstract Software Description(s)* Abstract Hardware Description(s)

· Must be a formal Process.· Must be a formal Output

(Formal)Design Step



… 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.




TheoreticalImpl'n

Description

N

Y


Actual Impl'nDescription

N

Y

ArchitectureMapping

Design Step Verification Step

ImplementationStep

Logi

cal D

esig

n

Impl

emen

tatio

n



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

Impl

emen

t

H S

H

H SMAP

H SMAP

SMAP

Requirement Product

or *

or *

or * .

or *

Real HW / SWCo-Verification

Real HW / SW+ Model.

Co-Verification



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.



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



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 !



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.



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 - HWBoundary

Layer 1 Stubs

L1 Interface

L2 Interface

L3 Interface

L4 Interface

L5 Interface

SIFs

SIF Interface

Host Application

Minimal HW

Use

r



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 - HWBoundary

L1Stub

L2Stub

L3Stub

L1 Interface

L2 Interface

L3 Interface

L4 Interface

L5 Interface

SIF Interface

Host Application

Normal HW

Func

tiona

lity

Use

r



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 - HWBoundary

L4Stub

L3 Stub

L1 Interface

L2 Interface

L3 Interface

L4 Interface

L5 Interface

SIFs

SIF Interface

Host Application

Very Capable .HW .

Func

tiona

lity

Use

r



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.



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.



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



is a way to treat a system-level product as a component, but the route to success involves a state-of-the-art Si process, tight financial control and a very good and integrated tool-suite.

It is worth looking at the Synthesis role in this, because to some customers, where all other parameters are equal, the supplier who is able to take RTL-VHDL (or equivalent) is more attractive … taking some of the work away from his own engineers. Indeed, it offers the 'factory' more time to achieve its overall function, and a better opportunity to make profit. Synthesis is the thin-end of the system-level wedge and ignoring it not really a viable option.

(This silicon-centric view is symptomatic of the problem … System-Level aspects really do constitute as much if not more, of a design task than the silicon ! … The Silicon is not the System ! )

… So is there an error ? Well some error is in the increasing productivity of tools being deployed. In particular, the ones we are not (individually) using yet, though are being improved through their use in other parts of the industry … and which are becoming relevant to system-level design. In addition, the improved communication and networking of engineers (internal and external) is leading to an improved informal reuse of information … though the combined effect of these is probably only one order of magnitude, it does emphasise the importance of immediate investment in new tools … not only in the areas that we already know, but also in the associated areas, areas that are becoming part of our increasing system-level responsibility domain. (Eg: Si vendors, must invest in state-of-the-art Si methods and tools … assumed ; but also in state-of-the-art software development methods and tools … unprecedented ).

So assuming that we do deploy the latest tools across the spectrum of 'system' we achieve a factor of 10 improvement, so we still need to find at least one further order of magnitude improvement to take us to the order of 10's of man.years of effort.

Probably the only vehicle that offers this potential is further deployment of reuse …

10.1 Aspects of Reuse Dr Hatton [12] identifies ten system-level reuse components as …

1. Architecture 2. Requirements 3. Cost & Resource Estimates 4. Plans 5. Designs & Specifications 6. Data 7. Human Interfaces 8. Source Code (SW or HW HDL) 9. User Documentation 10. Test Material

I would add several more items to this list …

11. Methods 12. Tools 13. Object Code (Including ByteCode and Layout Data) 14. Simulation models 15. Test-Benches

… There are probably (many) more. And each one of these can have several facets (hardware, software, system, support tools, etc).

This list (when complete) comprises the Views of an object, and they are all reusable !

This is significantly broader context than the traditional view of reuse which is more regularly considered as binary or logic-gate level libraries, with simulation models and data sheets ! This list outlines the huge potential for reuse, across the sphere of System-Level developments. It sets the scene for the reuse domain that we need to consider to achieve the x10 improvement of productivity needed … all-pervasive, all-level reuse ! We must develop all of our data (plans, manuals, software and hardware) with consistent



style and to be reuseable, at all levels of its being. Further, we must manage this data in such a way that when it comes to being reused, that it is readily accessible and with a known quality level (See : Configuration Control, Ch12 : Quality Gateway, Ch7 and Appendix A). In this way a basic, but effective reuse library will 'just happen', as a part of the product design process.

10.2 Intellectual Property If we consider that we need to reuse various Product Aspects and Components, then these must be encapsulated in some way to support their reuse. Because they offer the capability to 'save time' and also encapsulate 'pieces' of knowledge or experience, then they can be valued in financial terms. The industry has given this a title of Intellectual Property … though it is usually applied to circuit functions or software modules, this need not be a restriction.

Although it is possible to express the value of a particular block of IP in financial terms, it is not easy to do as the following examples show :-

Effort-Based Value : The value of the IP is measured in terms of the man.months of effort that went into its development. This in no way reflects the efficiency of the actual design route, or the intrinsic value of the solution.

Intrinsic Value : 50-100%(?) of the costs involved in an 'un-skilled' design group creating the same solution. This in no-way reflects the skill-level of the actual design group. It does not include the value of having a solution 'today' as opposed to having to go through the design process. Also, it does not reflect the value of not having to divert internal engineers, which are probably in short supply.

Market value : What you can get ! If the object is available from more than one source, then this is likely to be the value experienced by IP vendors. In this scenario, the vendor seldom recovers his actual development cost, which forces vendors out of business or to deliver poor quality IP… neither of which are in the long-term interest of the licensee … though they are in their short term interest !

… From a IP licensee perspective, it is not easy. IP has a poor reputation. It takes a lot of effort to use and your own engineers have to understand it, and possibly re-engineer it to include your methods or quality procedures. IP is seldom used as purchased. This tends to be a pressure to force the price down, as the licensee anticipates having to do work himself. It also tends to be a reason not to buy IP, as the perceived effort in designing your own is less than the effort of incorporating someone else's … A mistake which is easy to make when you don't understand the complexity of the object being discussed.

Fundamental to breaking this deadlock, is agreement of quality standards. This will allow the transfer of IP of known levels of completion … and just as importantly, un-completion. As a result it will enable the licensee to have a much better understanding of what he is buying and how much effort will be required to use it ! It also gives the IP vendor quality standards to aspire towards (a goal to enable him to optimise his design methods) and also a basis on which to claim IP value.

Surely the IP protection and licensing terms and conditions are important practical parameters in the exchange of IP, but neither of them can successfully proceed without a realistic assessment of value.

… However, internally, protection and licensing should not be an issue. Here only the intrinsic value is important, so we would expect reuse to be extensive … but it is not. Principally because the extra effort involved in encapsulation of IP is not allowed for in the 'host' project time frame … and this is accepted corporately because the lost value of this IP is not truly recognised in the improvement of cycle times and development costs for other projects. Accordingly, the value of potential IP should be neutrally assessed and if it is judged valuable against internal criteria, then it must be required that it is encapsulated even if there is no intent to offer the IP externally…. Its corporate value is recognised and that overrides its project value alone.

How much (extra) effort is involved in encapsulation ?

… If a project falls within the scope of one Conceptual-Span, then the effort for encapsulation of components of it is significant (estimated at x3). However there is grounds for belief that if it is such a small project that it is not worth encapsulation of the components as they are (by definition) simple. However, for



more complex system-level products, where the complexity of the development expands beyond a Concept-Span, then encapsulation of the components is already a requirement so that it can be deployed in other parts of the project … and the additional work to formalise this encapsulation will be minimal, if release management is managed through the use of a Configuration Control tool, as an integral part of the development environment.

A key observation from this, is that it is valuable for a company to recognise and encapsulate its own IP, even if it has no intention of offering its IP for sale ! Accordingly, grading and encapsulation of data (IP) must be considered as a priority in all companies … and a prerequisite for those who intent to trade in IP.

Of course when exchange of IP is envisaged, then the data assembled must conform to standards. For internal exchange it is adequate that this is to internal standards, but for external exchange then global standards are mandated … This can cause a significant difficulty as no global standards exist for views or quality ! This is at least a part of the objective of the ModesRoute, because through its identification and establishment as an accepted route for system-level product development, the components of standardisation will become apparent. And similarly, through recognition of the needs of Concurrent Development, the standardisation of Quality Gateways.

… It is recognised that this description of reuse 'facets' and 'quality' is not specific enough to be immediately applicable, but it identifies the need for broadening the scope significantly beyond those of the Si-centric VSIA initiative, and is an opportunity for Europe to develop a lead position.



11 Configuration Control It is clear from the preceding chapters, that with Products having many Aspects and Aspects having many Components. And the successful product development operating under time pressure and geographic distribution of design resources. And needing to work in a Concurrent Design environment … than effective and efficient management of data is mandatory.

Such a management tool will have the following facilities to support the needs of the method :-

Manage the edit and read access to all kinds of computer data : Thereby maintain paths to prescribed statuses and versions of files, their histories, links, releases and interdependencies.

Incorporate 'Product, Aspect & Component Assembly Rules' : Such that it will not be possible to release an object to a higher level, than the lowest level of its component parts … or at least those parts of the component that apply to that release.

Manage the release of data to the Quality Gateway standards : Allowing designers to be unencumbered by the control procedure.

Allow management of data across geographic locations : Allowing data to be checked-out for edit at one location, and not confused with edit attempts at another. Allowing 'development builds' of products using components of 'at-least X state' criteria.

Not replicate full data-bases at each geographic location : Allowing the minimisation of stored data, by its minimum replication.

Maintain access control of certain data : To restrict data access to certain parts of the information in support licence and audit requirements.

Be available (integrally) on all common platforms and be applicable to the use of that platform : Supporting the development of all Project Data, from all development (including Marketing) sources.

Provide security of data : Confidence that data put into the environment will not be lost or degraded.

Provide a bug-tracking capability : To manage the identification, allocation, correction and release of bug-fixes.



12 The ModesRoute Diagram Although the preceding sections describe applicable methods and requirements for a MicroElectronic-System methodology, some sort of diagram is beneficial to condense the salient features and illustrate the flow. The ModesRoute Diagram (Figure 12.1) can be considered as an implementation of a single Design-Step, with several Quality-Gateway compatible output stages accessible. The hierarchy of the Design-Step is incorporated through the Component Preparation stage, in conjunction with the use of Component & Sub-System Source (Library). It is in itself a V-Diagram, incorporating the analysis, implementation and verification stages.

… It is not complete, in that it does not capture everything that is described in the preceding chapters. However, it is complete in that it illustrates a framework in which the methods described can and should be implemented. It is the ModesRoute Diagram in context, which can best be used for mapping of productivity tool functionality and interface requirements.

It is worth a closer look to establish that it demonstrates the desired characteristics …

• It looks simple and describes a process familiar to everybody in whatever sphere they develop Systems, it can be generalised as :- Formalise Requirements -> Develop -> Implement -> Verify -> Replicate. However, because its scope includes the full verification activity, it identifies the need for and sources of, verification documentation (files).

• It is implementation independent, not using words which associate it with a pre-conceived implementation technology or hierarchical level ; it is equally applicable to all spheres of System design (Battleship, to IC).

• It is complete, covering the full span from concept to production. As development is the creation of manufacturable (and valuable) product, anything less would not cover the scope of the development process.

• It describes heretical, component based design, allowing the entire route to be 'attached' to lower or higher levels of implementation.

• It is compatible with Concept-Span/Design-Step, supporting distributed development of System-Level products.

• It identifies the need for after-the-event verification, illustrating the importance of verification as a part of the development cycle-time

• It supports the multi-component product, allowing components to be considered as developments in their own rights.

• It is compatable with the MacroFunction concept, allowing system partitioning to be delayed and seperated from analysis.

• It inherently understands the interface to reuse and IP exchange, minimising TTM and design effort, whilst maximising quality.

… as it describes the process by which System-Level products do come into being, it is describes the process that design engineers are already doing (knowingly or not). However, having illustrated it, it is now possible to optimise it and its support.

(See Appendix B for expansion of the roles of each of the stages in the ModesRoute Diagram)



Comp't Requirements(Test1 Benches)

ComponentImpl'n & Prep'n

Product Idea

Functional Design

Architect &Partition System

System Integration& Prototype

Integration Spec.(Functional Test2)

AssessReproduceability

Product Spec.(Reproduction Test4)

The ModesRoute

Acceptance Trials(Alpha & Beta)

Functional Spec.(Verification Test3)

R - Recursion May Occur Here

Reproduce

FormaliseRequirements

COMPONENTREQUIRMENTS

ARCHITECTURALREQUIRMENTS

Component Preparation

System Integration

System Implementation

SYSTEMFUNCTIONAL SPEC.

PRODUCTREQUIREMENTS

SPEC.

EXTERNAL REQ'S

OBJECTREQ'S

COMPONENTSTO LIBRARY

(SUB) SYSTEMTO LIBRARY

Commercial RestrictionsRe-Use Restrictions

Reproduction Restrictions

ALL COMP'SPREPARED

RECURSION INPUT FOR LOWER-LEVELCOMPONENTS OR SUB-SYSTEMS

SUM

MA

RY

INFO

RM

ATI

ON

SOURCEDOBJECT

x3.3

- Itterate to agreement

INTEGRATIONPLAN

Ext

erna

lP

repa

ratio

n

EXTERNALOBJECTC

omp'

t & S

ub-S

yst.

Sou

rce

(Lib

)

R

R

R

Fig12.1: The ModesRoute Diagram

V1.0



13 Tool Mapping to ModesRoute Whilst we do not do any specific tool mapping at this stage, it is 'easy' to see the roles that identifiable tools play in an implementation of a System using the route. It is also fairly easy to see major gaps where development or re-deployment of tools would be immediately beneficial …

… But Tool Mapping specific tools onto ModesRoute is not a role for this document ! This document is and should remain implementation (tool) independent. Having said that, it would be beneficial if the tools that have been developed and deployed within the OMI/MODES project are mapped to establish their relevance in context … no doubt there will be some 'strong links' as these are the tools whose usage (in context) has been observed and form the basis for many of the generic solutions in the ModesRoute itself.

From the observation of the ModesRoute and knowledge of the tools and methods that are available, yet without reference to specific tools and their use, it is possible to identify some 'quick hits', weaknesses that are apparent with existing tools, and opportunities that exist for new ones …

Without elaboration, priority or any claims for completion, here is such a list :-

* Functional verification is not adequately supported by existing tools.

* The use of interconnection standards (Busses for Si, CORBA for SW … but others for … Project Planning, Documentation, etc.) significantly ease the use and reuse of invested effort and IP.

* That interconnection standards must include enhancements for Debug, Manufacturing Test and Verification … which they do not adequately do today.

* Data management and control systems should be across the whole product and should support componentised and hierarchical developments, and concurrent and distributed design practice.

* The concept of Quality Gateways, allowing pre-release information to flow throughout a project is not supported by normal tools. This will ideally be established universally as soon as possible.

* Emulation model building tools. To build emulation and simulation models of arbitrary functional objects and with exchangeable (library) components. To build models of interfaces. To build models of Use-Cases and responses.

* The ability of geographical and disciplinary distributed 'contributors' to be part of a managed environment is not supported by existing tools.

* The recognition of libraries as the lowest level of analysis required, representing the use of a 'known commodity', with known quality and characteristics, is not easily supported by existing tools.

* The need to generate Requirement Specifications in an animate-able way, and to use them as the criteria for measuring design completion.

* The scope of Co-Design tools, need to be extended to allow the free interchange of Hardware, Software, Model and Implementation 'views' as appropriate for the appropriate task in the development cycle. And that it should be compatible with the format of the requirement specification (or use cases) … the test banches.

* Abstract Requirement Specification capturing and animation tools are required for the generation and disintegration of Requirement Specifications and provision of test cases … but they must be able to generate Test and Verification material for use later in the product cycle.

* Interfaces are pervasive. Tools to test conformance and emulate interactions are needed at all levels.

* Interface standardisation development tools such as those that provide regularised interfaces between software and hardware should be encouraged.

* The use of RTOS's is an important part of multi-processor products, their use should no longer be considered optional ! Without them complex system-level products will be impossible.



* All development tools should support true hierarchy and multiple external libraries … allowing their ready transplant into another part of the System-Level development activity. This is seldom the case today.

* Documentation tools that allow automatic compilation of documents from templates and data.

* Time aware support for tasks to assure optimal performance and graceful service degradation.

* …



Appendix A : Quality Gateways Quality Gateway Universal Criteria

Specification Entry Req: An idea Do In State: Internal : Refinement of idea, development of architecture, selection of Methods. External : Basic information only, accuracy may be little better than a best-guess. Comment: A development may enter this State several times as the ‘task’ it is to perform is re-

partitioned with its neighbours.

Development Entry Req: Knowledge based estimate of the development task ahead and its likelihood of success. Functional Acceptability Criteria. Development Costs and Schedule. Manufacturing Cost. Methods and Tools to be used. Risk Assessment. (Preliminary Requirement Spec.)

Do In State: Internal : Convert the planned development, by stages until it achieves full release criteria. Ultimately resulting in a matching implementation and product specification.

External: Users may make use of Development data must be aware that it will probably be only partially functional against the currently applicable Requirement Spec.

Comment: The Development state is where all of the actual development and testing takes place. A development moving between (Eg) Alpha and Beta, does so via Development. The Requirement Spec. itself may be modified during this stage, to achieve ‘end’ agreement with the implement-ation. Significant changes may involve return to the Specification stage.

Alpha Entry Req: A development which has demon-strated Basic Functionality

Do In State: Use the data recognising its fragility. Bugs probably will be found.

# against the (at that time) applicable Requirement Spec.

Comment: There will probably be several Alpha releases as errors of functionality are discovered &/or changes in Requirement Spec are required. A development in this stage will demonstrate significant functional fragility and it will seldom be reliable enough to be used without close supervision or support.

Beta Entry Req: A development which has demon-strated Complete Functionality * against the (by now) solid Requirement Spec. Additionally, it will have demonstrated Basic Functionality

Do In State: Use the data freely, but beware it is still not fully released. Bugs may be found. # in a Normal-Operating-Environment.

Comment: The intention is that there is just one Beta release, though there may be more if ‘deep’ errors of functionality are discovered &/or changes in Requirement Spec are identified. A development in this stage will demonstrate significant robustness. At a Corporate level (and as a Developer) we are happy to agree a Limited Supply Contract with our customers, where we reserve full commitment to conform to certain aspects.

Release Entry Req: A development which has demonstrated Complete Functionality

Do In State: Deployment of the ‘package’ of information, restrained only by Commercial considerations.

* against the Requirement Specification and in its Normal-Operating-Environment(s). Viable Reproducibility. Complete and consistent Implementation Spec.

Comment: The intention is that there is just one Release. Significant errors after this stage will normally result in a new development or change of description. At a Corporate level (and as a Developer) we are happy to agree an unconstrained Supply Contract with our customers.

# Basic Functionality : Demonstrating apparently correct functional responses to the application of Normal-Operating-Mode stimuli (or Normal-Operating-Environment stimuli). * Complete Functionality : Completely meets the functional and non-functional requirements identified in the Requirements Specification (and Normal-Operating-Environment).

The Quality Gateways are the unified Release Criteria identified in Section 7, they represent levels-of-achievement of a generic Development process applicable to all Products and Aspects, Components and Elements. They apply to External Data, data which goes outside of the immediate closed environment of its local developers, for purposes of exploitation or further use. They are described in a generic way they do not prescribe interpretation for a given technology, nor detail of the method (or tools) to be used to make the transition between them. Accordingly, they act as the unifying influence to regulate the development of an arbitrary object in an arbitrary technology. Corporate Policy can now prescribe the



quality requirements for an arbitrary Product, Aspect, Component, Element or Capability … without having need to understand the actual technology being deployed :-

1st : Interpret the Quality Gateways in terms appropriate to the technology involved (Where an existing interpretation is not available).

2nd : Select the appropriate Method to use to accomplish the state transitions. Where a Capability exists and is appropriate to use, it should be selected.



Blank Quality Gateway Form

Quality Gateway Criteria For :

Specification Entry Req:

In State:

Comment:

Development Entry Req:

In State:

Comment:

Alpha Entry Req:

In State:

Comment:

Beta Entry Req:

In State:

Comment:

Release Entry Req:

In State:

Comment:



Appendix B : ModesRoute Stages

Product Idea RECURSION INPUT FOR LOWER-LEVELCOMPONENTS OR SUB-SYSTEMS

a) Product Idea

Function : Inputs :

Product Idea :

• Ideas, Market feedback, Customer needs

Outputs : • Enough of an understanding to participate in an interactive understanding of consolidating the functional and none-functional behaviour of a proposed development.

Commentary : This is Conceptual step, it is a consolidation of input and formulation of an idea stage, it is a human process.



FormaliseRequirements

PRODUCTREQUIREMENTS

SPEC.

Commercial RestrictionsRe-Use Restrictions

Reproduction Restrictions

b) Formalise Requirements

Function :

Inputs :

Formalise Requirements :

• An idea of a product, with enough of an appreciation of its environment and application to appreciate how it might be used. Also enough of an understanding of the Market and the product's Value.

Outputs : • A Product Requirement Specification, including corporate parameters, timescale, functional and none-functional parameters. This should not prescribe implementation details, unless it is a specific part of the requirement.

Commentary : Although considered complete, it is possible (probable) that changes will be required in the Requirement Specification as the subsequent stages are actioned. (The main data-flow arrow is downward, but there is a small arrow in the return direction … this applies for all stages). Model will belong to the customer as a reference for the object development.



Functional Design

System Implementation

SYSTEMFUNCTIONAL SPEC.

PRODUCTREQUIREMENTS

SPEC.

c) Functional Design

Function : Functional Design :Development of the Functional Block Diagram, identifying the major function blocks and the principle interconnections between them.

It also quantifies the principle 'controls' and 'behaviour' that will be used as the basis of confirmation of functional behaviour later in the design process.

Inputs : • Product requirement Specification

Outputs : • System Functional Specification

Commentary : This is used as the basis of the next phase of implementation, and also as the basis of the Functional Testing which will occur. Model may be passed to a customer with a Pre-Alpha grading … as long as the customer is aware of its restricted functionality.



Architect &Partition System

COMPONENTREQUIRMENTS

System Integration

INTEGRATIONPLAN

d) Architect & Partition System

Function : To identify the Functional Components and their Interactions. And to establish how they will be implemented (HW/HW, HW/SW, SW/SW).

Architect & Partition System :

Also to establish how the Functional Objects will be Integrated after they are become available

Inputs : • System Functional Spec. • Commercial Restrictions • Re-Use Restrictions • Reproduction Restrictions • Summary Information

Outputs : • Component Requirements • Integration Plan • Architectural Requirements

Commentary : Behavioural modelling of architectural decisions, is important part of getting this phase right. Knowledge Based approaches might apply. Model may be passed to a customer with a Pre-Alpha grading … as long as the customer is aware of its restricted functionality.



Comp't Requirement

Comp't Requirement

Comp't Requirement

Comp't Requirement

Comp't Requirement

Comp't Requirement(Test 1 Bench )

Comp't Requirement(Test 1 Bench )

etc.etcHW/HW:AnalogueHW/HW:HDL

HW/HW:DigitalHW/SW:Low-LevelSW/SW:HDL

Component /Sub-Syst. Prep'n

Component Preparation

ObjectRequirement

ComponentRequirements

New ComponentsTo Library

SourcedObject

Com

pone

nts

&/o

rS

ub-S

yste

ms

All Comp'sPrepared

e) Component Preparation

Function : This is the 'many task' activity of implementing the Components (& Sub-Systems) identified in the earlier analysis stage.

Component Preparation :

It has some features of particular note … • That during this phase, components can be designed in isolation • Components may be Sub-Systems and may be constructed out of other components or sub-

systems … though not usually from another being developed at the same level. • The Requirement Specification is the basis for verification of the functionality of the

Component being implemented. As such it must exist in a simulate-able form. • That Requirement Specification and the component implementation must agree by the time

the preparation of the Components is complete, and may iterate to achieve this. • The nature of the components can be conveniently categorised as HW/HW, SW/SW or

HW/SW and independently optimised design tools can be selected to provide for the development of each of these. (Spice/VHDL/CoSim/C/etc)

• There will always be at least one HW/SW component in a System-Level product. • There may well be several (many) instances of a type of Component development (EG :

Several HW/HW components. • This activity makes use of support information from a library source, to achieve its

functionality. • Even when an object is available directly from the Re-Use library, it will need some work

before it is used

Inputs : • Formal description of the components to be produced (Architecture Format) • Design information from the Re-Use Library (Library Format)

Outputs : • Objects for the next phase of the Product Implementation (Data Format) • Object requirements from the Re-Use Library (Library Format) • Re-Use Objects for the Library (Library Format)

Commentary : This model may not adequately reflect the need for re-partitioning during the course of design. Integration of components may take place informally during this stage for confidence reasons.



System Integration& Prototype

Integration Spec.(Functional Test2)

ARCHITECTURALREQUIRMENTS

ALL COMP'SPREPARED

f) Integration Spec. | System Integration & Prototype

Function :

The Test-Bench which will be used to verify the correct operation of the System Integration and Prototype device, in both the simulation environment and also the prototype product (physical).

Integration Specification :

Inputs : • An Integration Plan from the Architect & Partition System stage

Outputs : • Test-Bench • Support documentation

Commentary : Interacts with the Integration Specification until a satisfactory agreement is achieved.

Function :

This is primarily a Component Assembly and Basic Functionality assessment stage. It is the task of integration of the prepared components and the creation of the prototype system.

System Integration & Prototype :

• Compliance to all interface requirements must be established. • All components must be available • An Integration Plan must be available

Inputs : • All the prepared Components • Architectural Guidance

Outputs : • Prototype product suitable for Beta Trials to commence (Suitable for first customer assessment).

• Information to finalise the Product Specification (and final test bench)

Commentary : Interacts with the Integration Specification until a satisfactory agreement is achieved. Product may be passed to a customer with a Pre-Alpha grading … as long as the customer is aware of its restricted functionality.



Acceptance Trials(Alpha & Beta)

Functional Spec.(Verification Test3)

g) Functional Spec. | Acceptance Trials

Function : Establish Test-Bench which will be used to verify the correct operation of the prototype product (physical) in the Acceptance Trial stages.

Functional Spec :

Inputs : • An System-Functionality Plan from the Functional Design stage


Commentary : Interacts with the Acceptance Trials until a satisfactory agreement is achieved.

Function :

This is primarily a customer assessment stage. It is the task of verification that the device behaves as required by the application.

Acceptance Trials :

• Compliance to all interface requirements must be established.

Inputs : • Completed System Integration prototype

Outputs : • Prototype product suitable for Reproduceability Trials to commence • Information to finalise the Product Specification (and final test bench)

Commentary : Interacts with the Functional Spec until a satisfactory agreement is achieved. Product may be passed to a customer with an Alpha or Beta grading … as long as the customer is aware of its restricted quality.



AssessReproduceability

Product Spec.(Reproduction Test4)

(SUB) SYSTEMTO LIBRARY

h) Product Spec. | Assess Reproduceability

Function : Establish Test-Bench which will be used to verify adequate conformance of the manufactured product to the behaviour of the verified prototype.

Product Specification :

Inputs : • An Manufacturing Test Plan from the System Integration & Prototype, & Acceptance Trial stages.


Commentary : Interacts with the Acceptance Trials until a satisfactory agreement is achieved.

Function :

This is primarily a test of reproduction and distribution stage. It is the task of verification that the device is compatable with the reproduction and distribution methodology chosen, with an acceptable degree of difficulty to the customer.

Assess Reproduceability :

Inputs : • Prototype with completed Acceptance Trials • Reproduction documentation

Outputs : • 'Formula' for reproduction • Pre-Production Product suitable for general supply

Commentary : Interacts with the Customer and earlier design stages until a satisfactory agreement is achieved. Product may be passed to the customer as a Full-Release staus.



Reproduce

i) Reproduce

Function : Inputs :

Reproduce :

• Reproduction Formula and documentation

Outputs : • Freely available Product (With all of its Aspects)

Commentary : This may be a disk file, a chip or documentation. All of which are shipped to the customer (at the next level of hierarchy) in an appropriate volume and with an appropriate Full-Release quality.



EXTERNAL REQ'S

OBJECTREQ'S

COMPONENTSTO LIBRARY

SUM

MA

RY

INF

OR

MA

TIO

SOURCEDOBJECT

EXTERNALOBJECTC

om

p't

& S

ub

-Sy

st.

So

urc

e (

Lib

)

j) Comp't & Sub-Syst. Source (Lib)

Function : This is a repository for Objects of known quality, with their associated views. It may be a combination of real libraries, on one or several geographically distributed sites.

Component & Sub-System Source (Library) :

Inputs : • Objects which have some reuse value • All of their associated views • Known quality • Known terms and conditions of use

Outputs : • Objects which have some reuse value • All of their associated views

Commentary : The library may commission Objects in response to requested (or anticipated) demand, these in turn will make use of the ModesRoute (which is in effect a Design-Step) for implementing the next level below.



EXTERNAL REQ'S

Ext

ern

al

Pre

pa

rati

on

EXTERNALOBJECT

R

k) External Preparation

Function : The use of external facilities to implement required Library Objects External Preparation :

Inputs : • Real or perceived need

Outputs : • Library Object of known quality, with all its views

Commentary :

MODES Route - 27may98

Technology

Transcript of MODES Route - 27may98