Page 19

EETE JULAUG 2013

EDA & DESIGN TOOLS Version control in EDA for optimum hardware design By Robert Huxel As a typical practice , most large EDA vendors conduct a costly on-site case study of a prospective client’s existing system at a cost that can run into the millions of dollars. In the next step of the scenario, they deploy a Field Application Engineer (FAE) on site to manually produce code. The objective: an integrated design solution. Instead, the result produces a lengthy and costly process that often fails to integrate even a majority of the prospect’s desired functionality, especially for version control. Unfortunately, electronic engineering educators typically do not teach version control. Version control actually evolved as a software best practice methodology. It became an absolute necessity for software developers because programs grew to such large sizes that they required Fig. 1: Aberdeen Group’s research report, “Need to Save PCB Design Time?” established three categories of survey participants; best-in-class, average, and laggards. ever larger design teams. Trying to manage the volumes of code without an effective version control system provides an excellent definition of hell. Version control allows multiple team members to be simultaneously working on a software program without risk of losing or overwriting another member’s code. Unless a company’s sole business is to design boards, most people in the electronic products industry understand that software teams considerably outnumber their hardware counterparts. Because hardware design teams generally tend to be smaller, they have typically adopted document control types of systems with revision numbering schemes. Team members share folders on a server or even from a filing cabinet! These solutions fall into the “organize-it-into-a-box” approach. Which raises the question: is that really version control? Complexity in software development Over the past 20 years, software programs have grown rapidly and become more complex. With each new software release, the code needed to be regularly updated to incorporate new or improved features and bug fixes. To cope, the software industry implemented modular design practices, a form of design reuse. However, modular design and reuse of code segments led to other challenges. Companies found that reusing software modules delivered many benefits. Modules resulted in increased dependability because reused software has already been tested in working systems. Reuse also reduced process risk, since the functionality, risk, and cost of existing software was already known. In addition, reusable software makes effective use of specialists, since the software embodies their knowledge. Perhaps most compelling, design teams realized that reuse resulted in accelerated development, reducing the time spent in coding and validation. As a result, they could meet accelerated time-to-market objectives and produce new iterations of product versions faster. However, implementing software design reuse did not come without its challenges. Generalized application of software modules doesn’t just happen. First, the modules must be maintained and development processes adapted in subsequent releases. Reused modules may also become increasingly incompatible with system changes in subsequent releases, resulting in increased maintenance costs. To actually have value, reused elements must be discoverable in the library, understood, and sometimes adapted. In subsequent versions, new or upgraded design elements will likely impose prerequisites and dependencies to which the reused elements must comply. Perhaps most challenging in the IP ecosystem, many companies believe they can and should rewrite components because they believe they can improve or own them. Software complexity leads to team approach In a development team environment, multiple people touch the same code. To manage the team, engineering managers need visibility of their team’s work. As a first requirement, the team needed a single secure storage repository for their various design modules. Once established, the design team needed an incremental history of changes made to the source code. To achieve effective reuse in a team environment therefore also required an effective method to check-in and check-out design sources. Over the past 20 years or so, software design teams realized that an effective design management system must facilitate collaboration between team members. As suggested above, the system must also create and maintain an incremental history of Robert Huxel is responsible for the care of Altium’s customers in Europe in his role as Industry Specialist - Enterprise Solutions - www.altium.com www.electronics-eetimes.com Electronic Engineering Times Europe July/August 2013 17


EETE JULAUG 2013
To see the actual publication please follow the link above