Optimal HDL Coding Styles for Programmable Logic Design

By Suhel Dhanani, Sr. Product Marketing Engineer, Altera Corporation (sdhanani@altera.com)

1.0 Introduction
As PLD designers implement higher density designs using programmable logic devices, they are discovering, like their ASIC counterparts, the benefits of a VHDL or Verilog HDL design flow. PLD vendors have rapidly adopted smaller process geometries so that 100,000 gate and larger PLDs are now widely available. Designs for devices of this complexity cannot be done easily using traditional schematic design entry. Also the use of VHDL and Verilog HDL synthesis for PLDs has increased, and device density is reaching the point where it has become a must. Estimates of the penetration of HDL tools into high-density programmable logic design range from 20 percent to 35 percent.

The obvious benefits provided by a HDL based design flow are higher designer productivity, design portability and a self-documenting design flow. Higher designer productivity is crucial when designing for programmable logic, whose biggest advantage over traditional gate-array devices is faster time-to-market and design flexibility. However from a designer's perspective, quality-of-results is also crucial. The design HAS to achieve the required speed and fit in the target PLD. These goals are achievable through optimal utilization of synthesis.

The programmable logic synthesis software available today, generally takes advantage of the unique features of different programmable logic architectures. But it is also true, that small changes in the HDL coding style (without making it specific to any one PLD vendor) can result in significant improvement in speed and area optimization when targeting PLDs. This article describes some of these optimal HDL coding techniques.

2.0 Optimal HDL Coding Styles

2.1 Using the IF - THEN Construct in VHDL
This is a common VHDL construct used inside a PROCESS statement. The usage of this construct can be a key pitfall, which can make the design logic very complex. Consider the following example, which implements a state machine decode logic.

PROCESS (current_state, x, y, z)
BEGIN
O1 & O2 & O3 <= "000";
IF current_state = (S1 OR S2) THEN 
O1 <= X;
ELSIF current_state = (S3 OR S4) THEN
O2 <= Y;
ELSIF current_state = (S5 OR S6) THEN
O3 <= Z;
END IF;
END PROCESS;

If the output signals are mutually exclusive the use of ELSEIF statement causes O3 to be dependent on all the states. In most synthesis tools the output O3 is decoded as

O3 = Z and (S5 or S6) and (NOT(S3) and NOT(S2) 
and NOT(S1) and NOT(S0))

Instead if the same code is written as

PROCESS (current_state, x, y, z)
BEGIN
O1 & O2 & O3 <= "000";
IF current_state = (S1 OR S2) THEN 
O1 <= X;
END IF;
IF current_state = (S3 OR S4) THEN
O2 <= Y;
END IF;
IF current_state = (S5 OR S6) THEN
O3 <= Z;
END IF;
END PROCESS;

Most synthesis tools will now remove the priority encoding and decode the output O3 as

O3 = Z and (S5 or S6)

This significantly reduces the logic required to implement the state machine decoder. If each output is indeed dependent on all of the inputs it is better to use a CASE statement and not an IF-THEN statement.

2.2 State Machine Coding Styles
In gate array architecture, a latch is more area efficient than a register (4 gates vs. 7+ gates). However this may not be the case when targeting a look-up table based PLD. For example in an Altera FLEX 10K device, there is a register in each logic element (LE); the basic building block of the device.

This is important to consider when implementing state machines. When targeting a state machine design in a register-rich programmable logic architecture, one-hot encoding is much more efficient in terms of area optimization than binary encoding.

One-hot encoding for state machines uses one register bit per state. This encoding technique uses significantly fewer combinatorial resources than binary encoding, while increasing the number of registers required. However if the designer is targeting a look-up table based PLD in which registers are abundant, one-hot encoding for state machines utilizes fewer look-up tables and provides shorter register-to-register delays than binary encoding.

3.0 Instantiation vs. Inferring Functions
Implementation of standard functions in a HDL design environment can be optimized for area and speed by instantiating functions rather than having the synthesis tool infer them. Designers can choose either LPM (Library of Parameterized Modules) or Synopsys Designware functions to efficiently implement standard functions in their designs. Using either of these types of functions does not compromise the portability of the HDL design. The designer can still target multiple PLD architectures and/or gate-array technologies.

DesignWare functions are technology independent building blocks provided by Synopsys. Synopsys provides additional information on DesignWare at http://www.synopsys.com/products/designware.

The LPM standard was proposed in 1990 as a means to enable efficient mapping of digital designs into divergent technologies such as PLDs, gate arrays, and standard cells. Preliminary versions of the standard appeared in 1991 and again in 1992. The standard was accepted as an Electronic Industries Association (EIA) Interim standard in April 1993 as an adjunct standard to the Electronic Design Interface Format (EDIF). More information on the LPM functions is available at http://www.edif.org/lpmweb.

To demonstrate, let's look at a 32-bit loadable, enabled, up/down counter that is inferred and one that is instantiated.

Inferred Counter

ARCHITECTURE structure OF count32 IS
BEGIN
-- A synchronous load enable up/down counter
PROCESS (clk, reset)
Variable temp : STD_LOGIC _VECTOR(31 downto 0);
BEGIN
IF (clk'EVENT AND clk = '1') THEN
IF (load='0') THEN
temp := data;
ELSE
IF (enable = '1') THEN
IF (up_down = '1') THEN
temp := temp + 1;
ELSE
temp := temp - 1;
ENDIF;
ENDIF;
ENDIF;
result <= temp;
ENDIF;
END PROCESS;
END structure;

The inferred counter gives satisfactory results. However instead if this counter is instantiated using either a Synopsys DesignWare counter or a LPM_COUNTER there could be considerable improvement in area utilization and registered performance.

Instantiated DesignWare Counter

ARCHITECTURE structure OF count32 IS
BEGIN
U1: DW03_updn_ctr
GENERIC MAP (width => 32)
PORT MAP (data => d, clk =>clk, reset=> rst, 
up_dn => up_dn, load => ld, tercnt => tercnt, 
cen=> ce, count => q);
END structure;

Instantiating a counter can potentially double the design performance while reducing area utilization. Also the complexity of the code is reduced considerably.

4.0 Conclusion
When designing for programmable logic, optimal HDL coding techniques can significantly improve the quality-of-results. Designers who understand the underlying PLD architecture and structure their HDL code accordingly can get the best design performance and the most efficient area utilization. Also using optimized functions such as LPMs can significantly speed the design cycle and provide better quality-of-results.


		Click here to get your listing up.