Digital Signal Processing Reference
In-Depth Information
of logic to bandwidth, the designer can pack many different processing modules
onto the same device. If the design parameters are revised to use a different device
that features a lower ratio of logic to bandwidth, the number of instances of the
processing modules may need to be reduced or some of the module may even need to
be moved to other chips. Maintaining modularity in the design affords these options.
Second, modules should be created in a parameterized fashion. Hardware design
languages (HDLs), such as Verilog and VHDL, support parameterized hardware
descriptions. These allow the designer to use variable parameters to specify the bit-
width of signals and support parameter-based auto-generation to easily vary the
number of times a module is replicated on the same chip. Using parameterized
designs and auto-generation of design units is valuable because it allows much more
rapid adaption to different sized chips. Changing the number of module instances
by manually instantiating the new quantity needed for a system with thousands of
sensors is not only very time-consuming and tedious, but also much more error-
prone. Fully parameterized designs also afford the ability to explore the design
space and rapidly examine the hardware efficiency using a variety of different chips,
each of which may have a different resource limit. This can help the designer make
intelligent decisions about the potential performance of the system on future devices
as well as provide concrete data to help guide the device selection process. When
attempting to convince a project manager to adopt a particular device, the argument
becomes much more potent if one can demonstrate that a change to that device
would result in a halving of the total number of chips needed to implement the
design.
4.4
Dataflow-Based Tools
Although creating modular and parameterized designs adds some automation and
efficiency to hardware updates due to technology changes, there are some challenges
that these techniques cannot solve. For example, in systems with a large amount
of interconnection and very high data rates between devices, it can be difficult
to efficiently balance computation and communication, and to choose the optimal
number of devices to prevent bottlenecks or under-utilization of data links. This
type of problem has been well-studied in the field of graph theory, but most HDL
implementations are not well-suited to rigorous mathematical analysis. On the other
hand, dataflow-style design strongly correlates to graph structures, allowing use of
graph theory. However, this style is not necessarily well-suited to direct translation
to high-performance, low-latency hardware. Researchers are working to create
automatic tools that bridge the gap between dataflow languages and HDLs. One
such example is the Open Dataflow (OpenDF) project, which features open-source
Dataflow-style descriptions can also serve as an intermediary to help bridge the
divide between software and hardware development for HEP systems. Dataflow
descriptions are particularly compatible with functional programming languages.
