Paul Boughton
Rapid prototyping is increasingly being used as a means to quickly build new products, investigate new solutions, and identify any potential problems at an early stage. However, the very nature of rapid prototyping can make managing such projects difficult. An increasing number of designers are using software configuration management (SCM) to deal with the vast volumes of code and other data involved, as Tony Smith explains.
In the drive to develop innovative products quickly, electronics companies are turning to the technique of rapid prototyping. Employing this approach, project teams quickly build working but incomplete software that runs on development hardware. A quickly assembled prototype allows developers to spot design flaws and fundamental bugs at a very early stage. In addition, rapid prototyping creates variants, so different solutions to a problem can be tried out and incorporated if successful or, if not, discarded.
Many types of applications can benefit from rapid prototyping. The European ESPADON project, which involved engineers from BAE Systems, Thales and MBDA, benchmarked the technique against traditional software development in radar and sonar applications[1]. They found rapid prototyping to be at least two times faster than traditional development and, in one case, resulted in a 16-fold improvement in cycle time. The researchers on the project concluded that the use of a common rapid-prototyping process and the development of libraries to maximise reuse were large factors in making these improvements possible.
However, rapid prototyping brings with it challenges. During the initial stages of development, the rate at which embedded software evolves can lead to problems as the number of variant builds and versions explodes. The many changes to software modules that occur towards the beginning of a sub-project can destabilise the core code base unless each of the variants is packaged and maintained separately. Conversely, bug fixes to code common to more than one variant need to be propagated to the equivalent code modules in other variants, to ensure that the underlying bugs do not leak into production software.
For an organisation to benefit fully from the potential productivity improvements of rapid prototyping, careful management is required. The traditional "tar, copy, move" approach to creating branches off a common code base - in which file-system utilities are used to identify and copy relevant source-code modules - can make it difficult to work out which changes need to be merged back into the core code base.
Each individual prototype can contain hundreds, if not thousands of files. In the context of an electronics project, a prototype development can contain many different elements, including:
* Behavioural models to simulate IP.
* Verilog and VHDL hardware description files.
* C source code files for the middleware and applications.
* Configuration files and scripts used by the many EDA design files in the project.
In addition, there will be compiled binary code to allow incremental compilation as well as test and verification files for both the hardware and software.
It is all too easy to forget about vital, but small changes, made to a line in a module used across many of the variants. This is particularly true when the focus is on larger additions to the code-base produced by the engineers working on a particular branch.
The amount of storage space needed to maintain different prototypes can quickly spiral out of control when large files are involved. Although the cost of disk space continues to fall, the issue becomes one of management. Regular backups become increasingly costly and time-consuming to perform. Projects that maximise reuse through the use of third-party and internal code frameworks and libraries pay an additional penalty in terms of the time it takes to copy all the source code to a new folder tree: time that could be spent on development.
To solve these problems, developers are turning to software configuration management (SCM). The purpose of an SCM system is to record all versions of all files that have ever existed within a project. The SCM system tracks changes to each and every file and controls file accesses so engineers know which files are checked out for editing by other users.
SCM systems can greatly streamline rapid prototyping using techniques such as 'lazy copying'. Lazy copying recognises that when a variant is first created it will be identical to the original. In that situation, all that is needed is a pointer to the original, rather than a physical copy. As the variant is modified new storage is reserved, but all that is recorded are the differences between the modified version and the original.
Where the code frameworks are large, it is not unusual for even extensive modifications to result in a divergence of just a few per cent between variants. Because lazy copying needs only to allocate space for a tiny proportion of the overall code base, the storage savings can be immense.
The developments within a particular variant have to be isolated from all other development streams until all or parts of them are ready to be introduced back into the main design. This can be a problem for some SCM systems, but is a vital requirement to allow engineers to innovate and prototype the way in which they want. By monitoring and displaying the differences between files, the SCM can greatly ease the job of merging important changes back into the core source code.
Differences can be moved backwards and forwards between variant streams with relative ease. This simplifies feature enhancements, bug tracking and resolution. New features added, or bugs resolved during development, can be applied easily and propagated around the various development areas. A complete audit trail is preserved within the SCM system.
Developers can use the change-tracking features of an SCM to ease collaboration between different groups, an important consideration in large projects where the engineers might not just be on different teams but working on different continents. Typically, the bulk of the rapid prototyping effort will focus on software, particularly if the organisation produces variants of systems aimed at subtly different markets, or customises those systems for partners. Because of considerations such as verification time and IC-mask costs, much of the hardware is typically common to a number of projects, with the software providing the 'personality' for each variant.
As a result, a change to the hardware design can impact many variants or prototypes at once. For example, a register definition might need to be altered to improve performance or deal with a bug, or there might be changes in the way in which units synchronise. These changes can affect how the software interacts with the hardware. Using traditional code management techniques, the engineers in the hardware and software groups have difficulty in communicating changes to each other.
With SCM maintaining all of the project's design data, a software engineer can be kept informed of changes made in areas that matter to them. If a file that contains the register definitions changes, a developer can check whether the modification matters to them quickly and not have to wait until integration testing for a problem to become apparent.
With SCM, design teams get the resources they need quickly and are given more room to innovate and push the boundaries of what is possible in embedded designs. Innovations in one variant can be folded back into the mainstream product lines, and bug fixes quickly propagated to everywhere they should be, ensuring design teams reap the full benefits of rapid prototyping.
[1] How rapid is rapid prototyping? Analysis of ESPADON programme results, Madahar et al, EURASIP Journal on Applied Signal Processing (2003).
Tony Smith is European Technical Director for Perforce Software, Where. www.perforce.com He is responsible for the provision of Training and Consulting services to Perforce users across Europe. He is an experienced developer and in addition to his management responsibilities, he also undertakes some development of the Perforce SCM system.
In the drive to develop innovative products quickly, electronics companies are turning to the technique of rapid prototyping. Employing this approach, project teams quickly build working but incomplete software that runs on development hardware. A quickly assembled prototype allows developers to spot design flaws and fundamental bugs at a very early stage. In addition, rapid prototyping creates variants, so different solutions to a problem can be tried out and incorporated if successful or, if not, discarded.
Many types of applications can benefit from rapid prototyping. The European ESPADON project, which involved engineers from BAE Systems, Thales and MBDA, benchmarked the technique against traditional software development in radar and sonar applications[1]. They found rapid prototyping to be at least two times faster than traditional development and, in one case, resulted in a 16-fold improvement in cycle time. The researchers on the project concluded that the use of a common rapid-prototyping process and the development of libraries to maximise reuse were large factors in making these improvements possible.
However, rapid prototyping brings with it challenges. During the initial stages of development, the rate at which embedded software evolves can lead to problems as the number of variant builds and versions explodes. The many changes to software modules that occur towards the beginning of a sub-project can destabilise the core code base unless each of the variants is packaged and maintained separately. Conversely, bug fixes to code common to more than one variant need to be propagated to the equivalent code modules in other variants, to ensure that the underlying bugs do not leak into production software.
For an organisation to benefit fully from the potential productivity improvements of rapid prototyping, careful management is required. The traditional "tar, copy, move" approach to creating branches off a common code base - in which file-system utilities are used to identify and copy relevant source-code modules - can make it difficult to work out which changes need to be merged back into the core code base.
Each individual prototype can contain hundreds, if not thousands of files. In the context of an electronics project, a prototype development can contain many different elements, including:
* Behavioural models to simulate IP.
* Verilog and VHDL hardware description files.
* C source code files for the middleware and applications.
* Configuration files and scripts used by the many EDA design files in the project.
In addition, there will be compiled binary code to allow incremental compilation as well as test and verification files for both the hardware and software.
It is all too easy to forget about vital, but small changes, made to a line in a module used across many of the variants. This is particularly true when the focus is on larger additions to the code-base produced by the engineers working on a particular branch.
The amount of storage space needed to maintain different prototypes can quickly spiral out of control when large files are involved. Although the cost of disk space continues to fall, the issue becomes one of management. Regular backups become increasingly costly and time-consuming to perform. Projects that maximise reuse through the use of third-party and internal code frameworks and libraries pay an additional penalty in terms of the time it takes to copy all the source code to a new folder tree: time that could be spent on development.
To solve these problems, developers are turning to software configuration management (SCM). The purpose of an SCM system is to record all versions of all files that have ever existed within a project. The SCM system tracks changes to each and every file and controls file accesses so engineers know which files are checked out for editing by other users.
SCM systems can greatly streamline rapid prototyping using techniques such as 'lazy copying'. Lazy copying recognises that when a variant is first created it will be identical to the original. In that situation, all that is needed is a pointer to the original, rather than a physical copy. As the variant is modified new storage is reserved, but all that is recorded are the differences between the modified version and the original.
Where the code frameworks are large, it is not unusual for even extensive modifications to result in a divergence of just a few per cent between variants. Because lazy copying needs only to allocate space for a tiny proportion of the overall code base, the storage savings can be immense.
The developments within a particular variant have to be isolated from all other development streams until all or parts of them are ready to be introduced back into the main design. This can be a problem for some SCM systems, but is a vital requirement to allow engineers to innovate and prototype the way in which they want. By monitoring and displaying the differences between files, the SCM can greatly ease the job of merging important changes back into the core source code.
Differences can be moved backwards and forwards between variant streams with relative ease. This simplifies feature enhancements, bug tracking and resolution. New features added, or bugs resolved during development, can be applied easily and propagated around the various development areas. A complete audit trail is preserved within the SCM system.
Developers can use the change-tracking features of an SCM to ease collaboration between different groups, an important consideration in large projects where the engineers might not just be on different teams but working on different continents. Typically, the bulk of the rapid prototyping effort will focus on software, particularly if the organisation produces variants of systems aimed at subtly different markets, or customises those systems for partners. Because of considerations such as verification time and IC-mask costs, much of the hardware is typically common to a number of projects, with the software providing the 'personality' for each variant.
As a result, a change to the hardware design can impact many variants or prototypes at once. For example, a register definition might need to be altered to improve performance or deal with a bug, or there might be changes in the way in which units synchronise. These changes can affect how the software interacts with the hardware. Using traditional code management techniques, the engineers in the hardware and software groups have difficulty in communicating changes to each other.
With SCM maintaining all of the project's design data, a software engineer can be kept informed of changes made in areas that matter to them. If a file that contains the register definitions changes, a developer can check whether the modification matters to them quickly and not have to wait until integration testing for a problem to become apparent.
With SCM, design teams get the resources they need quickly and are given more room to innovate and push the boundaries of what is possible in embedded designs. Innovations in one variant can be folded back into the mainstream product lines, and bug fixes quickly propagated to everywhere they should be, ensuring design teams reap the full benefits of rapid prototyping.
[1] How rapid is rapid prototyping? Analysis of ESPADON programme results, Madahar et al, EURASIP Journal on Applied Signal Processing (2003).
Tony Smith is European Technical Director for Perforce Software, Where. www.perforce.com He is responsible for the provision of Training and Consulting services to Perforce users across Europe. He is an experienced developer and in addition to his management responsibilities, he also undertakes some development of the Perforce SCM system.
