MODES Route - 27may98
Upcoming SlideShare
Loading in...5
×
 

MODES Route - 27may98

on

  • 623 views

HISTORY. I was the author of this Public Deliverable for the OMI/MODES Project (ESPRIT 20.592 - TR124) in 1998. It is an interesting to see what has changed in 15years. (See ...

HISTORY. I was the author of this Public Deliverable for the OMI/MODES Project (ESPRIT 20.592 - TR124) in 1998. It is an interesting to see what has changed in 15years. (See http://cordis.europa.eu/esprit/src/omi20592.htm)

Statistics

Views

Total Views
623
Views on SlideShare
623
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

MODES Route - 27may98 MODES Route - 27may98 Document Transcript

  • ESPRIT PROJECT 20.592OMI/MODESModular MicroElectronic-System Design- OMI/MODES-The ModesRoute MethodWritten By: Ian PhillipsMitel SemiconductorIssued By: Colin TattersalMitel SemiconductorProject CoordinatorDelivered By: Colin TattersalPMC ChairmanMitel SemiconductorDeliverable id: TR:1.2.4Document code: RDS/ESG/008-20Issue Date: 27 May 98Availability: PublicThis 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 liabilityfor errors or omission. No part may be reproduced or used except as authorised by contractor other written permission. The copyright and the foregoing restriction on reproduction anduse extend to all the media in which this information may be embodied.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 2Print Date: May 31, 2013Change Summary:Issue No Description of Changes.x1 (x1) First Pre-Issue : Released for discussion by ModesRoute Work-Group.Issue number .x1Number of pagesAuthor I PhillipsDate 27 May 98
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 3Print Date: May 31, 2013Table of Contents Page No1. Purpose................................................................................................................................. 42. References & Related Documents ........................................................................................ 43. Abbreviations ........................................................................................................................ 54. Introduction ........................................................................................................................... 64.1 Silicon Capacity - The Motive Force ................................................................64.2 The ModesRoute Method.................................................................................74.3 System-Level Products ....................................................................................74.4 Development....................................................................................................75. ModesRoute Scope............................................................................................................... 95.1 Systems and Components...............................................................................95.2 Unique features of Systems...........................................................................105.3 Short TTM......................................................................................................135.4 Productivity ....................................................................................................145.5 Right-First-Time .............................................................................................155.6 ModesRoute Scope … Summary...................................................................156. The Design Process.............................................................................................................. 166.1 Products and Aspects, Components and Elements.......................................166.2 The Development-Cycle.................................................................................176.3 The Design-Step............................................................................................186.4 Hierarchy in Design........................................................................................206.5 Formalised Design-Steps...............................................................................226.6 Formalised Implementation............................................................................246.7 Formalised Verification...................................................................................256.8 Design For Verification...................................................................................267 Formalised Requirements ..................................................................................................... 288 Partitioning and MacroFunctions........................................................................................... 308.1 The Minimal Hardware MacroFunction.........................................................308.2 The Normal Hardware MacroFunction..........................................................328.3 The Highly-Capable Hardware MacroFunction.............................................338.4 Autonomy in MacroFunctions.........................................................................338.5 Architecture in MacroFunctions......................................................................349 The need for Debug .............................................................................................................. 3510 Re-Use.................................................................................................................................. 3610.1 Aspects of Reuse...........................................................................................3710.2 Intellectual Property .......................................................................................3811 Configuration Control ............................................................................................................ 4012 The ModesRoute Diagram .................................................................................................... 4113 Tool Mapping to ModesRoute ............................................................................................... 43Appendix A : Quality Gateways ........................................................................................................ 45Appendix B : ModesRoute Stages.................................................................................................... 48
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 4Print Date: May 31, 2013- OMI/MODES-The ModesRoute Method1. PurposeThis document is the consolidation of the ModesRoute Modular Micro-System Design Methodology. It is theconsolidation of the work carried out in the OMI/MODES Project (20.592), and the discussions and workshops thathave 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 ofMicroElectronic-System products, which because of its acceptance will be used by tool vendors as a road-map forthe 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] Moores 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)
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 5Print Date: May 31, 20133. AbbreviationsArchitecture The outline of a likely implementation (High or Low level), which makes use of historicand commercial judgement.Component (See section 5)Concurrent Development Development of Aspects/Components & the Product in parallel (ie not waiting forcomponents 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 documentationDeployment Support Tools Tools which support the subsequent use of a product, which, though not directly a partof that product, enable the product to be deployed and thereby facilitate it reaching itsfull market potential.End-Product The item which is sold to the end-customer (Normally a consumer) and which results ina prime revenue stream to the supplier.Formal Methods Mathematical technique for proving the absolute equivalence between two items. In thisinstance a high-level functional description and the description of a lower level ofimplementation.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 theone that was functionally verified.MicroElectronic-System A System-Level Product whose functionality is implemented in a few Micro-Electronicdevices (solid-state integrated circuits).Product The item which is designed and which is subsequently to be reproduced and sold for orin support of prime revenueQuality An abstract concept encapsulating customer (end user) satisfaction.Quality Gateways Standardised quality levels for the release of information with regard to the stages ofdevelopment of a Component / Aspect or Product (or Capability).Solid-State-System (SSS) A System-Level Product whose functionality is implemented in a few solid-stateintegrated 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 (oneof) the hardware platform of the SOC … without the software component it cannot be acomplete 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 ProductDevelopment.Use-Cases The examples of use and misuse of an object that will be used as pass-fail criteria forthe 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 individuallydifferent tools or processes forming the Development Process.VSIA The Virtual Socket Interface Association.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 6Print Date: May 31, 20134. IntroductionThe 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 SemiconductorCheney ManorSwindonSN2 2QWUnited Kingdomhttp://www.gpsemi.com/Etnoteam SpAVia Adelaide Bone Cairoli, 34I-20127MilanoItalyhttp://www.etnoteam.it/TAC ABJägershillgatan 18S-213 75MALMÖ,SWEDENhttp://www.tac.se/UMISTDept of ComputationSackville StreetPO Box 88ManchesterM60 1QDUnited Kingdomhttp://www.umist.ac.uk/Universitá degli Studi diMilanoDipartimento di Scienze …… dellInformazioneVia Comelico 39I-20135MilanoItalyhttp://www.unimi.it/Visual ToolsAlmansa, 62E-28039MadridSpainhttp://www.vtools.es/By bringing together these disparate organisations and through watching each-other work, the OMI/MODESproject has been uniquely positioned to gain an overall perspective of System-Level design in a MicroElectroniccontext, appreciating the differences between us and the commonality of approaches and problems. Accordinglythe ModesRoute represents a unique System-Level view on that process …4.1 Silicon Capacity - The Motive ForceNearly 30 years ago Gordon Moore gave us Moores Law [6], a yardstick for the Integrated Circuit industrystating that silicon logic capacity would double every ~18 months for the foreseeable future … Over theyears 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 productapplication, raising the question, just what they can all be used for ? The reality seems to be that many ofthe things that we currently recognise as systems could be implemented on 120M transistors … or the 1Btransistors 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" areterms that have emerged into common usage … they are of similar meaning and may be considered assynonymous).Evidence available from several sources, indicate that todays 2-10M transistor component designs take ~50-200 my to implement. Even linearly interpolating (optimistic) this equates to 2000 my at 100Mtransistors ! However, by the time that the Systems aspects of Software, Architecture and Validation areincluded 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 beadequate ; The motive for finding a System-Level Product development method, and thereby achievingorders of magnitude improvement in productivity, is high !
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 7Print Date: May 31, 20134.2 The ModesRoute MethodUsing the divide-and-conquer approach that has been shown to be successful throughout history, theMODES project chose to address the methodology of System-Level design separated (at first) from theimplementation 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 theunderlying 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 whichseparated from the Implementation, can be optimised in isolation from the Tool(s) that do/will supports itsneeds.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 notconfused with the functional objective to which it is deployed.To draw this diagram, we must first comprehend the characteristics of a MicroElectronic-System and alsothe scope of the Development task …4.3 System-Level ProductsThe concept of System is one that is conceptually appreciated by everybody … and yet its definition is notreadily subject to analysis. It is very difficult to define a system, in any fixed context as practicallyeverything 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 tothe 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 developmentactivities across the full sphere of experience … involving hardware, software, and human interfaceissues … and their acceptable interplay.4.4 DevelopmentThe role of development is to move a product from an idea to a, customer satisfying, manufacturablereality, in a timely cost-effective manner.For a Component, the product may be completely described by a simple algorithm, the RequirementSpecification. Its implementation in a single, fixed function, chip is readily verified as achieving therequirements … thus satisfying the customer. Its implementation is readily verified for manufacturability asit either works or does not. Because of its regularity, ASIC approaches may be deployed to manage costand time.For a System-Level Product however, it is much more difficult to define the requirements, establishcustomer satisfaction and quantify manufacturability. Firstly, the full details of the requirement are notknown at the start of the development. Secondly, that it is not easy to verify that the object that wascreated 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 somerespect, yet most of it is perfectly acceptable to the end-customer. The uncertainty of the product and itswide 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-LevelProduct are significantly different.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 8Print Date: May 31, 2013This outlines the context of the MODES Project and the ModesRoute, and the themes outlined hereare returned to and elaborated upon, several times in the text that follows …
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 9Print Date: May 31, 20135. ModesRoute ScopeBefore the ModesRoute can be drawn it is necessary to have a good understanding of its span of authority. Tohave a clear understanding of what is within its scope and what is not !5.1 Systems and ComponentsAt first appearance, the prospect is onerous … if a System can by anything then surely we are talkingabout the development method for anything ! It takes an act of faith to say that the design process foranything is essentially the same (Which I believe to be the case) … but to be on the safe-side, it isreasonable 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 fullmanufacturing readiness, then it includes techniques beyond our frame of reference (eg: Conveyor beltand flow soldering techniques !). So again if we acknowledge the wider sphere, but are prepared torestrict our selves to the MicroElectronic context, then we can usefully proceed.Fig 5.1: Architecture of a MicroElectronic SystemA 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 completein 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 thehigher-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 functionalitywhich 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 timeof development, its System-Level functional requirement is the guiding constraint, and theachievement of it, is the indication of completion.… The MicroElectronic System will normally have an overall architecture consisting of a CentralProcessor, Instruction and Data Memory, one or more Co-Processors and an External Interface. It willhave Temporal constraints and deliver complete-in-context functionality at the interface. (See Fig 5.1)MainExecutionHWCo-ProcessingExternal IOInterfaceMainProgram &Workspace(Memory)TemporalConstraintsDelivers Complete Functionality
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 10Print Date: May 31, 2013Undoubtedly there is scope for all of these definitions to be refined and improved, they do exhibit a goodmatch with common understanding of the terms and their application, so are believed good enough foruse at this time.5.2 Unique features of SystemsFrom these definitions it is possible to make some observations about systems and see how they matchwith 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 jobexpected of it completely. A MicroElectronic-System would differ from this only in that when the physicalinterface is taken away, that the system-functionality is provided by the MicroElectronics within it. This iseasy to appreciate in the case of a portable telephone, the case, keypad, microphone, battery, etc, do notdirectly contribute to the system functionality, only peripherally … it would be readily possible to changethem for others without changing the operation of the phone. It is possible to imagine systems where this isnot the case. A car is such an example, when you take away the mechanics, the object loses itsfunctionality.However, though the microphone may be considered as a Component or Sub-System to the portabletelephone designer, it is a System in itself to the microphone designer ! The same argument applies to theportable phone, which is a system to the phone designer yet is a Component or Sub-System to thenetwork provider. So in the case of the microphone, we might reasonably expect that it is a Sub-Systemitself … 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 ProductA Component on the other hand is always incomplete … though to prevent the case of attributing physicalproperties to it, the specific atomic behaviour is excluded. Thus a resistor is a component as is the plasticcase of the portable phone. Interestingly a microprocessor without program memory and code is also acomponent !The notable implication of this is that many of the most complex MicroElectronic Products we design andproduce today are Components, not Systems ! Products like PentiumPro, the huge DRAMs, 3DRendering Engines and MPEG encode/decoders are components … which means that the drivers beingused 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-Productfunctional need and, end with the implementation of an economically viable, manufacturable, customer
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 11Print Date: May 31, 2013satisfying End-Product reality … If we start any lower, or deliver any less, then our Product it is only aComponent !It is currently fashionable to think that a System-Level MicroElectronic product consists of Hardware andSoftware components. Whilst this may be an adequate observation of a System-Level product, it is notenough to describe the elements that have gone into its development ! Architecture, Documentation,Deployment Support Tools, Use Methods, Functional Verification, Manufacturing Test, Quality, TTM andCost are all elements of the design process. It may be argued that these are also elements of aComponent design process as well, but the scale of many of these are significantly different between thetwo examples.CUSTOMERrequirementsanalysisspecificationsystem designCUSTOMERacceptance testingsystem testsystem integrationuser needsspecificationuserrequirementssystem architectureand subsystemspecificationmodulespecificationdeliveredsystemintegratedsystemvalidated andverified systemtestedsubsystemtested modulemodulecodesubsystemintegration andtestsubsystemintegration andtestsubsystemintegration andtestdetailed designdetailed designdetailed designmoduleimplementationmoduleimplementationmoduleimplementationmodule testmodule testmodule testdelivered systemmeets user needssystem meetsuser requirementssystem agreeswith specificationsubsystem agreeswith specificationmodule agreeswith specificationFig 5.2.2: The V software development life-cycle from a testing viewpointTake for example the Architectural aspects of a NAND gate … they are all physical and they are readilycaptured. The architecture of a Multiplier is significantly more complex and must take into accountadditional features of performance, test, power and size. Similarly the task of Verification of functionalconformance (establishing that it does what it is supposed to do under all combination of inputs) is hugelydifferent … as Intel will undoubtedly remember with their Pentium problem in 1996.… If anything, the fact that Components exhibit the same design elements confirms the conceptthat development of anything involves the same process steps … just that they are not always the samesize !Fig 5.2.1 is extracted from the MCC/OMI CoDesign report [7]. It is overlaid with the increasing siliconcapacity 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 theArchitectural 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 implementationtasks have become significantly smaller in magnitude … This is attributable to the improvements in toolsand methods in this area. It is valuable to note however that the additional bubbles are also becoming partof the design task … and most notably the System-Level ones are growing larger ! The need to focus onthese areas is now paramount as further attention to the lower-levels will now lead to significantlydiminished returns in the larger context of System-Level design.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 12Print Date: May 31, 2013Though Figure 5.2.1 apparently says it all, in reality it only illustrates half of the problem. The task isconsidered 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 simpledigital 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 (Fig5.2.2). This has a progress from left to right, and top to bottom to top. The first part of which is concernedwith the identification of a products Requirement and the increased detailing of the proposedimplementation. The second part is concerned with the progressive Verification and release (andmaintenance) of the product … The actual Implementation, (module code) is a point at which acompilation process (or formalised translation to another existence) is done.The V-Diagram encapsulates development responsibility for Product creation from its basic originsthrough to and including the delivery of the end product. It identifies the progressive Detailing andVerification 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 ? Andwe would expect a MicroElectronic System to be any different to a Software System, simply because itsorigins are in the increased functional capacity of Silicon ? The answers are respectively ; That theomission is from history, where gate-level functionality was the measure of completion ! … There is nodifference between the systems !Fig 5.2.3: Product Life-Cycle … with a hardware angleSo Fig 5.2.3 is particularly valuable, being an independent rendition of the V-diagram, given an IChardware flavour by its author, a Mitel engineer, M Dunk. Though its exact interpretation is open todiscussion, 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 arehappy with a gate-level implementation. The ASIC world has been dominated by this level ofdevelopment. The customer specifies a netlist, the ASIC house delivers a functioningequivalent of the netlist on silicon, verified by a logic tester. The customer accepts allfunctional responsibility and all higher level architectural and debugging problems.For higher level products, however, if they are specified at Behaviour level and above, thenthe end product must be delivered at the same level ! It is not acceptable to specify a
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 13Print Date: May 31, 2013Calculator requirement and deliver a logic circuit … the circuit must have been Verified to bea Calculator by the design authority and the correlation between the Functionality and theManufacturing Test established and agreed.… The implication of specifying and delivering a System-Level Product is significantlydifferent to that of the Component-Level product… The ovals, added later, illustrate another important message, that the increasingcapacity of silicon ICs lead to the inevitable inclusion of increasing System-Level context intothe products.2. That the current improvements in Design Automation Tools only addresses the Specificationside of the Life-Cycle … the Detail-Phase.This is very significant, because it illustrates the fruitful-opportunity for optimisation of overallaspects … 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, especiallywith regard to the System-Level product, to establish that our half-way premise is a true reflection ofreality. 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 isundoubtedly 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, andcontinued improvement of limited aspects in isolation will not significantly improve the overall developmentprocess. The need for the identification of a System-Level Product Development & Introduction Life-Cycle,the ModesRoute, is thus identified.5.3 Short TTMThe traditional view of a System-Level Product has an implicitly complex introduction history. Systemsusually (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 modelsinvolving 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 itemsare at the end of their evolution (and about to die-out) few are in their first iterations … most are in theiriterative improvement cycles.Unfortunately the entry cost to enter a product market which is already iterating, is prohibitive, as the firstone (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 establishedcompetition. As most developers use the same market research organisations, it is inevitable that when aproduct 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 apparentlyno competition !… However, as even the best predictions of new markets are notoriously unreliable, then the riskof 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 moderatelysuccessful product must be prepared to start as many as ten developments. There are no reliable figuresavailable for this, but it is my impression that about 10% of architecturally new product developmentsstarted are moderately successful, and about 1% very successful. For product evolutions, there is an~70+% probability of achieving the same level of business ; ~10% probability of a significant increase ofbusiness ; 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 nothappen at all.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 14Print Date: May 31, 2013The development of new systems has traditionally been a very protracted, ISDN has been over 20 yearsgetting to a competitive technology, GSM telephony has taken 10. DVD looks like it is going to achieve fullcompetitive supply in about 5. This can be considered as True TTM, the time from first product conceptidentification to competitive market supply.Clearly the longer True TTMs allow plenty of time for iterative improvement, but even the 5 year can beeffectively utilised with an aggressive market entry strategy. Assume a 3 year gestation period and utilisinga pipeline scheme. The 1stproduct arrives after 3 years and is delivered to an unready market. A 2ndgeneration product, started after ~18 months, benefiting from the lessons learned in the first developmentand arriving at the market 18 months after the 1st,, just as the market starts to build. The first team, startson the the 3rdgeneration product which is delivered at year 4.5 into an established market … but now withcompetition. Positive cash-flow may not occur until the 2ndgeneration is launched. A successful 3rdgeneration product is the gateway to longer term success in the market and may represent the firstPositive 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 1Development-Cycle-time limit of 2-3 years, and at current rate of time-erosion, this will happen within thenext 5 years. In this scenario, no supplier will have any market to himself even the first time, so competitiveproduct has to be developed the first time. Further, because the market is (by definition) new, engineerswith appropriate background cannot be bought-in, so the architectural skills have to be provided by theuse of appropriate tools. The evolutionary pipeline must still be established, but ~90% of players canexpect to fall at the first product generation.… The pain for development of a speculative product must be minimal and the ability to reusecomponents, even whilst they are being developed must be slick. With shortening True TTM, and need formultiple and continuous simultaneous evolutions, productivity must reach an all-time high.5.4 ProductivityThe driving force for the System-Level Products and their development is the exponentially increasingcapacity 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] availablefor product application. Assuming that System-Level Products based on this capability will be designed asan entity and will comprise between 1 and ~10 devices (the 1G transistor product is at hand). Though Sicapacity is the enabling technology, many of the transistors will be used for software functionality ormemory. Here there is significant history which demonstrates that size (bytes) of software in any product isalso doubling on a 12 month cycle.Though these System-Level Products when they are analysed (retrospectively), will be seen to consist ofonly hardware and software. The correct conclusion to draw from this, is not that that hardware andsoftware is all that needs to be designed, but that those are the only parts of the development which areexplicitly 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 tobe designed, before the product earned its place on the PCB !Evidence available from several sources, indicate that todays 2-10M transistor Component-Level Products(ICs) take ~ 50-200 my to implement, even linear interpolation (which is optimistic) leads to 2000 myprojections for 100M transistors devices. By the time Systems aspects of Software, Architecture andValidation are included this is unlikely to be less than 6000 my. Using conventional approaches, the impacton TTM and the cost will be severe !The necessary productivity will not come about through evolution, revolution is necessary ; System-LevelProducts need System-Level design methods, supported by appropriate tools. The Method must cover thecomplete span of product development and must encourage the use of reuse in all aspects of a productslife-cycle. To achieve 6000 my products measured against todays methods, from the order of 10 my ofeffort requires ~600 fold improvement of productivity … reuse must pervade all aspects ; the completedevelopment process must be supported by competent tools … nothing less will deliver !
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 15Print Date: May 31, 20135.5 Right-First-TimeThe need to develop System-Level development of (relatively) optimised solutions in short time periodsessentially demands right-first-time performance. Is this a reasonable expectation for a System-Levelproduct development ?This area is very tricky to quantify, but software systems have been designed in the past and the results ofthese have been quantified … and there is grounds for believing that the lessons learned are applicable tothe development of systems involving hardware [12][13].Dr Hatton [13] illustrates that for existing software products it is unusual for residual functional errors to beless than about 5-10 errors per thousand lines of source code (5-10 /KLOC). This result, amongst manyothers, is confirmed by Mr Jones [12]. This result is reflected in our own experiences of the use of PCsand 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 forothers. The practical implication of this is that we cannot expect a System-Level Product to be right, butonly to be acceptably right ! The consequence of this on the whole product release process andmanufacturing will be profound.Whilst it is reasonable to expect that many of the errors will be convergent (effect tends to fade out) andonly a few directly divergent (effect tends to escalate, leading to major failure) ; convergent errors cancombine with each other in the huge state-space of a system to produce divergent behaviour. Becauseerrors are not intentional, their behaviour is not predictable, accordingly the use of large Alpha and Betatrials are required to establish the error-content and nature by experimental methods … Design byiterative 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 whichcombined with much smaller Alpha and Beta trials (An initiative lead by IBM and Bell , but now beingfollowed by Microsoft !), are proving a much-more effective tool … not to improve the overall residualerrors, but to get to the product end-point more quickly by reducing the iterations ! The formality consistsof 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-practicetechniques if a right-first-time unified-methodology is to develop. It must also accept that the product (orcomponents thereof) whilst being less than perfect, yet may be perfectly acceptable in the end productsfunctional context !… Close enough is good enough !5.6 ModesRoute Scope … Summary1. Stars at System-Level Requirement Development …2. … Ends at System-Level Product Delivery3. 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.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 16Print Date: May 31, 20136. The Design ProcessCloser examination of the design process of the System-Level Product identifies some concepts which areelaborated upon in the following sections …6.1 Products and Aspects, Components and ElementsWhen we look at System-Level Products we find that they have Aspects, which represent significant itemsof development in themselves, and which may be in orthogonal technologies. For a typical programmableProduct, these Aspects would typically be (amongst other things) : The Silicon, The Boot-Code, TheApplication Code, The Demo PCB, The Development Tools and The Design Manuals. Aspects are oftenSub-Products in their own right, and may be sold independently … they are not (often) sold together as afixed-kit, and there may be one Aspect (Eg: The silicon) which is the main target revenue-earner, yet theothers are a part of achieving that revenue. (See Fig 6.1.1)Fig 6.1.1: Product & Aspect, Component & ElementLooking closely at individual Aspects, we find that they are made of Components which themselves haveAspects (Which for clarity we will call Elements) and that the Elements of the Components contribute to thedifferent Aspects of the Product.There is no definitive list of Aspects of a Product, nor Elements of a Component. Product evolution willcontinue to introduce new Aspects and Elements as features previously outside of today’s product becomepart of tomorrow’s deliverable.The implication of this is that Aspects and Components are pseudo products in their own right and areused in the higher-levels of the Product development. Accordingly their quality-status has to be establishedand recorded before they can be released for use by those higher levels, and that quality-status must beunderstood by the user (Take particular note, there is no requirement that the quality is ‘perfect’ only that itis understood by both parties involved in the transaction).Product(Eg: Butterfly)DevTool-Asp.(Eg Compiler)Si-Aspect(Eg: SA024)Docn-Aspect(Eg: User Manual)PCB-Aspect(Eg: MAP Board)Component(Eg UART)Component(Eg ARM7)CLA HardwareSoftwareAudit ReportElements - Of a ComponentRTL HardwareDocumentationTest BenchSW-Aspect(Eg: Drivers, SIFs)Component(Eg DMAC)Component(Eg MPC)Aspects - Of a ProductComponents - Of an Aspect
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 17Print Date: May 31, 2013The implication of this is apparently onerous layers of release stages and sign-off’s, which unless it issupported by a Configuration Control Tool will become a major organisational headache.6.2 The Development-CycleIf we consider a Complex Product as comprising (many) Aspects, with each Aspect being composed ofComponents each with (many) Elements (Fig 7.1.1.), then a hierarchy of design and release processesmust be involved. The good news is that despite their differences, the same general Method can be usedfor 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 andtested against the requirements of the specification. Where it fails to meet the requirement, thedevelopment tasks are ‘continued’ until conformance is achieved. Occasionally, the act of development willuncover fundamental limitations with the specification and lead to its modification.Fig 6.2.1: The Development-CycleDuring the course of development of a Complex Product, the component parts will be developedconcurrently with the products hierarchy, demanding information flow from the lower level items from theearliest stages, through to full-release. Further, in optimised development environments, there will berequirements for components to be designed for deployment in more than one higher-level product (in theirfirst implementations). This practical Concurrent Design and the methodology must recognise itsimplications. By formalising the states and the quality implicit, information can be exchanged with theconfidence 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 AppendixA), 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 areused to extract data from a component development, before it is used at the next level (above). The qualitylevels illustrated at L1 to L5, where L1 is minimal, and L5 is excellence. The hierarchical Product is ofoverall status equal to the lowest of its component. Using the scheme, hierarchical users of information willbe in no doubt about the quality of the data that they are using from their suppliers … and by implicationthe 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 beshown to have Aspects also constructed out of Components, with Elements. Indeed, the Components of aCapability in many cases will be the same as those used in the development of Products !)Integration& VerificationDevelopment-TaskRelease AuditRelease Criteria* Specification* Development* Alpha* Beta* VersionExternalDataSpecification
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 18Print Date: May 31, 2013Fig 6.2.2: The Waterfall of QualityThe 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, sowe can consider them in a bigger context. Figure 6.2.3 is a rotation and translation of 6.2.1 … andincorporates an iconic version for use in subsequent diagrams. The various forms will be used, asappropriate, in the analyses that follow.RequirementSpecificationExpansion /Detailing(Design)ConformanceTesting ?ImplementnDescriptionNYFig 6.2.3: Alternative representations of the Development-Cycle6.3 The Design-StepHierarchy is necessary because of the necessity to partition a task into smaller units. The size of thesmaller units may be determined by the need for productivity or the inability of a single engineer, or closelyco-operating group, to readily comprehend a greater one. In reality both of these are the same as the timefor implementing an object increases rapidly as it approaches the limits of comprehension. Accordingly weintroduce the idea of the Conceptual-Span, as representing the size of a task which is convenient to behandled. A Complex Product (System Level) will inevitably comprise several (many) of these workingtogether to deliver the required functionality. The size of a Development-Cycle is naturally that of theConceptual-Span, Fig 7.3.1 (Though this does not have to be a limitation, it helps to understand the needsof hierarchy if it is assumed to be the case).ProductAspect 1ComponentComponentComponent Aspect 2L1L4L2 L5L1 L1
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 19Print Date: May 31, 2013Fig 6.3.1: The Conceptual-Span & Development-CycleIt is significant to remember that tool developments supporting this need to expand productivity this in linewith the rate of product complexity expansion ... currently doubling every ~12 months. Clearly thisdemands introduction of increasing Conceptual-Span along with productivity of the Development-Cycleitself. 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 divisionis inevitable … partitioning of tasks into smaller more readily comprehended and managed units. Theconcept 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 andagreed. Frequently this is impossible, solely because the high-level functionality of the Product has notbeen understood completely (!), a situation which is understandable because of our history, but is notexcusable ! Additionally, although the interfaces may subsequently be modified, it will impact all of theoccurrences of its use (especially if it is in any way universal). Also it may make sense that the partitionedobject 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 ofwhich is largely understood by common practice.RequirementSpecificationExpansion /Detailing(Design)ConformanceTesting ?ImplementnDescriptionNYConceptualSpan
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 20Print Date: May 31, 20136.4 Hierarchy in DesignFig 6.4.1: Hierarchy of Concept-SpansFigure 6.4.1. illustrates the first two levels of a typical hierarchical product development. The output of thefirst (highest) stage of analysis, leads into further (lower) stages of analysis ; the fist stages will bearchitectural, the lowest stages will be implementational. A typical product, will comprise many lowerstages, as a single Concept-Span/Design-Step will frequently result in 3 to 5 lower-level requirements andhave 3 or 4 Concept-Spans of hierarchy … On this basis, a typical 4 Concept-Span deep product willinvolve 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 ofElements (or Aspects), which are effectively requirements for the performance of a Component (by theCustomer), such that when they are all combined the functional requirements of the product (level) will bemet. The Component implementer also follows the same Conceptual-Span / Development-Cycle as a wayto achieve his objective … though he adds other things to make his Component more suitable for his ownpurposes (principally ; manufacturability, quality, re-use and re-deployment). The result is that thefunctionality of the Component is at-least that required by the Customer… or to put it another way, theComponent has features which are not specifically used by the Customer. Accordingly, the componentmust have a test specification for its self, which is more extensive than the acceptance specification of theCustomer. As the Customers acceptance specification is his Requirement Specification, the RequirementSpecification that the Component developer uses is more comprehensive, and must incorporate theCustomers Requirement Specification as a sub-set within it. And the Component RequirementSpecification, becomes the Test-Bench used for determination of the completion of the development task.RequirementSpecificationExpansion /Detailing(Design)ConformanceTesting ?ImplnDescnNYConceptualSpanRequirementSpecificationExpansion /Detailing(Design)ConformanceTesting ?ImplnDescnNYConceptualSpanRequirementSpecificationExpansion /Detailing(Design)ConformanceTesting ?ImplnDescnNYImplnDescnConceptualSpan
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 21Print Date: May 31, 2013Fig 6.4.2: Inclusion of Additional Requirements… For this reason, the Requirement Specification at the entry of a lower-level Conceptual-Spanare 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 thelower-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 twoclasses. 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 - UnrefinedRequirement, S - Software, H - Hardware. Where S & H are the identified translation and R, theunidentified. It can now be seen that the process of Detailing involved in the Design-Steps stops when atranslation is identified for all Design-Step Requirements. After which it is just a case of doing thetranslations, combining the pieces, and the Product comes into being !… Well … right to a degree ! We have implemented the Detailing-Phase of the V-Diagram, andthe 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 tobe evaluated !ConformanceTesting ?ImplementnDescriptionNYAdditionalRequirements* Additional Features* Re-Use Parameters* Standards* Business Politicies* Manufacturing IssuesComponentRequirementSpecificationExpansion /Detailing(Design)HardwareDescription(s)SoftwareDescription(s)RequirementDescription(s)CustomersRequirementDescriptionImplementn Description
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 22Print Date: May 31, 2013Fig 6.4.2: Hierarchical Design-StepsTo examine the effects of this we must look more closely at the formality of the Design-Step.6.5 Formality in Design-StepsHistory shows that the way we design is to complete the creation step using ad-hoc methods, then testthe result against expectation to establish that it is achieved. Clearly the ends justify the means if theresult is what was expected … this is the source of the difficulty with design as it is based upon the use ofgurus and advanced techniques.If the Design-Step concept is right then it should be applicable to this model … and it is. Figure 6.5.1shows what we expect to deploy at each of the stages of the Desin-Step. Figure 6.5.2 shows how formalitymay be applied to this, illustrating how the Expansion/Detailing task, may deploy Heuristics andExperience, yet the output can still be formalised. But it also shows that the other stages must beformalised 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 isno specific need for the Conformance Test to be carried out at all (To be precise, there is no need at thisstage of the development cycle, though there is still a need for it at a later stage ; See 6.7). Indeed FormalMethods can be shown to be significantly better than a Conformance Test, which no matter how thoroughwill not test every combination of correct and incorrect stimulus and response.HW / SWModelCo-SimulationR H SR HH SR R SH SLogicalDesign
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 23Print Date: May 31, 2013The use of Formal Methods is very interesting and should not be prohibited within this context, we shouldanticipate that it will be deployed in certain Design-Steps, whilst others must continue with the Heuristicand Experience based approaches … in particular at the forefront of technology where by-definition, theapproaches to be deployed cannot be formalised, because they are not understood. Indeed, even theLibraries may be in a state of flux.Clearly there remains an issue of how well the Conformance Testing can establish compliance with therequirement, and the exercising Test-Cases should be selected very carefully to achieve maximumconfidence … but if the Conformance Testing approach is used, then the output from the Design Step willnever be strictly formal, only formalised … and of course this reflects onto the System-Level developmentas well which cannot then be formal either.Fig 6.5.1: Needs of the Stages of a Design-StepAs the selection of Test-Cases is so important, it is worth a little more attention. They would be in effect theexamples that are specified for the verification of the behaviour of the object of the Design-Step, asimulate-able summary of the Requirement Specification. This in turn specifies that the nature of theformality 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 toprove. Accordingly the specific Test-Cases will inevitably be a functional and none-functional sub-set ofthe Requirement Specification, the Use-Cases. As the Use-Cases can only ever (in all but the simplestcases) represent a small subset of all possible behaviour, the resulting Conformance Testing can only begood, not perfect ! So careful selection of Use-Cases to demonstrate the range of normal operation andmiss-operation, is an important part of the Design-Step …RequirementSpecificationExpansion /Detailing(Design)ConformanceTesting ?ImplementnDescriptionNY* Experience(Intelectual Property)* Libraries (History)* Methods* Tools* Heuristics* Methods* Tools* Standards* Methods* Tools* StandardsDesign Step* Data Base* Configuration Control* Documentation* Standards
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 24Print Date: May 31, 2013Fig 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 notadequately rigorous to constitute a Formal Design-Step, even if all of the other formal requirements aremet (which could be imagined). It is practical to achieve a Formalised Design-Step but not a FormalDesign-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 ImplementationUntil 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 whatpasses 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 describedthrough its hierarchy to a level where a suite of formalised (or formal) translation is identified … suchmappings 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 aspecific 2 input NAND function with timing, there is approximations taken about its actual performancewhich may under some circumstances effect its behaviour … Similarly in a compiler, there are translationand optimisation processes being run concurrently. In most substantial jobs will these tasks beingexecuted in an order or with data pattern that has never been seen before. Accordingly the result could beunpredictable. Accordingly, even at the end of the Design-Phase, the act of translation itself introducesuncertainty.RequirementSpecificationExpansion /Detailing(Design)ConformanceTesting ?ImplementnDescriptionNYRequirement 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 OutputExpansion / 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 OutputConformance 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 OutputImplementation DescriptionThe output data from a Design Step is a VerifiedImplementation Description Data-Base containingone or more of the following :-* Component Reqt Spec.(s)* Abstract Software Description(s)* Abstract Hardware Description(s)· Must be a formal Process.· Must be a formal Output(Formal)Design Step
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 25Print Date: May 31, 2013… So the answer would appear to be no, the act of implementation itself introduces errors from atleast two mechanisms (but probably many more ! ).6.7 Formalised VerificationSo because we cannot guarantee conformance in the translation process, we must propagate theConformance Testing after the Implementation translation stage …Fig 6.7.1: Architectural MappingIndeed it can now be seen (Figure 6.7.1) that the Use-Cases must be specified in such a way that they canbe applied to the reality of the implementation, to support the necessary Implementation Verificationtasks.… Not too complex for a single Design-Step, but a lot more complex when we look at theimplications of a multi Design-Step, System-Level Product Development as shown in Figure 6.7.2. (Thepartner to Fig 6.5.2) showing how the Use-Cases should be re-deployed to verify the actual physicalimplementation (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 theverification stages become a formality, a null-task. In the meantime, the resulting Product will have beenprogressively and thoroughly tested ; as well as it is reasonably practical to do so.RequirementSpecificationExpansion /Detailing(Design)ConformanceTesting ?TheoreticalImplnDescriptionNYConformanceTesting ?Actual ImplnDescriptionNYArchitectureMappingDesign Step Verification StepImplementationStepLogicalDesignImplementation
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 26Print Date: May 31, 2013Fig 6.7.2: Hierarchical VerificationBut there are implications of this on tool requirements and it is as well to point them out here. Figure 6.5.2and 6.7.2 identify the need for Co-Verification … a tool (or tools) which support concurrent simulation ofRequirements, Hardware & Software in the Design Phase, with the additional facet of Reality in theVerification Phase. This is the specification of the necessary Co-Design tools (it is not enough simply tomodel HW and SW !).… Additionally, it has an impact on implementation architecture, which should allow the access ofindividual blocks for verification, with the substitution of arbitrary parts with their functional-modelequivalents ! It is no-longer enough that (IC) designers chant the design for test mantra, now they mustalso chant design for verification !6.8 Design For VerificationIn the same way that design-for-(manufacturing)-test has many different implementation paths, so too willdesign-for-verification.The main lesson learned in the design-for-test era, was that the designer must consider test and testabilityas a part of the thing that is being designed, right from the first stages. As a result, certain types ofR H SR HH SR R SH SImplementH SHH SMAPH SMAPSMAPRequirement Productor *or *or * .or *Real HW / SWCo-VerificationReal HW / SW+ Model.Co-Verification
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 27Print Date: May 31, 2013functional implementations (Eg: FSMs, pseudo-static logic, etc) which were easy to design with, butdifficult 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 hadan architectural effect on the implementation methods.Design-for-verification will require a similar mind-set adjustment, and will also have architecturalconsequences. In the same way, it will not be possible to provide one solution for all cases, and a range ofmethods will be deployed, the most appropriate one (or two) being chosen in specific developmentinstances.An example of the approach that could be applied is that with knowledge that a Hardware Component of aProduct is going to become part of a System-Level Integration (SLI), that the test-bench used to developthe 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 Components 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 appliedonce 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 thetest-bench and the Component, then to use a hardware architecture which will allow those patterns to beapplied to the Component, as if it were the only thing on the SLI. This could be achieved using scan-patharound 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 aconsistent interface (The bus), it improves the prospect of Components designed in isolation correctlyinterfacing.…Undoubtedly there are many other approaches that could be deployed, once it is recognised thatVerification is a significant part of the Product Development task.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 28Print Date: May 31, 20137 Formalised RequirementsFigure 6.4.2 and 6.7.2 identified the need for a Co-Verification tool where Formal Methods could not bedeployed, to support the need for Conformance Testing in the Modelled and Real world. To achieve thissuch a tool needs to be able to simulate Requirements, Hardware & Software in the Design Phase, withthe additional facet of Reality in the Verification Phase. This need to include Requirements arises, becausethe Requirement Specification is really the customers test-bench … the criteria that he has decided willapply to a successful product development.To be simulate-able, the Requirements need to be formally captured, using a notation that is completeenough be used as a descriptor to a simulation engine. This can be very difficult, because the traditionalMarket/Customer lead view of the products functionality has limitations, because the customer does notalways (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 thecustomer. But even they have limitations, as they do not understand the customers market as well as hedoes, even if they have a better understanding of the technology that they are able to deploy. The mosteffective 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 iterationand should be discouraged if we are to achieve the tight TTMs required in the future. Looking more closelyat the process, it is possible to say that in principle at least, the iterations of the Requirement Spec are onlythe addition of details … though there are instances where the exposure of detail in the Design-Phasedoes mandate the fundamental change of requirement … but as these also call the future of thedevelopment into question, they would class as serious changes.Unnecessarily requirements also have the effect of causing serious changes to requirement specificationsfor no truly justifiable reason, so must be discouraged.So the need to develop good quality Requirement Specifications and to extend them down through thelevels 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 withthe customer and be simulate-able and be capable of having detail added later without influencing thebasic 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 ofphysics or against another requirement).The first point can be addressed by the simulation environment itself. It must be possible to give thecustomer 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 thesituation where the customer refines his requirements as a result of seeing the modelled behaviour of hisoriginal requirements.Clearly to be useful, the model must be provided with an interface to enable the customer to exercise it inthe way intended … indeed its use may require the provision of modelled support-tools, all of which willcomprise Aspects of the end Product. As a warning, it is easier to imagine and provide the simulated userinterface to a GSM telephone, but it is a lot more complex to provide it for a product which only has adigital or programmable interface, these lower-level requirements will need to be encapsulated for theAspects/Components of a product.A special case worthy of note is the specification of Interfaces. Though not a specific Component inthemselves, they are the mechanism by which users are able to guarantee the interconnection of theComponents 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 therest of the system. This is particularly important where the rest of the system does not (yet) exist. The useof agreed Interfaces is a very powerful approach for modularity and reuse and where common interfaces
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 29Print Date: May 31, 2013can be agreed, then powerful tools to test conformance to the interface, and to source and sink datasignificantly assist with productivity. It has to be remembered however, that the definition of Interfaces andany support tools is additional to the principle task at hand … they are not Components nor Aspects of theproduct. But their use should be encouraged from a quality and accuracy point of view, and their reuseencouraged from an efficiency point of view. One example, is an on-chip bus, another C++, but others maybe agreed optimised for other application needs. Clearly there is a requirement for a minimum, butcomprehensive 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 orhuman) is required to make a continuous assessment of the requirements. One way of achievingmeaningful 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 intoHierarchical Design-Steps, it can only ever provide guidance. The special case where the AdditionalRequirements are a null-set may be logical and predictable for certain types of design (architecture) andthus it could become the entire Design-Phase. But recognising that it is a guide, will enable approximationsto be made in the name of speed. Focusing on rapid, approximate feedback to assess product architectureis felt to be much more valuable, as there will be many more architectures for which useful feedback isobtained, than there will be architectures for which an automated and complete design-process can beapplied !
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 30Print Date: May 31, 20138 Partitioning and MacroFunctionsIt becomes clear that in the process of hierarchical decomposition that the Design-Steps result in definition ofrequirements for Functional Objects. First at a high (abstract) level, but later at lower levels of detail … ultimatelydecomposing to ByteCode or Boolean. The problem is that at some stage the decision has to be made to commit aFunctional Object to a hardware or software implementation … and yet such a Partitioning decision is not an easyone to make, as it depends upon many system variables, as well as the Partitioning decisions that have alreadybeen taken.Some Partitioning examples ...• A software FFT Function is free if it fits into an available ROM and use available MIPs in a hostprocessor, 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, thesoft parameters (the last case) are difficult to quantify. It probably doesnt matter in an vehicle managementsystem, 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 lastpossible 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 ofbeing 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 willalways be software, it must have at least a small software interface component). In the vein of reaching the end ofthe Design-Phase, the MacroFunction may be considered to be a an identified formalised translation toimplementation … 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 everyend-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 accessedfrom the Application Program by the same function call, irrespective of its internal implementation, trade-offbetween 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 offormal isolation which improves the probability of producing right-first-time code in highly complex embeddedsystems, 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 arbitrarylevels, must be implementable, interchangeably, in hardware or software. Further, to maintain independence fromthe Application program that will use it, that the MacroFunction (and maybe parts of it) must operate or be capableof operation in an isolated, autonomous environment (eg: As a task under an RTOS).8.1 The Minimal Hardware MacroFunctionTo be implementation independent there some rules and concepts to which the MacroFunction mustconform. These are encapsulated in the functional components, SIFs and Stubs, Layer ‘N’ Functions andtheir Interfaces, which the following diagrams illustrate.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 31Print Date: May 31, 2013Fig 8.1.1: Minimal Hardware adapting to Functional LayersFigure 8.1.1 serves to introduce the conceptual MacroFunction implemented largely in software. Theconcept expects the Application Code to access the MacroFunction by the interface provided at the Layer5 Interface (The five layers shown is for illustration purposes only).This implementation has all of the functionality of the MacroFunction implemented in software. TheSoftware Interface Functions (SIFs) provide a none-functional translation from the software to thehardware domain. The process of analysis will reveal the natural functional layers, layers that are of similarclass, providing it starts at an adequately high functional level. At the same time, meaningful interfaces tothose functions will also be identified. In this specific case, all layers and interfaces are all implemented insoftware, using appropriate techniques. The lowest layer, is largely the same, but some of thefunctionality may be included in the SIFs (or their sequenced access), so the whole functionality of theLayer 1 is only partly achieved in software … so the layer is implemented as an adaption layer … or stub.Layer 5 FunctionsLayer 4 FunctionsLayer 3 FunctionsLayer 2 FunctionsSW - HWBoundaryLayer 1 StubsL1 InterfaceL2 InterfaceL3 InterfaceL4 InterfaceL5 InterfaceSIFsSIF InterfaceHost ApplicationMinimal HWUser
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 32Print Date: May 31, 20138.2 The Normal Hardware MacroFunctionThe extreme case of Figure 8.1.1 is unusual, and a more normal circumstance is where the hardwarecomponent is reasonably functional in itself, and this is illustrated in Figure 8.2.1.Fig 8.2.1 : Normal Hardware adapting to Functional LayersSome 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 Layer1 and some higher than Layer 2. However, it is unlikely that the hardware will be fully capable ofsupporting the functionality of the respective layers and their interface calls. So, as before, the SIFsprovide 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 softwareimplementations can carry-on to support the layers above.SIFsLayer 5 FunctionsLayer 4 FunctionsLayer 3 FnsL.2 FnsSW - HWBoundaryL1StubL2StubL3StubL1 InterfaceL2 InterfaceL3 InterfaceL4 InterfaceL5 InterfaceSIF InterfaceHost ApplicationNormal HWFunctionalityUser
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 33Print Date: May 31, 20138.3 The Highly-Capable Hardware MacroFunctionFigure 8.3.1 illustrates the extreme case, where the hardware has a high degree of intelligence (this mightbe the case if the hardware is actually a processor sub-system in its own right). In this case the lowerLevel’N’ Functions are not supported at all on the main host processor, but are interfaced to the hardwarethrough the Stubs and SIFs at higher levels only. The lower Levels Functions and Interfaces may beconsidered 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 aseparate (second) processor.Fig 8.3.1 : Very-Capable Hardware adapting to Functional LayersThis model shows an interesting characteristic. The Virtual layers, though they may exist inside thehardware implementation are inaccessible to the Host Application. Accordingly, even in the minimalhardware case, where all the layers are implemented in software, the lower levels must not be directlyaccessed by the host application … if the freedom to flexibly partition hardware and software is to bemaintained. For that reason, the complete functionality of the MacroFunction must be accessible at theinterface to its highest level of analysis (L5 Interface in this case) … Logically, there is no need to mandatea specific layer for an interface, except that it must be a layer sufficiently high, that its interface will alwaysbe in the software domain.As a footnote, it is quite in order that higher level MacroFunctions may be constructed out of lower-levelMacroFunctions. The only constraint is that the lower level MacroFunctions must exist entirely within thehigher level ones.8.4 Autonomy in MacroFunctionsOne 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 truefreedom of interchange-ability. The facility for autonomy is provided in the software domain through theuse of Tasks and an operating system. Logically, for an embedded system with real-time constraints, thisshould be a Real Time Operating System (RTOS). However, though the use of an RTOS emulates it, itshould be remembered that in its implementation, the actual Tasks are actioned serially on the single hostprocessor, so are not absolutely independent of one another as one Task may influence the run-time ofanother.Whilst it is clear that Tasks and an RTOS are necessary part of the practical deployment ofMacroFunctions. And that each MacroFunction should exist within a Task, it is not clear if a MacroFunctionmay/should contain multiple Tasks within it … after all a hardware implementation may consist of severalLayer 5 FunctionsLayer 4 FunctionsSW - HWBoundaryL4StubL3 StubL1 InterfaceL2 InterfaceL3 InterfaceL4 InterfaceL5 InterfaceSIFsSIF InterfaceHost ApplicationVery Capable .HW .FunctionalityUser
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 34Print Date: May 31, 2013autonomous hardware-processes ! The answer is, that providing the Tasks are entirely within theMacroFunction, 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 implementationsis 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 andmodel that alone. (Experience to date indicates that a single Task is all that is necessary … but this mustnot 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 bea 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 foradministering 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 bethe 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 anyObjects 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 MacroFunctionsThe use of MacroFunctions (and analysis that leads to them), tends to create a control centric architectureof product functionality. In this architecture there is always a Master in control ; like a conductor in chargeof an orchestra. The master administers tasks to the outstations, which may in turn administer moreremoved outstations. Although in control, the Master may only have a notional turn-on, turn-offmastership 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 acommunication mechanism must exist between the processors and this is best (generically) supported viaan RTOS … although for the turn-on, turn-off mastership, the minimal command interface could besupported 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 betweenhardware and software implementation (or software on a slave processor) is deferred until the resourceavailability is understood.As systems get more complicated it will become difficult to plan resources with fixed time-schedule plansat the start, and dynamic task scheduling will become a part of the design process, complemented bytasks that are aware of their time access and warn in the event of time-starvation is important … The futurerole 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 andverification are better supported in this way) there are still believers in peer-group architectures thoughthese tend to be more difficult to analyse and manage … and whose results are less predictable. As theModesRoute must coexist with both it should not prohibit either, though it may favour one.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 35Print Date: May 31, 20139 The need for DebugWe have established that providing the Requirement is formally defined, each Design-Step is formal, thatthe specification for the next Design-Step is formally linked to the preceding Design-Step, and that theimplementation is a formal translation from the last Design-Step … that debugging of an implementation isunnecessary, as it will, by definition work as specified.… However we are along way from that situation today, and errors will occur at every step. Errorsof incorrect specification, errors of translation, and errors of implementation. The practical result of this isthat debugging is a necessary part of the System-Product Development Cycle, and its support must beincluded 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 afundamental consideration … at all levels and throughout the design process. As with design forverification, it will have architectural consequences and it may be that the same solutions will offer supportfor debug. For example, we have already expressed the value of using an on-chip bus to facilitate modulardesign, and that the bus (by appropriate use of features) should support the verification of individualobjects connected to it. It is logical to extend the facility of the bus to include debug support features suchas Address/Data watch-points/break-points. A debug mode, allowing objects to be accessed in a debugmode … 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 expectthere are trade-offs in this) … hardware and software.With the need for multiple processor systems, and MacroFunctions, the need to extend this to debug totasks on an RTOS, and to support the communication of RTOSs on the different processors, such thatone can debug the other.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 36Print Date: May 31, 201310 Re-UseRemember, 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 Moores Law [6], a yardstick which subsequentlybecome popular in the Integrated Circuit industry. It stated that silicon logic capacity would double every ~18months for the foreseeable future … Over the years this has shown to be true. However, at the same time systemclock speed has been doubling every ~24 months, combining to produce a doubling of functionality every ~12months. 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-topbox can be implemented in about 2.4M transistors and the problem of understanding the architecture of the 120Mtransistor IC … or 1Billion transistors available in a small-handful of devices ! We undoubtedly will have productsof that complexity, but the problem is that although the technology is on the horizon, the products are not. This willforce us into a situation of very-short TTM as the silver bullet product emerges in the next few months … as itsurely will !We have already said that we cannot rely on the availability of engineers with experience of markets before we getinto them … we must substitute methodology and engineering, for experience. And we can already see that we willbe operating in a fiercely competitive situation as soon as the product is identified.Evidence available from several sources, indicate that todays 2-10M transistor component designs take ~ 50-200my 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 timesmore … an seriously alarming prospect ! Just think, a 6000 my project with 200 engineers working on it, will need30 years to complete … we only have ~2 years before the 0.18u capacity is generally available, so we should havestarted 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 cannotpossibly 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-200my projects referenced, did not either ! Having said that we (the industry) are very bad at reusinganything, even cell libraries. Tools and methods could be reused, but the temptation to do something a bitbetter means that new tools and methods are always being introduced, usually piecemeal. Probably thelargest 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-levelproduct the smart bit is not the development of the IC, there is a much larger task in the software thatmakes it into a product. A system-level product is a custom computer with custom software, a UART is asimple block of a computer or a custom computer. The huge state-space of a computer program makesthe development and debugging process more complex (and never absolute), adding customisedcomputer 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 historyshows that the size of computer programmes are doubling every 12 months, faster than silicon logicdensity."Most of our designs are completed in days, what is the big deal about sub 0.25u ! " … for an ASICsupplier then this is true and can be expected to remain the case in the future. However, look at what ishappening here. All of the front and back-end work is removed from your grasp, leaving the purelymechanistic (Synthesis), gate-layout, fabrication & logical-test … this is a process for creation of physicalsilicon from a standardised description … it is standardisable and available will be (is) available from manysources. The choice of vendor will be (is) purely on the basis of Performance, Cost, Cycle-Time andQuality. If Performance is predominantly a function of the Si geometry, and Quality is assumed … then weare left with Cost and Cycle-Time … classic factory parameters. With direct competition, Cost will comeunder direct pressure and margins will be reduced to minimum … and lower … to maintain full fabs. This
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 37Print Date: May 31, 2013is 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 fromhis own engineers. Indeed, it offers the factory more time to achieve its overall function, and a better opportunityto 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 notmore, 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. Inparticular, the ones we are not (individually) using yet, though are being improved through their use in other partsof the industry … and which are becoming relevant to system-level design. In addition, the improvedcommunication and networking of engineers (internal and external) is leading to an improved informal reuse ofinformation … though the combined effect of these is probably only one order of magnitude, it does emphasise theimportance of immediate investment in new tools … not only in the areas that we already know, but also in theassociated areas, areas that are becoming part of our increasing system-level responsibility domain. (Eg: Sivendors, must invest in state-of-the-art Si methods and tools … assumed ; but also in state-of-the-art softwaredevelopment methods and tools … unprecedented ).So assuming that we do deploy the latest tools across the spectrum of system we achieve a factor of 10improvement, so we still need to find at least one further order of magnitude improvement to take us to the order of10s of man.years of effort.Probably the only vehicle that offers this potential is further deployment of reuse …10.1 Aspects of ReuseDr Hatton [12] identifies ten system-level reuse components as …1. Architecture2. Requirements3. Cost & Resource Estimates4. Plans5. Designs & Specifications6. Data7. Human Interfaces8. Source Code (SW or HW HDL)9. User Documentation10. Test MaterialI would add several more items to this list …11. Methods12. Tools13. Object Code (Including ByteCode and Layout Data)14. Simulation models15. 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 asbinary or logic-gate level libraries, with simulation models and data sheets ! This list outlines the hugepotential for reuse, across the sphere of System-Level developments. It sets the scene for the reusedomain 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
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 38Print Date: May 31, 2013style and to be reuseable, at all levels of its being. Further, we must manage this data in such a way thatwhen 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 effectivereuse library will just happen, as a part of the product design process.10.2 Intellectual PropertyIf we consider that we need to reuse various Product Aspects and Components, then these must beencapsulated in some way to support their reuse. Because they offer the capability to save time and alsoencapsulate pieces of knowledge or experience, then they can be valued in financial terms. The industryhas given this a title of Intellectual Property … though it is usually applied to circuit functions or softwaremodules, 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 doas the following examples show :-Effort-Based Value : The value of the IP is measured in terms of the man.months of effort that went intoits development. This in no way reflects the efficiency of the actual design route, or the intrinsic value ofthe solution.Intrinsic Value : 50-100%(?) of the costs involved in an un-skilled design group creating the samesolution. This in no-way reflects the skill-level of the actual design group. It does not include the value ofhaving a solution today as opposed to having to go through the design process. Also, it does not reflectthe 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 likelyto be the value experienced by IP vendors. In this scenario, the vendor seldom recovers his actualdevelopment cost, which forces vendors out of business or to deliver poor quality IP… neither of which arein 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 touse and your own engineers have to understand it, and possibly re-engineer it to include your methods orquality 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 theperceived effort in designing your own is less than the effort of incorporating someone elses … A mistakewhich is easy to make when you dont understand the complexity of the object being discussed.Fundamental to breaking this deadlock, is agreement of quality standards. This will allow the transfer of IPof known levels of completion … and just as importantly, un-completion. As a result it will enable thelicensee to have a much better understanding of what he is buying and how much effort will be required touse it ! It also gives the IP vendor quality standards to aspire towards (a goal to enable him to optimise hisdesign 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 theexchange 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 intrinsicvalue is important, so we would expect reuse to be extensive … but it is not. Principally because the extraeffort involved in encapsulation of IP is not allowed for in the host project time frame … and this isaccepted corporately because the lost value of this IP is not truly recognised in the improvement of cycletimes and development costs for other projects. Accordingly, the value of potential IP should be neutrallyassessed and if it is judged valuable against internal criteria, then it must be required that it isencapsulated even if there is no intent to offer the IP externally…. Its corporate value is recognised andthat 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 ofcomponents of it is significant (estimated at x3). However there is grounds for belief that if it is such a smallproject that it is not worth encapsulation of the components as they are (by definition) simple. However, for
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 39Print Date: May 31, 2013more complex system-level products, where the complexity of the development expands beyond aConcept-Span, then encapsulation of the components is already a requirement so that it can be deployedin other parts of the project … and the additional work to formalise this encapsulation will be minimal, ifrelease management is managed through the use of a Configuration Control tool, as an integral part of thedevelopment 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. Forinternal exchange it is adequate that this is to internal standards, but for external exchange then globalstandards are mandated … This can cause a significant difficulty as no global standards exist for views orquality ! This is at least a part of the objective of the ModesRoute, because through its identification andestablishment as an accepted route for system-level product development, the components ofstandardisation will become apparent. And similarly, through recognition of the needs of ConcurrentDevelopment, the standardisation of Quality Gateways.… It is recognised that this description of reuse facets and quality is not specific enough to beimmediately applicable, but it identifies the need for broadening the scope significantly beyond those of theSi-centric VSIA initiative, and is an opportunity for Europe to develop a lead position.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 40Print Date: May 31, 201311 Configuration ControlIt is clear from the preceding chapters, that with Products having many Aspects and Aspects having manyComponents. And the successful product development operating under time pressure and geographic distributionof design resources. And needing to work in a Concurrent Design environment … than effective and efficientmanagement 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 prescribedstatuses and versions of files, their histories, links, releases and interdependencies.Incorporate Product, Aspect & Component Assembly Rules : Such that it will not be possible to releasean object to a higher level, than the lowest level of its component parts … or at least those parts of thecomponent that apply to that release.Manage the release of data to the Quality Gateway standards : Allowing designers to be unencumberedby the control procedure.Allow management of data across geographic locations : Allowing data to be checked-out for edit at onelocation, and not confused with edit attempts at another. Allowing development builds of products usingcomponents of at-least X state criteria.Not replicate full data-bases at each geographic location : Allowing the minimisation of stored data, by itsminimum replication.Maintain access control of certain data : To restrict data access to certain parts of the information insupport 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.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 41Print Date: May 31, 201312 The ModesRoute DiagramAlthough the preceding sections describe applicable methods and requirements for a MicroElectronic-Systemmethodology, some sort of diagram is beneficial to condense the salient features and illustrate the flow. TheModesRoute Diagram (Figure 12.1) can be considered as an implementation of a single Design-Step, with severalQuality-Gateway compatible output stages accessible. The hierarchy of the Design-Step is incorporated throughthe Component Preparation stage, in conjunction with the use of Component & Sub-System Source (Library). It isin 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 beimplemented. It is the ModesRoute Diagram in context, which can best be used for mapping of productivity toolfunctionality 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 developSystems, it can be generalised as :-Formalise Requirements -> Develop -> Implement -> Verify -> Replicate.However, because its scope includes the full verification activity, it identifies theneed for and sources of, verification documentation (files).• It is implementation independent, not using words which associate it with a pre-conceivedimplementation technology or hierarchical level ; it is equally applicable to all spheres of Systemdesign (Battleship, to IC).• It is complete, covering the full span from concept to production. As development is the creation ofmanufacturable (and valuable) product, anything less would not cover the scope of the developmentprocess.• It describes heretical, component based design, allowing the entire route to be attached to loweror 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 asa part of the development cycle-time• It supports the multi-component product, allowing components to be considered asdevelopments in their own rights.• It is compatable with the MacroFunction concept, allowing system partitioning to be delayed andseperated from analysis.• It inherently understands the interface to reuse and IP exchange, minimising TTM and designeffort, whilst maximising quality.… as it describes the process by which System-Level products do come into being, it is describes the process thatdesign engineers are already doing (knowingly or not). However, having illustrated it, it is now possible tooptimise it and its support.(See Appendix B for expansion of the roles of each of the stages in the ModesRoute Diagram)
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 42Print Date: May 31, 2013Compt Requirements(Test1Benches)ComponentImpln & PrepnProduct IdeaFunctional DesignArchitect &Partition SystemSystem Integration& PrototypeIntegration Spec.(Functional Test2)AssessReproduceabilityProduct Spec.(Reproduction Test4)The ModesRouteAcceptance Trials(Alpha & Beta)Functional Spec.(Verification Test3)R - Recursion May Occur HereReproduceFormaliseRequirementsCOMPONENTREQUIRMENTSARCHITECTURALREQUIRMENTSComponent PreparationSystem IntegrationSystem ImplementationSYSTEMFUNCTIONAL SPEC.PRODUCTREQUIREMENTSSPEC.EXTERNALREQSOBJECTREQSCOMPONENTSTO LIBRARY(SUB) SYSTEMTO LIBRARYCommercial RestrictionsRe-Use RestrictionsReproduction RestrictionsALL COMPSPREPAREDRECURSION INPUT FOR LOWER-LEVELCOMPONENTS OR SUB-SYSTEMSSUMMARYINFORMATIONSOURCEDOBJECTx3.3- Itterate to agreementINTEGRATIONPLANExternalPreparationEXTERNALOBJECTCompt&Sub-Syst.Source(Lib)RRRFig12.1: The ModesRoute DiagramV1.0
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 43Print Date: May 31, 201313 Tool Mapping to ModesRouteWhilst we do not do any specific tool mapping at this stage, it is easy to see the roles that identifiable tools playin 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 ifthe tools that have been developed and deployed within the OMI/MODES project are mapped to establish theirrelevance 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 withoutreference to specific tools and their use, it is possible to identify some quick hits, weaknesses that are apparentwith 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 effortand IP.* That interconnection standards must include enhancements for Debug, Manufacturing Test andVerification … which they do not adequately do today.* Data management and control systems should be across the whole product and should supportcomponentised and hierarchical developments, and concurrent and distributed design practice.* The concept of Quality Gateways, allowing pre-release information to flow throughout a projectis not supported by normal tools. This will ideally be established universally as soon aspossible.* Emulation model building tools. To build emulation and simulation models of arbitrary functionalobjects and with exchangeable (library) components. To build models of interfaces. To buildmodels of Use-Cases and responses.* The ability of geographical and disciplinary distributed contributors to be part of a managedenvironment is not supported by existing tools.* The recognition of libraries as the lowest level of analysis required, representing the use of aknown commodity, with known quality and characteristics, is not easily supported by existingtools.* The need to generate Requirement Specifications in an animate-able way, and to use them asthe 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 thedevelopment cycle. And that it should be compatible with the format of the requirementspecification (or use cases) … the test banches.* Abstract Requirement Specification capturing and animation tools are required for thegeneration and disintegration of Requirement Specifications and provision of test cases … butthey 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 alllevels.* Interface standardisation development tools such as those that provide regularised interfacesbetween software and hardware should be encouraged.* The use of RTOSs is an important part of multi-processor products, their use should no longerbe considered optional ! Without them complex system-level products will be impossible.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 44Print Date: May 31, 2013* All development tools should support true hierarchy and multiple external libraries … allowingtheir ready transplant into another part of the System-Level development activity. This isseldom 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.* …
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 45Print Date: May 31, 2013Appendix A : Quality GatewaysQuality Gateway Universal CriteriaSpecification Entry Req: An ideaDo 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 ofsuccess. Functional Acceptability Criteria. Development Costs and Schedule.Manufacturing Cost. Methods and Tools to be used. Risk Assessment. (PreliminaryRequirement Spec.)Do In State: Internal : Convert the planned development, by stages until it achieves full releasecriteria. Ultimately resulting in a matching implementation and product specification.External: Users may make use of Development data must be aware that it willprobably be only partially functional against the currently applicable RequirementSpec.Comment: The Development state is where all of the actual development and testing takesplace. A development moving between (Eg) Alpha and Beta, does so viaDevelopment. The Requirement Spec. itself may be modified during this stage, toachieve ‘end’ agreement with the implement-ation. Significant changes may involvereturn to the Specification stage.Alpha Entry Req: A development which has demon-strated Basic FunctionalityDo In State: Use the data recognising its fragility. Bugs probably will be found.# against the (at thattime) applicable Requirement Spec.Comment: There will probably be several Alpha releases as errors of functionality arediscovered &/or changes in Requirement Spec are required. A development in thisstage will demonstrate significant functional fragility and it will seldom be reliableenough to be used without close supervision or support.Beta Entry Req: A development which has demon-strated Complete Functionality * against the (bynow) solid Requirement Spec. Additionally, it will have demonstrated BasicFunctionalityDo 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 areidentified. A development in this stage will demonstrate significant robustness. At aCorporate level (and as a Developer) we are happy to agree a Limited SupplyContract with our customers, where we reserve full commitment to conform tocertain aspects.Release Entry Req: A development which has demonstrated Complete FunctionalityDo In State: Deployment of the ‘package’ of information, restrained only by Commercialconsiderations.* against theRequirement Specification and in its Normal-Operating-Environment(s). ViableReproducibility. Complete and consistent Implementation Spec.Comment: The intention is that there is just one Release. Significant errors after this stage willnormally 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 withour customers.# Basic Functionality : Demonstrating apparently correct functional responses to the application ofNormal-Operating-Mode stimuli (or Normal-Operating-Environment stimuli).* Complete Functionality : Completely meets the functional and non-functional requirements identified in theRequirements 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 andElements. They apply to External Data, data which goes outside of the immediate closed environment ofits local developers, for purposes of exploitation or further use. They are described in a generic way theydo not prescribe interpretation for a given technology, nor detail of the method (or tools) to be used tomake the transition between them. Accordingly, they act as the unifying influence to regulate thedevelopment of an arbitrary object in an arbitrary technology. Corporate Policy can now prescribe the
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 46Print Date: May 31, 2013quality requirements for an arbitrary Product, Aspect, Component, Element or Capability … without havingneed to understand the actual technology being deployed :-1st : Interpret the Quality Gateways in terms appropriate to the technology involved (Where anexisting interpretation is not available).2nd : Select the appropriate Method to use to accomplish the state transitions. Where a Capabilityexists and is appropriate to use, it should be selected.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 47Print Date: May 31, 2013Blank Quality Gateway FormQuality 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:
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 48Print Date: May 31, 2013Appendix B : ModesRoute StagesProduct IdeaRECURSION INPUT FOR LOWER-LEVELCOMPONENTS OR SUB-SYSTEMSa) Product IdeaFunction :Inputs :Product Idea :• Ideas, Market feedback, Customer needsOutputs : • Enough of an understanding to participate in an interactive understanding of consolidating thefunctional 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 humanprocess.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 49Print Date: May 31, 2013FormaliseRequirementsPRODUCTREQUIREMENTSSPEC.Commercial RestrictionsRe-Use RestrictionsReproduction Restrictionsb) Formalise RequirementsFunction :Inputs :Formalise Requirements :• An idea of a product, with enough of an appreciation of its environment and application toappreciate how it might be used. Also enough of an understanding of the Market and theproducts Value.Outputs : • A Product Requirement Specification, including corporate parameters, timescale, functionaland none-functional parameters. This should not prescribe implementation details, unless it isa specific part of the requirement.Commentary : Although considered complete, it is possible (probable) that changes will be required in theRequirement Specification as the subsequent stages are actioned. (The main data-flow arrow isdownward, 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.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 50Print Date: May 31, 2013Functional DesignSystem ImplementationSYSTEMFUNCTIONALSPEC.PRODUCTREQUIREMENTSSPEC.c) Functional DesignFunction : Functional Design :Development of the Functional Block Diagram, identifying the major function blocks and the principleinterconnections between them.It also quantifies the principle controls and behaviour that will be used as the basis of confirmationof functional behaviour later in the design process.Inputs : • Product requirement SpecificationOutputs : • System Functional SpecificationCommentary : This is used as the basis of the next phase of implementation, and also as the basis of the FunctionalTesting which will occur. Model may be passed to a customer with a Pre-Alpha grading … as long asthe customer is aware of its restricted functionality.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 51Print Date: May 31, 2013Architect &Partition SystemCOMPONENTREQUIRMENTSSystem IntegrationINTEGRATIONPLANd) Architect & Partition SystemFunction :To identify the Functional Components and their Interactions. And to establish how they will beimplemented (HW/HW, HW/SW, SW/SW).Architect & Partition System :Also to establish how the Functional Objects will be Integrated after they are become availableInputs : • System Functional Spec.• Commercial Restrictions• Re-Use Restrictions• Reproduction Restrictions• Summary InformationOutputs : • Component Requirements• Integration Plan• Architectural RequirementsCommentary : 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-Alphagrading … as long as the customer is aware of its restricted functionality.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 52Print Date: May 31, 2013Compt RequirementCompt RequirementCompt RequirementCompt RequirementCompt RequirementCompt Requirement(Test 1Bench )Compt Requirement(Test 1 Bench )etc.etcHW/HW:AnalogueHW/HW:HDLHW/HW:DigitalHW/SW:Low-LevelSW/SW:HDLComponent /Sub-Syst. PrepnComponent PreparationObjectRequirementComponentRequirementsNew ComponentsTo LibrarySourcedObjectComponents&/orSub-SystemsAll CompsPreparede) Component PreparationFunction :This is the many task activity of implementing the Components (& Sub-Systems) identified in theearlier 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 theComponent being implemented. As such it must exist in a simulate-able form.• That Requirement Specification and the component implementation must agree by the timethe 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 orHW/SW and independently optimised design tools can be selected to provide for thedevelopment 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 itsfunctionality.• Even when an object is available directly from the Re-Use library, it will need some workbefore it is usedInputs : • 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.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 53Print Date: May 31, 2013System Integration& PrototypeIntegration Spec.(Functional Test2)ARCHITECTURALREQUIRMENTSALL COMPSPREPAREDf) Integration Spec. | System Integration & PrototypeFunction :The Test-Bench which will be used to verify the correct operation of the System Integration andPrototype device, in both the simulation environment and also the prototype product (physical).Integration Specification :Inputs : • An Integration Plan from the Architect & Partition System stageOutputs : • Test-Bench• Support documentationCommentary : 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 ofintegration 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 availableInputs : • All the prepared Components• Architectural GuidanceOutputs : • Prototype product suitable for Beta Trials to commence (Suitable for first customerassessment).• Information to finalise the Product Specification (and final test bench)Commentary : Interacts with the Integration Specification until a satisfactory agreement is achieved. Product may bepassed to a customer with a Pre-Alpha grading … as long as the customer is aware of its restrictedfunctionality.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 54Print Date: May 31, 2013Acceptance Trials(Alpha & Beta)Functional Spec.(Verification Test3)g) Functional Spec. | Acceptance TrialsFunction :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 stageOutputs : • Test-Bench• Support documentationCommentary : 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 behavesas required by the application.Acceptance Trials :• Compliance to all interface requirements must be established.Inputs : • Completed System Integration prototypeOutputs : • 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 passedto a customer with an Alpha or Beta grading … as long as the customer is aware of its restrictedquality.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 55Print Date: May 31, 2013AssessReproduceabilityProduct Spec.(Reproduction Test4)(SUB) SYSTEMTO LIBRARYh) Product Spec. | Assess ReproduceabilityFunction :Establish Test-Bench which will be used to verify adequate conformance of the manufacturedproduct to the behaviour of the verified prototype.Product Specification :Inputs : • An Manufacturing Test Plan from the System Integration & Prototype, & Acceptance Trialstages.Outputs : • Test-Bench• Support documentationCommentary : 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 thedevice is compatable with the reproduction and distribution methodology chosen, with an acceptabledegree of difficulty to the customer.Assess Reproduceability :Inputs : • Prototype with completed Acceptance Trials• Reproduction documentationOutputs : • Formula for reproduction• Pre-Production Product suitable for general supplyCommentary : 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.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 56Print Date: May 31, 2013Reproducei) ReproduceFunction :Inputs :Reproduce :• Reproduction Formula and documentationOutputs : • 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 nextlevel of hierarchy) in an appropriate volume and with an appropriate Full-Release quality.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 57Print Date: May 31, 2013EXTERNALREQSOBJECTREQSCOMPONENTSTO LIBRARYSUMMARYINFORMATIOSOURCEDOBJECTEXTERNALOBJECTCompt&Sub-Syst.Source(Lib)j) Compt & Sub-Syst. Source (Lib)Function :This is a repository for Objects of known quality, with their associated views. It may be a combinationof 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 useOutputs : • Objects which have some reuse value• All of their associated viewsCommentary : The library may commission Objects in response to requested (or anticipated) demand, these in turnwill make use of the ModesRoute (which is in effect a Design-Step) for implementing the next levelbelow.
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 58Print Date: May 31, 2013EXTERNALREQSExternalPreparationEXTERNALOBJECTRk) External PreparationFunction :The use of external facilities to implement required Library ObjectsExternal Preparation :Inputs : • Real or perceived needOutputs : • Library Object of known quality, with all its viewsCommentary :
  • Esprit Project No 20.592 OMI/MODESMitel SemiconductorDeliverable id: TR:1.2.4Issue Date: 27 May 98RDS/ESG/008-20.x1 Page No 59Print Date: May 31, 2013