Documentation

HDL Constructs Properties

Customize generated HDL style

Customize HDL constructs in the generated code.

You can customize the style of the generated VHDL and Verilog code using the properties on this page. Specify these properties as Name,Value pair arguments to the generatehdl function, or set the corresponding options on the Global Settings > Advanced tab in the Generate HDL dialog box.

HDL Coding Style

expand all

When you set this property to 'off', the generated code preserves the types of input values during addition and subtraction operations and then converts the result to the desired type.

When you set this property to 'on', the generated code type casts input values of addition and subtraction operations to the desired result type before operating on the values. This setting produces numeric results that are typical of DSP processors.

The CastBeforeSum property is related to the setting of the Filter Designer quantization option Cast signals before sum as follows:

  • Some filter object types do not have the Cast signals before sum property. For such filter objects, CastBeforeSum is effectively off when HDL code is generated; it is not relevant to the filter. In the Generate HDL dialog box for these filters, Cast before sum is disabled.

  • When the filter object does have the Cast signals before sum property, by default the coder sets CastBeforeSum following the Cast signals before sum setting in the filter object. This setting is visible in the Generate HDL dialog box. If you change the setting of Cast signals before sum in Filter Designer, the coder updates the setting of Cast before sum in Generate HDL.

  • To override the Cast signals before sum setting passed in from Filter Designer, set Cast before sum explicitly in the Generate HDL dialog box, or set the CastBeforeSum property when you call generatehdl.

See Specifying Input Type Treatment for Addition and Subtraction Operations.

VHDL configurations for an entity can be either inline with the rest of the entity code, or external in separate VHDL source files. By default, the coder includes configurations for a filter entity within the generated VHDL code. If you create your own VHDL configuration files, suppress the generation of inline configurations.

When you set this property to 'on', the coder includes VHDL configurations in files that instantiate a component.

When you set this property to 'off', the coder does not generate configurations, and requires user-supplied external configurations. Use this setting if you are creating your own VHDL configuration files.

When you set this property to 'on', the coder unrolls and omits FOR and GENERATE loops from the generated VHDL code. Use this option if your EDA tool does not support GENERATE loops.

When you set this property to 'off', the generated VHDL code can contain FOR and GENERATE loops.

When you set this property to 'on', the coder uses the '0' & '0' syntax for concatenated zeros. This syntax is recommended because it is unambiguous.

When you set this property to 'off', the coder uses the "000000..." syntax for concatenated zeros. This syntax can be easier to read and is more compact, but can lead to ambiguous types.

When you set this property to 'on', the coder represents constants by aggregates, including constants that are less than 32 bits wide. These VHDL declarations show constants of less than 32 bits declared as aggregates:

CONSTANT c1: signed(15 DOWNTO 0):= (5 DOWNTO 3 =>'0',1 DOWNTO 0 => '0',OTHERS =>'1');
CONSTANT c2: signed(15 DOWNTO 0):= (7 => '0',5 DOWNTO 4 =>'0',0 => '0',OTHERS =>'1');

When you set this property to 'off', the coder represents constants less than 32 bits as scalars, and constants greater than or equal to 32 bits as aggregates. These VHDL declarations show the default scalar declaration for constants of less than 32 bits:

CONSTANT coeff1: signed(15 DOWNTO 0) := to_signed(-60, 16); -- sfix16_En16
CONSTANT coeff2: signed(15 DOWNTO 0) := to_signed(-178, 16); -- sfix16_En16

When you set this property to 'on', the generated code uses the VHDL rising_edge function when operating on registers.

Delay_Pipeline_Process : PROCESS (clk, reset)
BEGIN
  IF reset = '1' THEN
    delay_pipeline(0 TO 50) <= (OTHERS => (OTHERS => '0'));
  ELSIF rising_edge(clk) THEN
    IF clk_enable = '1' THEN
      delay_pipeline(0) <= signed(filter_in);		
      delay_pipeline(1 TO 50) <= delay_pipeline(0 TO 49);
    END IF;
  END IF;
END PROCESS Delay_Pipeline_Process ;

When you set this property to 'off', the generated code checks for clock events when operating on registers.

Delay_Pipeline_Process : PROCESS (clk, reset)
BEGIN
  IF reset = '1' THEN
    delay_pipeline(0 TO 50) <= (OTHERS => (OTHERS => '0'));
  ELSIF clk'event AND clk = '1' THEN
    IF clk_enable = '1' THEN
      delay_pipeline(0) <= signed(filter_in);
      delay_pipeline(1 TO 50) <= delay_pipeline(0 TO 49);
    END IF;
  END IF;
END PROCESS Delay_Pipeline_Process ;

The two coding styles have different simulation behavior when the clock transitions from 'X' to '1'.

When you set this property to 'on', the coder uses compiler ˋtimescale directives in generated Verilog code.

When you set this property to 'off', the coder does not include ˋtimescale directives in generated Verilog code.

The ˋtimescale directive provides a way of specifying different delay values for multiple modules in a Verilog file.

Was this topic helpful?