@head: Max's Chips and Dips - Embedded Developers Should Be Ahead of the Curve . . . Not Behind It!
@deck: It's time for embedded hardware and firmware/code developers to be dragged kicking and screaming into the 21st Century!
@text: Today's embedded hardware and firmware/code developers are creating some of the most complex and sophisticated systems ever conceived by humankind. Some System-on-Chip (SoC) devices may contain tens or hundreds of millions of logic gates, while their embedded software content can run to tens of millions of lines of code.
It's a sad truth, however, that many industry observers regard the design environments used by embedded developers with a mixture of dismay and wonder. The "dismay" is caused by the fact that – in at least one mission-critical area – these environments are so far behind the curve as to make one shake one's head in disbelieve; the "wonder" is that any embedded system that gets developed actually works at all.
<b>The Problem</b>
Embedded designs are composed of literally thousands of files. In addition to any specifications and documentation, hardware design engineers are up to their ears in representations of the design specified at different levels of abstraction. These include (but are not limited to) algorithmic models for use with MATLAB from The Mathworks, Transaction-Level Models (TLMs) written in SystemC, Register Transfer Level (RTL) representations captured in VHDL and/or Verilog and/or SystemVerilog. And there are assertions written in PSL and/or SVA and/or . . . ; and testbenches written in e and/or SystemC and/or SystemVerilog and/or . . . ; the list goes on.
Similarly, the firmware/code components of an embedded system can involve thousands of files captured in C/C++ and/or assembly language and/or other specialized languages. These components may include system initialization and verification routines, the hardware abstraction layer, a real-time operating system (RTOS) and associated device drivers, all the way up to the embedded application code itself.
Just to increase the fun and frivolity, both the hardware and firmware/code developers may be fragmented into multiple teams based in disparate locations around the world. The underlying issue is that, by default, computers provide only a static representation of their file systems; that is, theysave only the current contents of a file, but the past states of the file are lost. This obviously makes life difficult when it comes to keeping track of thousands of interrelated files with a strong temporal relationship in which only specific versions of each of the files "go together."
For more than three decades, the application software industry as a whole has addressed this issue by embracing ever-more sophisticated document/file version and control systems. In the early 1980s, for example, Walter Tichy of the Department of Computer Science at PurdueUniversity developed the Revision Control System (RCS) for use on UNIX platforms. In 1986, Dick Grune extended this work and introduced the Concurrent Versions System (CVS), which conceptually "sits on top of" RCS.
These days, there are a variety of sophisticated systems that provide a superset of the capabilities offered by the early tools. Known as Software Configuration Management (SCM), systems, these tools are actually applicable to any type of software/hardware design file, including textual and binary representations. The problem is that – almost unbelievably – embedded developers don't use them. In fact, it is estimated that 40% of embedded developers don't use any form of version control/management at all; furthermore, a lot of the embedded developers who do employ document management use only the most rudimentary of systems such as RCS.
<b>The Solution</b>
In a nutshell, without trying to be too bold, the best solution on the market today is Perforce SCM from Perforce (<a href=" target="_new"> Some key features of Perforce SCM – which can handle every form of embedded hardware/software document known to mankind (even ones that haven't been invented yet) – can be summarized as follows:
<ul>
<li<b>Easy to Install:</b> Some file/document version control systems require a team of IT experts to install (and subsequently maintain) the software. By comparison, users of Perforce SCM are typically amazed to discover its incredibly low administration overhead: basically, anyone can download (from the Internet), install, and maintain this tool and no expert administration is required.</li>
<li<b>Easy to Use:</b> Some file/document version control systems require their users to be experts in the technology. Embedded developers don't have the time (or interest) to spend weeks or months learning a new tool that is not core to their development mission. Creating designs and writing code is the "fun stuff" – document management is just something that "needs to be done". Users of Perforce SCM boast about how easy the system is to learn and use.</li>
<li<b>Powerful and Scalable:</b> Some file/document version control systems work well when it comes to handling tens of local users working with a few tens of gigabytes of data, but they slow down or grind to a halt as more data and users are added, especially when users are remotely located. By comparison, Perforce SCM can easily manage hundreds of gigabytes of data; it can handle hundreds of remote users working concurrently on the same files, and the system remains FAST even with hundreds of users and hundreds of gigabytes and hundreds of thousands of logged changes!</li>
<li<b>Multi-Platform Support:</b> Some file/document version control systems may look attractive … until you discover that they don't actually run on the computing platform you use. By comparison, Perforce SCM is available on a wide variety of platforms, including Windows NT/2000/XP/2003 and most Unix/Linux operating systems. Furthermore, Perforce SCM features a highly scriptable command-line client and graphical user interface for use on Windows, Mac OS X, Linux, Solaris, and FreeBSD.</li>
</ul>
Perforce SCM has so many features and capabilities that it would make your head spin, so – for the purposes of this brief introduction – we'll restrain ourselves to three key concepts:
<ul>
<li<b>Change-Based Architecture:</b> Many file/document version control systems require you to know the names of the files in which you are interested. Once you've tracked down the names of these files, you then have to request a list of the changes associated with those files. By comparison, Perforce SCM employs what is known as a "change-based architecture". The idea here is that every time someone checks a file or a group of files into the database, Perforce SCM generates a unique change (log) number, which makes it easy to keep track of even the most complex interactions with the system.</li>
<li<b>Atomic Transactions:</b> Many file/document version control systems require you to handle files individually; for example, if you wish to check-in (input) 20 files, you have to submit each one individually, By comparison, Perforce SCM employs the concept of "atomic transitions," which refers to the ability for groups of files to be tracked together. Even though each file has its own revision history, Perforce SCM allows youto process (e.g. submit) a group of files together and this atomic transaction will remain persistent in the future.</li>
<li<b>Inter-File branching:</b> When working on an embedded design, you often wish to play "what-if" games and explore different hardware/firmware design scenarios. In this case, you typically wish to take a copy of a group of files and work with that copy. Perforce SCM is totally geared up to addressing this type of situation. It allows multiple teams to "branch" (to start working with different copies of various groups of files) and then "merge" or "replace" these files as required.</li>
</ul>
<b>The Bottom Line</b>
As you can tell, I'm really somewhat enthusiastic about Perforce SCM. As far as I'm concerned, the bottom line is really simple – today's embedded designs are incredibly large and complex; managing all of the hardware and firmware code documentation, design, and implementation files is a nightmare. Development teams that use modern document/file management and version control systems will succeed; teams that don't will fail and fall by the wayside.