and our use of off-the-shelf FPGA-based
hardware as well as high-level FPGA software
design tools that scale from research to
manufacturing. In many cases, we find that
we can use the generic core architectures we
develop in multiple products. For example,
the same architecture for a pump controller
that regulates an IV and medication flow
pump can be used in another design project
that controls a motor for administering
blood transfusions.
Why Hardware Trumps Software
To employ this methodology effectively
and further speed our design process, we
had to change the way we thought about
designs, moving from a software-centric to
a more hardware-centric approach. As
many are aware, medical-device recalls
reached an all-time high in 2008—up 43
percent from 2007. Key causes, according
to the experts at the FDA, involve two primary
issues: defects in manufactured raw
materials and poorly developed software.
Companies can monitor the quality of
their raw materials fairly easily, but it can
be very tricky to address software quality.
As the lines of code in devices continue to
mushroom, the problem will only worsen—a
particular concern since the FDA’s
consumer safety branch says much of the
burden of safety is now the responsibility
of the medical-device designer.
At HEI, we feel there is a potential solution
to this problem, but it’s not in more
testing, code reviews and process. Instead,
we simply try to write less software and
Scrum/Sprint Waterfall
QSR compliant Yes Yes
Speed in execution Yes No
Reduces program risk Yes No
Early verification of requirements Yes No
Easy to implement change Yes No
Able to proceed without complete requirements Yes No
Short development cycles Yes No
Overall time-to-market Much reduced Typical
Table 1 – The scrum/sprint methodology outperforms the waterfall approach to development.
push more of the logic into hardware elements
like Xilinx FPGAs. Let’s look at
some of the common causes of software
failure and how we are addressing these
issues with FPGAs.
Eliminating Deadlock
Most modern devices need to be able to
handle multiple tasks simultaneously, yet
most embedded processors are still limited
to one processing core. This means the
processor can execute only one instruction
at a time. Meanwhile, parallel processes
Adjust
Plan
Verify
Define
Requirements
and Burn-
Down List
Scrum/Sprint
Development Cycle
Build and
Integrate
XCELLENCE IN AUTOMOTIVE & ISM
aren’t much better, as they must still share
the main CPU. In addition, other shared
resources such as communication drivers,
hard disk and user interface elements present
opportunities for deadlock—the condition
that occurs when two or more
processes are waiting for one another to
release a resource.
Deadlock can be very difficult to
reproduce and debug, because the situation
often relies on multiple processes
and usually requires a specific and synchronized
sequence of events to occur.
Unit testing alone will not catch most
deadlock issues; they are usually uncovered
by code reviews, adept system testers
or simply by luck.
With FPGAs, by contrast, “processes”
that are independent have their own
physical circuitry and therefore, there are
no shared resources. On each clock tick,
combinatorial logic latches in each circuit
and stores values in separate registers. No
deadlocking can occur because neither
process relies on the other’s resources.
This allows you to put much more faith
in the results of simulation and unit testing,
since other unknowns like resource
contention are no longer an issue.
Analyze
Risks
Fourth Quarter 2009 Xcell Journal 31
Design
Figure 5 – In the “scrum/sprint” process, only high-level system architecture and specifications
are required to start the project. Development is divided into “sprints” four to six weeks in duration.
Each sprint follows a six-step development cycle, as shown.