²ÝÁñÉçÇø

Analyze Datapath Extraction

To write RTL code that gives the best possible QoR during datapath synthesis, designers must understand what datapath functionality current synthesizers can efficiently implement, how the datapath synthesis flow works, and how coding can influence the effectiveness of datapath synthesis. To understand these requirements, refer to the SolvNet article "" (login required).

In Design Compiler, the analyze_datapath_extraction command can be used to analyze the RTL and get feedback whenever datapath extraction is blocked. This information is provided via HDL messages, based on the RTL coding guidelines, to the user.

The analyze_datapath_extraction command has been updated in I-2013.12 to provide enhanced reporting on the datapath extraction. These updates can help designers quickly determine and prioritize datapath leakage issues in large hierarchical designs.

The following enhancements have been made to analyze_datapath_extraction:

• Message Filtering: Datapath leakage messages (HDL-120, HDL-132) can now be filtered based on severity level (low, medium, and high). The severity of the message is determined based on the potential QoR impact.
• Message Sorting: Datapath leakage messages (HDL-120, HDL-132) can now be sorted based on severity.
• Max Messages: Maximum number of leakage messages to report can be specified.
• HTML Reporting: The command can now write out well-formatted HTML files with HDL messages. The messages contain hyperlinks to RTL files along with line numbers indicating the code that is blocking the datapath extraction.
• Hierarchical Reporting: The command can now be run on one or more sub-designs. Datapath extraction analysis and reporting will be done on each of the sub-designs provided.

The new switches are highlighted below:

 analyze_datapath_extraction # analyze_datapath_extraction

 [-html_file_name html_file]

 (Output html file name)

 [-no_autoungroup] (supress auto_ungroup)

 [-no_report] (do not show resources after the analysis)

 [-filter_msg ]

 (filter messages based on severity level:

 Values: none, low, medium)

 [-sort_msg] (sort leakage messages in each design)

 [-max_msgs ]

 (maximum number of leakage messages to display in each design:

 Value >= 1)

 [design_list] (list of sub-designs to analyze)

Figure 1 shows the output of the enhanced analysis_datapath_extraction command released in I-2013.12.

Datapath Leakage Messages

Datapath leakage happens when an internal operand is not wide enough to store the result of an operation, but the full result is required later for another operation.

The priority of leakage messages is shown below:

1. The width of the operand that has leakage detected
2. The size and operation type of the operator driving the operand with leakage
3. The sizes and operation types of the operators driven by the leaked operand

Example 1:

In the sample report of analyze_datapath_extraction in Figure 1, two HDL-132 messages are sorted based on the priority of potential QoR impact:

Information: The output of subtractor associated with resources 'sub_111

 (top.v:111)' is treated as signed signal. (HDL-132)

Information: The output of subtractor associated with resources 'sub_115

 (top.v:115)' is treated as signed signal. (HDL-132)

RTL snippet of the relevant code:

 111 assign add_mod_temp[15:0] = 0 - a1[7:0]; //sub_111

 112 assign add_mod[17:0] = add_mod_temp[15:0] + a2[7:0];

 113 

 114 

 115 assign add_mod_temp2[10:0] = 0 - a2[7:0] ; //sub_115

 116 assign add_mod2[12:0] = add_mod_temp2[10:0] + b2[7:0];

In line 111, the 8 bit wide ¡®a1¡¯ is subtracted from 0 and stored in a 16 bit result, ¡®add_mod_temp¡¯. Similarly, in line 115, the 8 bit wide ¡®a2¡¯ is subtracted from 0 and stored in an 11 bit result, ¡®add_mod_temp2¡¯. As none of the signals are explicitly defined as signed signals, the operations performed are unsigned subtractions. However, the output of these operations are stored in much wider signals ¡®add_mod_temp¡¯ and ¡®add_mod_temp2¡¯, resulting in sign extension (the signals to be treated as signed signals) which is what the HDL-132 messages refer to. To fix this, the RTL can be modified either to remove the sign extension for ¡®add_mod_temp¡¯ and ¡®add_mod_temp2¡¯, or all signals in the subtraction operations can be properly declared as signed signals.

Additional information and examples for each of the HDL messages are refer to the man pages for these messages. For example, to get more information on HDL-120:

dc_shell> man HDL-120

For large designs with multiple messages, the following guidelines can be useful in simplifying the results from analyze_datapath_extraction:

1. Identify the critical sub-designs with respect to timing, power, and arithmetic contents
2. Focus on the messages generated from the critical sub-designs, especially the higher priority messages (e.g., HDL-120, HDL-132)
3. Prioritize the operators based on their timing, power, area
4. Modify RTL to improve datapath extraction on operators associated with the most critical messages first

New DesignWare Datapath Functions

The following new functions have been added to the DesignWare Building Blocks Library.

Saturation Multipliers

A saturation multiplier is a multiplier with its upper output bits truncated and lower output bits saturated in case there is an overflow on the upper bits.

The following functions are available for saturation multiplier:

• DWF_dp_mult_sat: Saturation multiplier
• DWF_dp_mult_ovfldet: Multiplier with overflow detection

Detailed information on these functions is available in the Multiply and Saturate datasheet (SolvNet login required).

Combined Multipliers

A combined multiplier allows the flexibility of dynamically setting each input to signed or unsigned using a control signal.

The following functions are available for combined multipliers:

• DWF_dp_mult_comb: Combined multiplier
• DWF_dp_mult_comb_sat: Combined multiplier with saturation
• DWF_dp_mult_comb_ovfldet: Combined multiplier with overflow detection

Detailed information on these functions is available in the Combined Unsigned/Signed Multiply and Saturate datasheet (SolvNet login required).

Summary of features:

• Can be used as a function call in the RTL
• Support for VHDL/Verilog
• Parameterized widths for inputs and outputs
• Support for signed, unsigned, and combined (signed/unsigned) scenarios
• For combined multipliers, each input can be set to signed or unsigned
• Overflow detection
• Better QoR compared to implementing similar functionality with existing multipliers. Figure 2 shows average improvement in area and timing across multiple libraries under tight timing constraints for the Saturation Multiplier

New DesignWare Component

Saturation Divider

The DW_div_sat is a new DesignWare Building Block component that is a combinational integer divider offering saturation in its quotient output. This divider can be instantiated in designs when the full width of the quotient is not required. It provides better QoR compared to implementing the same functionality using a traditional divider (DW_div) and saturating the quotient output external to the DesignWare divider component.

Summary of features:

• Supports parameterizable quotient lengths. When the quotient length is smaller than the dividend length, the quotient is saturated in case of overflow.
• Supports both signed and unsigned data operations.
• Detects the condition where the divisor is zero.
• Offers multiple architectures, including cla, cla2 and cla3 which are available for selection based on area/performance trade-offs.
• Better QoR compared to implementing similar functionality with existing divider as the divider can be simplified when the quotient is shorter. Figure 3 shows average improvement in area and timing across multiple libraries under tight timing constraints for the Saturation Divider component.

Detailed information on this DW component is available in the Combinational Divider with Saturation(DW_div_sat) datasheet (SolvNet login required). 

Instantiated minPower component support in DC Explorer

DC Explorer now supports instantiated minPower components, featuring:

• Supports usage of instantiated DW minPower components in DC Explorer flow
• Allows minPower.sldb allowed to be included in synthetic library
• Does not support minPower optimizations (datapath gating, power optimizations)
  • QoR/runtime similar to that in default flow