| Filter Design HDL Coder™ | ![]() |
You select most HDL code customizations from options on the More HDL Settings dialog box. Options that are specific to VHDL or Verilog are active only if that language is selected. Inactive options appear gray and are not selectable. An option may also appear inactive if it is dependent on the selection of another option.
Options provided by the More HDL Settings dialog box are categorized into three tabs: General, Ports, and Advanced.
The following figure shows general options that are active for VHDL.

As shown, the Verilog file extension option is inactive due to the VHDL language selection. The Split entity file postfix and Split arch. file postfix options are inactive due to a dependency on the setting of Split entity and architecture.
The coder includes a header comment block, such as the following, at the top of the files it generates:
-- ------------------------------------------------------------- -- -- Module: Hd -- -- Generated by MATLAB(R) 7.3 and Filter Design HDL Coder 1.5. -- -- Generated on: 2006-10-19 14:34:09 -- -- -------------------------------------------------------------
You can use the Comment in header option to add a comment string, to the end of the header comment block in each generated file. For example, you might use this option to add the commentThis module was automatically generated.. With this change, the preceding header comment block would appear as follows:
-- ------------------------------------------------------------- -- -- Module: Hd -- -- Generated by MATLAB(R) 7.3 and Filter Design HDL Coder 1.5. -- -- Generated on: 2006-10-19 14:34:09 -- -- This module was automatically generated. -- -- -------------------------------------------------------------
To add a header comment,
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the General tab. General HDL coding options appear.
Type the comment string in the Comment in header field, as shown in the following figure.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property UserComment to add a comment string to the end of the header comment block in each generated HDL file.
The coder declares a filter's coefficients as constants within an rtl architecture. The coder derives the constant names adding the prefix coeff to the following:
| For... | The Prefix Is Concatenated with... |
|---|---|
| FIR filters | Each coefficient number, starting with 1. Examples: coeff1, coeff22 |
| IIR filters | An underscore (_) and an a or b coefficient name (for example, _a2, _b1, or _b2) followed by the string _sectionn, where n is the section number. Example: coeff_b1_section3 (first numerator coefficient of the third section) |
For example:
ARCHITECTURE rtl OF Hd IS -- Type Definitions TYPE delay_pipeline_type IS ARRAY(NATURAL range <>) OF signed(15 DOWNTO 0);-- sfix16_En15 CONSTANT coeff1 : signed(15 DOWNTO 0) := to_signed(-30, 16); -- sfix16_En15 CONSTANT coeff2 : signed(15 DOWNTO 0) := to_signed(-89, 16); -- sfix16_En15 CONSTANT coeff3 : signed(15 DOWNTO 0) := to_signed(-81, 16); -- sfix16_En15 CONSTANT coeff4 : signed(15 DOWNTO 0) := to_signed(120, 16); -- sfix16_En15
To use a prefix other than coeff,
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the General tab.
Enter a new string in the Coefficient prefix field, as shown in the following figure.

The string that you specify
Must start with a letter
Cannot end with an underscore (_)
Cannot include a double underscore (__)
Note If you specify a VHDL or Verilog reserved word, the coder appends a reserved word postfix to the string to form a valid identifier. If you specify a prefix that ends with an underscore, the coder replaces the underscore character with under. For example, if you specify coef_, the coder generates coefficient names such as coefunder1. |
Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property CoeffPrefix to change the base name for filter coefficients.
The coder checks whether multiple entities in VHDL or multiple modules in Verilog share the same name. If a name conflict exists, the coder appends the postfix _entity to the second of the two matching strings.
To change the postfix string:
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the General tab.
Enter a new string in the Entity conflict postfix field, as shown in the following figure.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property EntityConflictPostfix to change the entity or module conflict postfix string.
The coder checks whether any strings that you specify as names, postfix values, or labels are VHDL or Verilog reserved words. See Reserved Word Tables for listings of all VHDL and Verilog reserved words.
If you specify a reserved word, the coder appends the postfix _rsvd to the string. For example, if you try to name your filter mod, for VHDL code, the coder adds the postfix _rsvd to form the name mod_rsvd.
To change the postfix string:
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the General tab.
Enter a new string in the Reserved word postfix field, as shown in the following figure.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property ReservedWordPostfix to change the reserved word postfix string.
The following tables list all VHDL and Verilog reserved words.
VHDL Reserved Words
| abs | access | after | alias | all |
| and | architecture | array | assert | attribute |
| begin | block | body | buffer | bus |
| case | component | configuration | constant | disconnect |
| downto | else | elsif | end | entity |
| exit | file | for | function | generate |
| generic | group | guarded | if | impure |
| in | inertial | inout | is | label |
| library | linkage | literal | loop | map |
| mod | nand | new | next | nor |
| not | null | of | on | open |
| or | others | out | package | port |
| postponed | procedure | process | pure | range |
| record | register | reject | rem | report |
| return | rol | ror | select | severity |
| signal | shared | sla | sll | sra |
| srl | subtype | then | to | transport |
| type | unaffected | units | until | use |
| variable | wait | when | while | with |
| xnor | xor |
Verilog Reserved Words
| always | and | assign | automatic | begin |
| buf | bufif0 | bufif1 | case | casex |
| casez | cell | cmos | config | deassign |
| default | defparam | design | disable | edge |
| else | end | endcase | endconfig | endfunction |
| endgenerate | endmodule | endprimitive | endspecify | endtable |
| endtask | event | for | force | forever |
| fork | function | generate | genvar | highz0 |
| highz1 | if | ifnone | incdir | include |
| initial | inout | input | instance | integer |
| join | large | liblist | library | localparam |
| macromodule | medium | module | nand | negedge |
| nmos | nor | noshowcancelled | not | notif0 |
| notif1 | or | output | parameter | pmos |
| posedge | primitive | pull0 | pull1 | pulldown |
| pullup | pulsestyle_onevent | pulsestyle_ondetect | rcmos | real |
| realtime | reg | release | repeat | rnmos |
| rpmos | rtran | rtranif0 | rtranif1 | scalared |
| showcancelled | signed | small | specify | specparam |
| strong0 | strong1 | supply0 | supply1 | table |
| task | time | tran | tranif0 | tranif1 |
| tri | tri0 | tri1 | triand | trior |
| trireg | unsigned | use | vectored | wait |
| wand | weak0 | weak1 | while | wire |
| wor | xnor | xor |
The coder generates process blocks to modify the content of a filter's registers. The label for each of these blocks is derived from a register name and the postfix _process. For example, the coder derives the label delay_pipeline_process in the following block from the register name delay_pipeline and the postfix string _process.
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;
You can of set the postfix string to a value other than _process. For example, you might change it to _clkproc. To change the string,
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the General tab.
Enter a new string in the Clocked process postfix field, as shown in the following figure.

Click Apply to register the change, or click OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property ClockProcessPostfix to change the postfix string appended to process labels.
Instance prefix specifies a string to be prefixed to component instance names in generated code. The default string is u_.
You can of set the postfix string to a value other than u_. To change the string:
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the General tab.
Enter a new string in the Instance prefix field, as shown in the following figure.

Click Apply to register the change, or click OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property InstancePrefix to change the instance prefix string.
Vector prefix specifies a string to be prefixed to vector names in generated VHDL code. The default string is vector_of_.
Note VectorPrefix is supported only for VHDL code generation. |
You can of set the postfix string to a value other than vector_of_. To change the string:
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the General tab.
Enter a new string in the Vector prefix field, as shown in the following figure.

Click Apply to register the change, or click OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property VectorPrefixto change the instance prefix string.
The default names for filter HDL ports are as follows:
| HDL Port | Default Port Name |
|---|---|
| Input port | filter_in |
| Output port | filter_out |
| Clock port | clk |
| Clock enable port | clk_enable |
| Reset port | reset |
| Fractional delay port (Farrow filters only) | filter_fd |
For example, the default VHDL declaration for entity Hd looks like the following.
ENTITYHd IS
PORT( clk : IN std_logic;
clk_enable : IN std_logic;
reset : IN std_logic;
filter_in : IN std_logic_vector (15 DOWNTO 0); -- sfix16_En15
filter_out : OUT std_logic_vector (15 DOWNTO 0); -- sfix16_En15
);
ENDHd;To change any of the port names,
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the Ports tab. Port options appear, as shown in the following figure.

Enter new strings in the following fields, as necessary:
Input port
Output port
Clock port
Clock enable port
Reset input port
Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the properties InputPort, OutputPort, ClockInputPort, ClockEnableInputPort, and ResetInputPort to change the names of a filter's VHDL ports.
By default, filter input and output data ports have data type std_logic_vector in VHDL and type wire in Verilog. If you are generating VHDL code, alternatively, you can specify signed/unsigned, and for output data ports, Same as input data type. The coder applies type SIGNED or UNSIGNED based on the data type specified in the filter design.
To change the VHDL data type setting for the input and output data ports,
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the Ports tab. Port options appear.
Select a data type from the Input data type or Output data type menu identified in the following figure. The type for Verilog ports is always wire.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the properties InputType and OutputType to change the VHDL data type for a filter's input and output ports.
The coder adds an extra input register (input_register) and an extra output register (output_register) during HDL code generation. These extra registers can be useful for timing purposes, but they add to the filter's overall latency. The following process block writes to extra output register output_register when a clock event occurs and clk is active high (1):
Output_Register_Process : PROCESS (clk, reset)
BEGIN
IF reset = '1' THEN
output_register <= (OTHERS => '0');
ELSIF clk'event AND clk = '1' THEN
IF clk_enable = '1' THEN
output_register <= output_typeconvert;
END IF;
END IF;
END PROCESS Output_Register_Process;
If overall latency is a concern for your application and you have no timing requirements, you can suppress generation of the extra registers as follows:
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the Ports tab. Port options appear.
Clear Add input register and Add output register per your requirements. The following figure shows the setting for suppressing the generation of an extra input register.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the properties AddInputRegister and AddOutputRegister to add an extra input or output register.
By default, the coder represents constants as scalars or aggregates depending on the size and type of the data. The coder represents values that are less than 232 – 1 as integers and values greater than or equal to 232 – 1 as aggregates. The following VHDL constant declarations are examples of declarations generated by default for values less than 32 bits:
CONSTANT coeff1 :signed(15 DOWNTO 0) := to_signed(-30, 16); CONSTANT coeff2 :signed(15 DOWNTO 0) := to_signed(-89, 16);
If you prefer that all constant values be represented as aggregates, set the Represent constant values by aggregates as follows:
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the Advanced tab. The Advanced pane appears.
Select Represent constant values by aggregates, as shown the following figure.

Click Apply to register the change or OK to register the change and close the dialog box.
The preceding constant declarations would now appear as follows:
CONSTANT coeff1 :signed(15 DOWNTO 0) := (4 DOWNTO 2 => '0', 0 =>'0', OTHERS => ', '); -- sfix16_En15 CONSTANT coeff2 :signed(15 DOWNTO 0) := (6 => '0', 4 DOWNTO 3 => '0', OTHERS => ', '); -- sfix16_En15
Command Line Alternative: Use the generatehdl and generatetb functions with the property UseAggregatesForConst to represent all constants in the HDL code as aggregates.
By default, the coder supports VHDL loops. However, some EDA tools do not support them. If you are using such a tool along with VHDL, you might need to unroll and remove FOR and GENERATE loops from your filter's generated VHDL code. Verilog code is always unrolled.
To unroll and remove FOR and GENERATE loops,
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the Advanced tab. The Advanced pane appears.
Select Loop unrolling, as shown in the following figure.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property LoopUnrolling to unroll and remove loops from generated VHDL code.
The coder can generate two styles of VHDL code for checking for rising edges when the filter operates on registers. By default, the generated code checks for a clock event, as shown in the ELSIF statement of the following VHDL process block.
Delay_Pipeline_Process : PROCESS (clk, reset)
BEGIN
IF reset = '1' THEN
delay_pipeline(0 TO 50) <= (OTHERS => (OTHERS => '0'));
ELSEIF 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 ;
If you prefer, the coder can produce VHDL code that applies the VHDL rising_edge function instead. For example, the ELSIF statement in the preceding process block would be replaced with the following statement:
ELSIF rising_edge(clk) THEN
To use the rising_edge function,
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the Advanced tab. The Advanced pane appears.
Select Use 'rising_edge' for registers, as shown in the following dialog box.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property UseRisingEdge to use the VHDL rising_edge function to check for rising edges during register operations.
VHDL configurations can be either inline with the rest of the VHDL code for an entity or external in separate VHDL source files. By default, the coder includes configurations for a filter within the generated VHDL code. If you are creating your own VHDL configuration files, you should suppress the generation of inline configurations.
To suppress the generation of inline configurations,
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the Advanced tab. The Advanced pane appears.
Clear Inline VHDL configuration, as shown in the following figure.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property InlineConfigurations to suppress the generation of inline configurations.
In VHDL, the concatenation of zeros can be represented in two syntax forms. One form, '0' & '0', is type safe. This is the default. The alternative syntax, "000000...", can be easier to read and is more compact, but can lead to ambiguous types.
To use the syntax "000000..." for concatenated zeros,
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the Advanced tab. The Advanced pane appears.
Clear Concatenate type safe zeros, as shown in the following figure.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property SafeZeroConcat to use the syntax "000000...", for concatenated zeros.
In Verilog, the coder generates time scale directives (ˋtimescale) , as appropriate, by default. This compiler directive provides a way of specifying different delay values for multiple modules in a Verilog file.
To suppress the use of ˋtimescale directives,
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the Advanced tab. The Advanced pane appears.
Clear Use Verilog ˋtimescale directives, as shown in the following figure.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property UseVerilogTimescale to suppress the use of time scale directives.
By default, generated HDL code operates on input data using data types as specified by the filter design, and then converts the result to the specified result type.
Typical DSP processors type cast input data to the result type before operating on the data. Depending on the operation, the results can be very different. If you want generated HDL code to handle result typing in this way, use the Cast before sum option as follows:
Click More HDL Settings in the Filter settings pane of the Generate HDL dialog box. The More HDL Settings dialog box appears.
Select the Advanced tab. The Advanced pane appears.
Select Cast before sum, as shown in the following figure.

Click Apply to register the change or OK to register the change and close the dialog box.
Command Line Alternative: Use the generatehdl and generatetb functions with the property CastBeforeSum to cast input values to the result type for addition and subtraction operations.
The Cast before sum property is related to the FDATool setting for the quantization property Cast signals before accum. as follows:
Some filter object types do not have theCast signals before accum. property. For such filter objects, Cast before sum is effectively off when HDL code is generated; it is not relevant to the filter.
Where the filter object. does have the Cast signals before accum. property, the coder by default follows the setting of Cast signals before accum. in the filter object. This is visible in the GUI. If the you change the setting of Cast signals before accum., the coder updates the setting of Cast before sum.
However, by explicitly setting Cast before sum, you can override the Cast signals before accum. setting passed in from FDATool.
By default, the coder obtains filter coefficients from a filter object and hard-codes them into the generated code. An HDL filter realization generated in this way cannot be used with a different set of coefficients.
For direct-form FIR filters, the coder provides two GUI options and corresponding command-line properties that let you generate a RAM or register file interface for loading coefficients, and test the interface.
The GUI options, shown in the figures below are:
The Coefficient source menu on the Generate HDL dialog box lets you select whether coefficients are obtained from the filter object and hard-coded (Internal), or from a generated RAM interface (Processor interface) The default is Internal. The corresponding command line property is CoefficientSource. See Generating a RAM Port Interface for Coefficients for detailed information.

The Coefficient stimulus on the More Test Bench Settings dialog box lets you lets specify how the test bench tests the generated RAM or register file interface. The corresponding command line property is TestbenchCoeffStimulus. See Generating a Test Bench for RAM Coefficients for detailed information.

The following discussion refers to generated RAM or register file storage generically, as RAM.
When you specify storage of FIR filter coefficients to RAM, coefficients are stored via a port interface generated for the filter entity or module. Coefficient loading is assumed to be under the control of a microprocessor that is external to the generated filter. The filter uses the loaded coefficients for processing input samples.
To generate storage of filter coefficients in RAM, the filter must meet the following requirements:
The filter must be one of the following direct-form FIR filter types:
dfilt.dffir
dfilt.dfsymfir
dfilt.dfasymfir
The filter must have a fully parallel architecture. (This is the default architecture.)
This section describes how to use the CoefficientSource property to specify whether a processor interface for loading coefficients in RAM is generated. You can also use the Coefficient source menu on the Generate HDL dialog box for this purpose.
The valid value strings for the property are:
'Internal': (Default) Do not generate a RAM port interface. Coefficients are obtained from the filter object and hard-coded.
'ProcessorInterface': Generate a RAM port interface for coefficients.
When you specify 'ProcessorInterface', the generated entity or module definition for the filter includes the following port definitions:
coeffs_in: Input port for coefficient data
wr_addr: Write address for the RAM
wr_en: Write enable signal for RAM
wr_done: Signal to indicate completion of coefficient write operation
Example. In the following command-line example, a RAM interface is generated in VHDL code for a direct-form symmetric FIR filter.
Hd = design(fdesign.lowpass, 'equiripple', 'FilterStructure', 'dfsymfir'); generatehdl(Hd, 'CoefficientSource', 'ProcessorInterface')
The following listing shows the VHDL entity definition generated for the filter object Hd.
ENTITY Hd IS
PORT( clk : IN std_logic;
clk_enable : IN std_logic;
reset : IN std_logic;
filter_in : IN real; -- double
write_enable : IN std_logic;
write_done : IN std_logic;
write_address : IN real; -- double
coeffs_in : IN real; -- double
filter_out : OUT real -- double
);
END Hd;This section describes how to use the TestbenchCoeffStimulus property to specify how the test bench drives the coefficient RAM ports. You can also use the Coefficient stimulus option on the More Test Bench Options dialog box for this purpose.
When a coefficient RAM interface has been generated for a filter, all RAM ports (wr_en, wr_addr, coeff_addr, and coeff_in) have associated test vectors. The TestbenchCoeffStimulus property determines how the test bench drives the coefficient RAM ports.
The TestBenchStimulus property determines the filter input stimuli, as with any filter.
The TestbenchCoeffStimulus property selects from two types of test benches. TestbenchCoeffStimulus takes a vector argument. The valid values are:
[] : Empty vector.
This is the default. When the value of TestbenchCoeffStimulus is unspecified (or set to the default value of[]). the test bench loads the coefficients from the filter object and then forces the input stimuli. This shows the response to the input stimuli and verifies that the interface correctly writes one set of coefficients into the RAM.
[coeff1 ,coeff2, ...coeffN]: Vector of N coefficients.
N must equal the length of the filter object. In this case, the filter processes the input stimuli twice. First, the test bench loads the coefficients from the filter object and forces the input stimuli to show the response. Then, the filter loads the set of coefficients specified in the TestbenchCoeffStimulus vector, and shows the response by processing the same input stimuli for a second time. In this case, the internal states of the filter, as set by the first run of the input stimulus, are retained. The test bench verifies that the interface writes two different sets of coefficients into the RAM. The test bench also provides an example of how the RAM interface can be used to program the filter with different sets of coefficients.
Note If a coefficient RAM interface has not been previously generated for the filter, the TestbenchCoeffStimulus property is ignored. |
Example. In the following example, a RAM interface is generated in VHDL code for a direct-form symmetric FIR filter. The coefficients for the filter object are defined in the vector b. Test bench code is then generated, using a second set of coefficients defined in the vector c.
b = [-0.01 0.1 0.8 0.1 -0.01]; c = [-0.03 0.5 0.7 0.5 -0.03]; hd = dfilt.dfsymfir(b); generatehdl(hd, 'CoefficientSource', 'ProcessorInterface'); generatetb(hd,'VHDL', 'TestbenchCoeffStimulus', c);
Demo. For a detailed demo of the generation of a processor interface to coefficient RAM, see the HDL Programmable FIR Filter demo (hdlprogramcoeffs.m).
![]() | Customizing Reset Specifications | Capturing Code Generation Settings to an M-File | ![]() |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |