The DSP blocks within the AMD devices can perform many different functions, including the following operations:
- Multiplication
- Addition and subtraction
- Comparators
- Counters
- General logic
The DSP blocks use multiple register stages to achieve high-speed operation. This design reduces the overall power footprint of the resource. AMD recommends that you fully pipeline the code intended to map into the DSP58, so that all pipeline stages are used. A set condition cannot exist in the function. This provides flexibility and ensures accurate mapping to the resource.
DSP58 slice registers within AMD devices contain only resets, and not sets. Unless necessary, do not code a set (value equals logic 1 upon an applied signal) around multipliers, adders, or counters. Also, do not code a set around other logic that you can implement within a DSP58 slice.
Many DSP designs are well-suited for the AMD architecture. To obtain the best use of the architecture, you must be familiar with the underlying features and capabilities. This familiarity allows design entry code to take advantage of these resources.
The DSP58 blocks use a signed arithmetic implementation. AMD recommends code using signed values in the HDL source to best match the resource capabilities and, in general, obtain the most efficient mapping. If unsigned bus values are used in the code, the synthesis tools can still use this resource. However, they cannot obtain the full bit precision of the component. This is due to the unsigned-to-signed conversion.
AMD recommends evaluating the design. This is especially important if it contains many adders. This evaluation increases the use of DSP58 slice pre-adders and post-adders. For example, you can use the adder cascade to build a systolic filter with FIR filters. This approach avoids using multiple successive add functions (adder trees).
If the filter is symmetric, you can evaluate using the dedicated pre-adder. This further consolidates the function into fewer LUTs and flip-flops. It also consolidates the function into fewer DSP slices as well. In most cases, it uses half the resources.
Knowing these capabilities allows for acknowledging proper trade-offs up front. These trade-offs can be accounted for in the RTL code. This approach enables a smoother and more efficient implementation from the start. In most cases, AMD recommends inferring DSP resources.