OBSOLESCENCE
COMMERCIAL USE
SOFTWARE VIEW
can become very cumbersome, and one
faulty component can delay the entire system
development. For this reason, at HEI
we reuse as much known-good and proven
middleware and RTOS driver combinations
as possible. We use, for example, the
middleware drivers that are a part of NI’s
Single-Board RIO platforms.
In addition to validating software in
each use case, we also need to validate all
the third-party intellectual property (IP)
we are using in our FPGA-based design.
However, once we have validated all of our
use cases, we have confidence that the IP
will behave as expected when integrated
with other components. Let’s look at our
FFT example again. If we use an FPGA, we
can acquire or generate an FFT IP core and
validate its numerical correctness for each
use case—the same as with the software.
However, the risk of intermittent failure
decreases drastically because there is no
need for all the processor middleware we
would have in a software-centric design. As
such, there is no longer an RTOS, and the
SPI driver is its own IP core—its operation
does not directly affect the FFT.
Furthermore, if we modify the SPI driver
ACQUIRE ANALYZE PRESENT
RESOLUTION
FREQUENCY
MARKETING
HARDWARE VIEW
Figure 7 – The late product life cycle takes the product to market, where feedback
helps determine the features for the next generation of the device. This completes
the cycle and brings it back around to the concept phase.
implementation, we don’t need to revalidate
the unaffected areas of the system.
Managing Buffer Overflow
Another example of how we use FPGAs to
mitigate errors that typically occur in software-centric
systems is in buffer overflow
management. Buffer overflow occurs when
a program tries to store data past the end of
the memory that you’ve allocated for that
storage, and it ends up overwriting some
adjacent data that it shouldn’t. This can be
a really nasty bug to diagnose, since the
memory that was overwritten could be
accessed at any time in the future, and it
may or may not cause obvious errors. One
of the more common buffer overflows in
embedded design is a result of high-speed
communications of some sort, perhaps
from a network, disk or A/D converter.
When communications are interrupted for
too long, buffers can overflow, so we need
to account for this to avoid crashes.
We use FPGAs to manage buffer overflow
in two ways. In one example, we use
the FPGA to manage a circular or doublebuffered
transfer, where it can offload the
burden from a real-time processor. In this
XCELLENCE IN AUTOMOTIVE & ISM
case, the FPGA serves as a coprocessor that
reduces the interrupt load on the main
processor. This is a common configuration,
especially in high-speed A/D converters.
In a second example, we use the FPGA as
a safety layer of protection, routing all of the
patient-facing I/O through the FPGA before
it gets to the processor. In this case, you can
add extra safety logic to the FPGA so that
you can place all your outputs in a known
and safe state in the event of a software crash
on the processor. The FPGA serves as a
watchdog and its logic ensures that risk to
the patient is lowered in the event of a software
failure. By making the architectural
decision to use an FPGA in your device’s primary
signal chain, you can use one or both
of these two methods to guard against buffer
overflow and to better handle the situation if
and when it does occur.
In fact, the more overall system functionality—software
as well as hardware—
we move into the FPGA, the faster we can
expedite our design process and ultimately
validate our design running in the customer’s
end product. The sooner we can
validate the reliability of our design running
in the overall system, the sooner our customer
can validate the entire end product
and get it to the FDA for approvals. This of
course means our clients can then get their
products to the market faster, and in doing
so improve quality of life or even save lives.
If we were to implement a design using
an ASIC process, we would have to wait
many months for a foundry to create the
hardware. The extra steps of having to verify
the ASIC’s physical design, create masks
and then manufacture the design create
more room to introduce errors and defects.
If a design does pick up an error in any of
these steps, the result can be significant
delays in getting products to market in a
timely manner. Because FPGAs are already
fabricated and thoroughly tested, we only
have to worry about our design, our software
and ensuring that our design runs to
the customer’s specifications. With our
scrum-and-sprint methodology, our hardware-centric
mind-set, use of reliable tools
and choice of FPGAs over ASICs, we can
make a difference for our customers and, in
turn, their customers—the patients.
Fourth Quarter 2009 Xcell Journal 33
To view a Ceros magazine you need to have JavaScript enabled in your browser and have the flash player 8 or higher installed. To install the latest flash player, click the icon above, install the flash plugin and then click here to refresh this page.