COMMENTARY: Got Configuration Management?

Companies that don't adopt appropriate configuration management technology will fail and fall by the wayside!

For many years, I've been waffling on about the incredibly slow
adoption rate of version control systems by the embedded industry. As
an engineer and a writer I am "up-to-my-ears" in files of all types (documentation, design, graphics, etc.)
and I rely on version control to track my changes.

Version control [or software
configuration management (SCM) as it's known in the software industry]
records every action or iteration performed on a file (HDL, schematics,
project documents, firmware and source code, etc.).

This means that a given set of files and versions - called a
configuration - can be faithfully recreated back to any point in time.
SCM tools also provide branching and merging functions that enable
concurrent development on single files and enable new product variants
to be created easily.

The lack of version control adoption by my fellow embedded engineers
was brought home to me once again by the 2008 Embedded Market study
(conducted by Embedded Systems Design magazine and embedded.com). The
recent article, "An Insider's view of the 2008 Embedded
Market Study," by Richard Nass caused me to scratch my head
— yet again — as to why the adoption rate of this tool is so low when
it can address the issues we find (at least according to the study)
most important. The following points highlight what I'm talking about:

* Only 6% of respondents are using hardware/software co-design
tools. (An appropriate configuration
management tool would help these folks meet the needs they identify as
being important.)

* Only 14% of the respondents identify configuration management
tools as falling into the "Favorite/Most Important" category. (This reflects the lack of use of
appropriate tools; once a team has used a good configuration management
application, this score rockets up).

* It's no surprise that 78% of projects re-use code previously
developed in-house. In fact, the editor of the article, Richard Nass,
writes: "I've always preached the need to reuse code whenever possible,
rather than writing from scratch." (This
point alone should provide a 'Eureka moment' to embedded project
leaders, because the right SCM tool with strong branching and merging
capabilities enables seamless reuse and product variations.)

... and, skipping briskly along for the sake of brevity...

* Nearly 60% of companies are outsourcing, either in the US or
outside. (An appropriate configuration tool can help effectively manage
distributed and concurrent development.)

So, my question is - if meeting schedules and code re-use in
distributed development environments is the goal, then why aren't
companies tackling these challenges by using a version control tool?

There are so many "pieces" involved in a modern embedded product
that bringing the correct versions of each piece together in the right
place at the right time is a major feat. And, this is where version
control or managing change can help.

We're drowning in data
When I started out in design back in the days of yore, we tended to
have lots of pages of gate-level schematics but - overall -
things were relatively easy to wrap one's brain around.

By comparison, modern designs are incredibly complex, often
involving thousands of files and millions of lines of code; hardware
and firmware design teams are often fragmented into multiple groups
scattered across the country and/or around the world; and time to
market pressures are cutting development cycles to the bone.

We start with the high-level architectural specification and ongoing
documentation. Once members of the hardware team gets involved, they
spawn multiple representations of the design captured 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, and Register Transfer Level (RTL) representations captured
in VHDL and/or Verilog and/or SystemVerilog.

The there's formal verification and assertion-based verification,
both of which involve assertions written in PSL and/or SVA and/or some
other language. And, of course, we also have testbenches written in e
and/or SystemC and/or SystemVerilog and/or... the list goes on.

In the case of the firmware designers, their code components can
involve thousands of files captured in C/C++ and/or assembly language
and/or some other specialized languages. These components may include
system initialization and verification routines, the code that
interfaces with the hardware abstraction layer (HAL), and a real-time
operating system (RTOS) along with associated device drivers.

And, of course, we also have the developers of the software
applications that will be seen by the end users...

The bottom line is that all of these disciplines (hardware,
firmware, and application software engineers) can benefit from an
appropriate configuration management application... but which one?

But wait, there's hope...
There are a number of powerful and sophisticated version/configuration
management tools around, but - as with everything - you have to be
careful to choose the right one before reaching into your pocket and
pulling out your hard-earned money.

Some tools are more tailored to support application software
development environments and are less useful when it comes to managing
various aspects of an embedded project, including firmware and hardware
design files.

Another problem is that some tools are very complex and require a
team of IT gurus to install them as well as significant training and
expertise to actually use them. 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," while
data/document management is just something that "needs to be done". If
such a tool is too complex, users tend to work outside/around the
system rather than using it as intended.

All of which brings me to Perforce SCM. This little rascal
(the tool, not the company) is particularly well-suited for embedded
development because it manages much more than just source code and is
easy to learn and administer.

With reference to the points raised in the Embedded Market Study,
this tool helps embedded developers in a number of important ways:

* Helping engineers meet schedules:
Perforce improves project productivity by automating version control on
any type of software/hardware design file, including HDL files,
compiled binaries, schematics, project documents, and firmware/software
code. Adding Perforce to the code creation phase ensures repeatability
and allows changes to be easily backed out of the build if something is
modified and the design no longer functions correctly.

* Re-using code on multiple
projects: Perforce has fast and efficient branching and merging
capabilities that make it easy to reuse code and create custom variants
and prototypes. Using minimal disk space, branches are created quickly
(even for large binaries) and changes are propagated easily between
branches using spiffy merge tools. Furthermore, I understand that the
number of branches that Perforce supports is nearly unlimited.

* Managing Distributed Development
and Outsourcing: With Perforce, distributed teams can work
together on the same products regardless of their physical location.
Perforce uses an efficient TCP/IP based messaging protocol to transfer
data between client and server, thereby reducing the latencies
associated with NFS solutions. Important files are cached locally for
each team, while real-time access to the state of development across
the entire project is also provided.

The bottom line is that Perforce works, as is evidenced by the fact
that more than 300,000 developers at 5000-plus organizations worldwide
now use it to manage their digital assets. Notable U.S. customers
include AMD, Electronic Arts, National Instruments, QUALCOMM, NVIDIA,
Symantec, and Washington Mutual. International customers include BBC
News Online, Deutsche Bank, and Symbian.

I've said it before...
And I will doubtless say it again... today's embedded designs are so
humongous and complex that a solid version management tool is a
critical necessity as part of our development arsenal. As far as I'm
concerned we've reached the breaking point. Going forward, embedded
design teams that use modern document/file management and version
control systems will succeed; those that don't will fail and fall by
the wayside.

Most of the engineers I know simply don't have the time (or
patience) to learn a mega-complex version/configuration management tool
that ends up "getting in the way" and slowing the design process down
so much so that folks end up "working around" the tool (which is a polite way of saying they don't
use it until the very end of the project).

But, Perforce is different; it's easy to install, learn, and
administer; but don't just take my word for it ... why not
try it yourself for free and then tell me what you think.

Some groups have 1 engineer working on code. SCM doesn't help too much 1 engineer.
But that said (most groups have multiple people) people who don't use SCM tools are not doing professional work. They can do it this way but they should not be PAID.
Too much 'I don't wanna'...