This page contains a Flash digital edition of a book.
EDA & Development


Solving the design reuse dilemma


In electronics design the drive to reuse assets is a compelling one but, as Rob Evans explains, confidence in the integrity of the recycled element is the key to success


A


t its most fundamental level, design engineers practice design reuse in every hardware project


through the use of integrated circuits – off-the-shelf ICs that have been rigorously tested and used in countless other designs. ICs generally contain a complex collection of circuitry, but we have a high degree of faith in the integrity of what’s inside. In fact, we care much more about the functional behaviour of the chip than the circuitry it represents, and confidently treat it as a black box device. Moving up the design reuse scale, our confidence tends to wane as the variables increase in number – as the abstraction of the reusable items goes up. Chips and other components, arranged in libraries, include a range of parameters and models that are collected, created and manipulated over time. Library components are reused in designs with a degree of confidence that depends on


44 July/August 2011


their perceived integrity – whether the various models are correct and up to date, the part is still available, the supply is assured and so on.


Managing the integrity of that collection of component data, ensuring its ‘reuse-ability’ in effect, can take on the form of locally approved component libraries right through to company database libraries that hook into the organisation’s lifecycle management system. The practical effectiveness of these systems varies widely – higher level, more complex data management tends to restrict component choice and is disconnected from the design process, while an informal, local approach carries a higher degree of risk but is an interactive part of the environment where component decisions are actually made. Nevertheless, organisations arrive at some kind of workable balance – or perhaps more accurately, compromise –


Components in Electronics


between rigid data management and relevance to the design process. The real issue, as in all instances of design reuse, is how the integrity of the reusable elements is maintained, rather than the availability of features and functions that deliver those elements.


Chasing the goal It’s at the highest level of design reuse where things really become challenging. The Holy Grail of recycling design resources is the ability to apply whole sections of pre-existing design content in new design projects. This is design reuse at a much higher level of abstraction, where the number of elements and variables included in each design package can be huge. Here, each reusable section will represent the circuitry and sub-elements – components (models and parameters), nested circuitry and so on – that are needed to deliver the function of that package.


Reusing these high level design sections should, in theory, be just like using integrated circuits or components from a library, which can be treated as a black box of functionality because we have full confidence in the integrity of what’s inside. But it’s somewhat different in reality.


To date, this level of design reuse has been tackled using an ad hoc approach based on copy-and-paste techniques, or at best, a system to formally store reusable chunks of circuitry. This notional “design reuse capability” provides the basic mechanisms to implement reusable elements, but does very little (or nothing at all) to mitigate the risk of using them. You just can’t be sure that the source circuitry is the latest version, its functionality is still viable, it does not contain errors or undocumented modifications, or for that matter, if the components are still suitable and available. The risks of reusing design sections in this way are cumulative and untenable, so providing the design system features and functions needed to reuse design content is of little value when the integrity of that content is in doubt.


Tackling data integrity What’s needed is a practical and effective way to securely store, share and manage locked revisions of reusable design content, then manage the lifecycle of that content to define its suitability for new designs. Taking this approach, design content


can be released from the design space itself into a secure storage ‘vault’ as a unique, traceable revision, which can contain any number of child elements (components, sub circuits, etc). The child content will also exist in the vault as its own set of managed revisions, so the integrity of the ‘parent’ content is maintained down to the lowest level. A design section is released into the vault as a schematic sheet (or tree of sheets) and stored as a fixed revision, where its lifecycle status (prototype or production, for example) can be defined over time. If the design source documents are updated, a new revision can be


www.cieonline.co.uk


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44  |  Page 45  |  Page 46  |  Page 47  |  Page 48  |  Page 49  |  Page 50  |  Page 51  |  Page 52