Hardware vs. software solution

Download Report

Transcript Hardware vs. software solution

Hardware vs. software solution
• Many high-performance applications can ONLY
be realized in hardware
– The overhead introduced by executing code on a
general-purpose processor prevents a software solution
in many real-time applications
– Examples are video processing, modulation/filtering,
types of real-time simulation
– Interfaces that have critical timing cannot be controlled
precisely with a purely software implementation
David Rutishauser, Crew Systems and Operations
Branch
Hardware vs. Software Solution
• Some solutions map better to software
– Floating-point arithmetic requires much of the
functionality of a general purpose processor
(currently)
– Complex, dynamic data structures
– Iterative processes (loops)
David Rutishauser, Crew Systems and Operations
Branch
Benefits of FPGA Designs
• FPGAs are general-purpose digital hardware
• Integration of discrete components simplifies
design and improves performance and reliability
• Ability to re-program reduces risk in the design
process
• New hardware revisions are easy to implement
• Many other potential benefits to reconfigurable
hardware
David Rutishauser, Crew Systems and Operations
Branch
FPGA Technology
• FPGAs use an architecture consisting of (n) generalpurpose, configurable logic cells (Xilinx uses CLBs, for
Configurable Logic Blocks; each vendor has its own
proprietary architecture)
• Each logic cell can be used itself or in combination with
other cells (via a controllable interconnect network) to
implement any digital logic function, within the limits of
the available resources on a particular device
• FPGA functionality is captured in a binary file, which is
effectively a set of commands that control switches in the
CLBs and interconnect network. The file must be loaded
to the device prior to operation
David Rutishauser, Crew Systems and Operations
Branch
FPGA Design Process
• The FPGA design process is complex, but highlyautomated
– Hardware compliers (silicon compliers) exist from
FPGA manufacturers and third-party vendors
– Compliers use a high level behavioral description
(schematic or High Level Design Language, HDL) and
performance constraints (e.g. timing) as input to
generate a binary configuration file
– Skilled designers guide the tools to a solution; the tools
need an accurate and efficient HDL description to
synthesize an accurate and efficient design
David Rutishauser, Crew Systems and Operations
Branch
FPGA Design Steps
HDL description,
hand-written or
generated from a
schematic
Translation, HDL
syntax checked and
design converted to
generic logic
components
Vendor or third-party synthesis
tools run to create intermediate
representation; low-level
functional description with no
timing or resource info
Entity videoFilter is
Optimize/Map
Designer adds timing/area
constraints
Port (
CLOCK in BIT;
INPUT in integer;
OUTPUT out integer;
Device-specific representation
)
End videoFilter;
Binary configuration file
* Design is verified
with simulation at
each step in process
Vendor place and
route (“back end”)
tools
10010111011
…
David Rutishauser, Crew Systems and Operations
Branch
The Star Bridge Claim
•
•
•
•
•
•
Star Bridge has replaced the initial steps (up to the back-end tools, most likely)
of the design process with their own high-level design methodology
The process allows the performance and capability of hardware designs to be
utilized by non-hardware designers
A great deal of optimization, resource allocation, and design verification must
be happening behind the scenes
Assumptions must be made to automate the decisions traditionally made by a
human designer
The overhead will increase exponentially with the complexity of designs input
to the system
Experiments are required to determine how well the system works
David Rutishauser, Crew Systems and Operations
Branch