Store 
| Products & Services | Solutions | Academia | Support | User Community | Company |
 |
|
|
|
|
|
 |
Download Product Updates | | |  |
Get Pricing | | | |
Trial Software |
| R2010b Documentation → Filter Design HDL Coder |
| Products & Services | Solutions | Academia | Support | User Community | Company |
|
|
|
|
|
|
|
Download Product Updates | | | |
Get Pricing | | | |
Trial Software |
| R2010b Documentation → Filter Design HDL Coder |
| Contents | Index |
| Learn more about Filter Design HDL Coder |
The coder includes a header comment block, such as the following, at the top of the files it generates:
-- ------------------------------------------------------------- -- -- Module: filter_tb_pkg -- -- Generated by MATLAB(R) 7.9 and the Filter Design HDL Coder 2.5. -- -- Generated on: 2009-05-11 15:34:30 -- -------------------------------------------------------------
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: filter_tb_pkg -- -- Generated by MATLAB(R) 7.9 and the Filter Design HDL Coder 2.5. -- -- Generated on: 2009-05-11 15:34:30 -- -- This module was automatically generated. -- -- -------------------------------------------------------------
To add a header comment,
Select the Global Settings tab on the Generate HDL dialog box.
Select the General tab in the Additional settings pane.
Type the comment string in the Comment in header field, as shown in the following figure.
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,
Select the Global Settings tab on the Generate HDL dialog box.
Select the General tab in the Additional settings pane.
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. |
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 _block to the second of the two matching strings.
To change the postfix string:
Select the Global Settings tab on the Generate HDL dialog box.
Select the General tab in the Additional settings pane.
Enter a new string in the Entity conflict postfix field, as shown in the following figure.
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:
Select the Global Settings tab on the Generate HDL dialog box.
Select the General tab in the Additional settings pane.
Enter a new string in the Reserved word postfix field, as shown in the following figure.
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,
Select the Global Settings tab on the Generate HDL dialog box.
Select the General tab in the Additional settings pane.
Enter a new string in the Clocked process postfix field, as shown in the following figure.
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:
Select the Global Settings tab on the Generate HDL dialog box.
Select the General tab in the Additional settings pane.
Enter a new string in the Instance prefix field, as shown in the following figure.
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_.
You can set the prefix string to a value other than vector_of_. To change the string:
Select the Global Settings tab on the Generate HDL dialog box.
Select the General tab in the Additional settings pane.
Enter a new string in the Vector prefix field, as shown in the following figure.
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,
Select the Global Settings tab on the Generate HDL dialog box.
Select the Ports tab in the Additional settings pane. The following figure highlights the port name fields for Input port, Output port, Clock input port, Reset input port, and Clock enable output port.
Enter new strings in the port name fields, as necessary
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,
Select the Global Settings tab on the Generate HDL dialog box.
Select the Ports tab in the Additional settings pane.
Select a data type from the Input data type or Output data type menu identified in the following figure.
By default, the output data type is the same as the input data type.
The type for Verilog ports is always wire, and cannot be changed.
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:
Select the Global Settings tab on the Generate HDL dialog box.
Select the Ports tab in the Additional settings pane.
Clear Add input register and Add output register as required. The following figure shows the setting for suppressing the generation of an extra input register.
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(-60, 16); -- sfix16_En16 CONSTANT coeff2: signed(15 DOWNTO 0) := to_signed(-178, 16); -- sfix16_En16
If you prefer that all constant values be represented as aggregates, set the Represent constant values by aggregates as follows:
Select the Global Settings tab on the Generate HDL dialog box.
Select the Advanced tab.
Select Represent constant values by aggregates, as shown the following figure.
The preceding constant declarations would now appear as follows:
CONSTANT coeff1: signed(15 DOWNTO 0) := (5 DOWNTO 3 => '0',1 DOWNTO 0 => '0,OTHERS =>'1'); CONSTANT coeff2: signed(15 DOWNTO 0) := (7 => '0',5 DOWNTO 4 => '0',0 => '0',OTHERS =>'1');
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,
Select the Global Settings tab on the Generate HDL dialog box.
Select the Advanced tab. The Advanced pane appears.
Select Loop unrolling, as shown in the following figure.
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 Global Settings in the Generate HDL dialog box.
Select the Advanced tab. The Advanced pane appears.
Select Use 'rising_edge' for registers, as shown in the following 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,
Select the Global Settings tab on the Generate HDL dialog box.
Select the Advanced tab. The Advanced pane appears.
Clear Inline VHDL configuration, as shown in the following figure.
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,
Select the Global Settings tab on the Generate HDL dialog box.
Select the Advanced tab. The Advanced pane appears.
Clear Concatenate type safe zeros, as shown in the following figure.
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,
Select the Global Settings tab on the Generate HDL dialog box.
Select the Advanced tab. The Advanced pane appears.
Clear Use Verilog ˋtimescale directives, as shown in the following figure.
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:
Select the Global Settings tab on the Generate HDL dialog box.
Select the Advanced tab. The Advanced pane appears.
Select Cast before sum, as shown in the following figure.
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 the Cast 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.
The coder supports use of complex coefficients and complex input signals for fully parallel FIR, CIC, and some other filter structures. In many cases, you can use complex data and complex coefficients in combination. The following table shows the filter structures that support complex data and/or coefficients, and the permitted combinations.
| Filter Structure | Complex Data | Complex Coefficients | Both Complex
Data and Coefficients |
|---|---|---|---|
| dfilt.dffir | Y | Y | Y |
| dfilt.dfsymfir | Y | Y | Y |
| dfilt.dfasymfir | Y | Y | Y |
| dfilt.dffirt | Y | Y | Y |
| dfilt.scalar | Y | Y | Y |
| dfilt.delay | Y | N/A | N/A |
| mfilt.cicdecim | Y | N/A | N/A |
| mfilt.cicinterp | Y | N/A | N/A |
| mfilt.firdecim | Y | Y | Y |
| mfilt.firinterp | Y | Y | Y |
| mfilt.firsrc | Y | Y | Y |
| mfilt.firtdecim | Y | Y | Y |
| mfilt.linearinterp | Y | N/A | N/A |
| mfilt.holdinterp | Y | Y | N/A |
| dfilt.df1sos | Y | Y | Y |
| dfilt.df1tsos | Y | Y | Y |
| dfilt.df2sos | Y | Y | Y |
| dfilt.df2tsos | Y | Y | Y |
The option you choose from the Input complexity menu instructs the coder whether or not to generate the appropriate ports and signal paths for the real and imaginary components of a complex signal. The default setting for Input complexity is Real, disabling generation of ports for complex input data. To enable generation of ports for complex input data, set Input complexity to Complex.
The corresponding command line property is InputComplex. By default, InputComplex is set to 'off', disabling generation of ports for complex input data. To enable generation of ports for complex input data, set InputComplex to 'on', as in the following code example:
Hd = design(fdesign.lowpass,'equiripple','Filterstructure','dffir'); generatehdl(Hd, 'InputComplex', 'on');
The following VHDL code excerpt shows the entity definition generated by the preceding commands:
ENTITY Hd IS
PORT( clk : IN std_logic;
clk_enable : IN std_logic;
reset : IN std_logic;
filter_in_re : IN real; -- double
filter_in_im : IN real; -- double
filter_out_re : OUT real; -- double
filter_out_im : OUT real -- double
);
END Hd;In the code excerpt, the port names generated for the real components of complex signals are identified by the default postfix string'_re', and port names generated for the imaginary components of complex signals are identified by the default postfix string '_im'.
Two code generation properties let you customize naming conventions for the real and imaginary components of complex signals in generated HDL code. These properties are:
The Complex real part postfix option (corresponding to the ComplexRealPostfix command line property) specifies a string to be appended to the names generated for the real part of complex signals. The default postfix is '_re'. See also ComplexRealPostfix.
The Complex imaginary part postfix option (corresponding to the ComplexImagPostfix command line property) specifies a string to be appended to the names generated for the imaginary part of complex signals. The default postfix is '_im'. See also ComplexImagPostfix.
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 GUI options and corresponding command-line properties that let you:
Generate an interface for loading coefficients from memory. Coefficients stored in memory are called programmable coefficients.
Test the interface.
To use programmable coefficients, a port interface (referred to as a processor interface) is 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.
If you choose one of the serial FIR filter architectures, you can also specify storage of programmable coefficients in your choice of RAM (dual-port or single-port) or register file ( See Using Programmable Coefficients with Serial FIR Filter Architectures).
Note You can also generate a processor interface for loading IIR filter coefficients. See Specifying Programmable Filter Coefficients for IIR Filters for further information. |
Programmable filter coefficients are supported for the following direct-form FIR filter types:
dfilt.dffir
dfilt.dfsymfir
dfilt.dfasymfir
Programmable filter coefficients are supported for the following FIR filter architectures:
Fully parallel
Fully serial
Partly serial
Cascade serial
If you choose one of the serial filter architectures, see Using Programmable Coefficients with Serial FIR Filter Architectures for special considerations that apply to these architectures.
This section describes how to use the CoefficientSource property to specify that a processor interface for loading coefficients is generated. You can also use the Coefficient source list on the Generate HDL dialog box for this purpose.
The valid value strings for the property are:
'Internal': (Default) Do not generate a processor interface. Coefficients are obtained from the filter object and hard-coded.
'ProcessorInterface': Generate a processor 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
write_address: Write address for coefficient memory
write_enable: Write enable signal for coefficient memory
write_done: Signal to indicate completion of coefficient write operation
Example. In the following command-line example, a processor interface is generated in VHDL code for a direct-form symmetric FIR filter with fully parallel (default) architecture.
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 ports. You can also use the Coefficient stimulus option for this purpose.
When a coefficient memory interface has been generated for a filter, all coefficient ports have associated test vectors. The TestbenchCoeffStimulus property determines how the test bench drives the coefficient 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 memory.
[coeff1, coeff2, ...coeffN]: Vector of N coefficients, where N is determined as follows:
For symmetric filters, N must equal ceil(length(filterObj.Numerator)/2).
For symmetric filters, N must equal floor(length(filterObj.Numerator)/2).
For other filters, 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 coefficient memory. The test bench also provides an example of how the memory interface can be used to program the filter with different sets of coefficients.
Note If a coefficient memory interface has not been previously generated for the filter, the TestbenchCoeffStimulus property is ignored. |
Example. In the following example, a processor interface is generated for a direct-form symmetric FIR filter with fully parallel (default) architecture. 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. Note that c is trimmed to the effective length of the filter.
b = [-0.01 0.1 0.8 0.1 -0.01]; c = [-0.03 0.5 0.7 0.5 -0.03]; c = c(1:ceil(length(c)/2)); hd = dfilt.dfsymfir(b); generatehdl(hd, 'CoefficientSource', 'ProcessorInterface'); generatetb(hd,'VHDL', 'TestbenchCoeffStimulus', c);
The following GUI options let you specify programmable coefficients:
The Coefficient source list on the Generate HDL dialog box lets you select whether coefficients are obtained from the filter object and hard-coded (Internal), or from memory (Processor interface). The default is Internal.
The corresponding command-line property is CoefficientSource (see Generating a Port Interface for Programmable FIR Coefficients).
The Coefficient stimulus option on the Test Bench pane of the Generate HDL dialog box lets you lets specify how the test bench tests the generated memory interface.
The corresponding command-line property is TestbenchCoeffStimulus (see Generating a Test Bench for Programmable FIR Coefficients).
This section discusses special considerations for using programmable filter coefficients with FIR filters that have one of the following serial architectures:
Fully serial
Partly serial
Cascade serial
Specifying Memory for Programmable Coefficients.
By default, the processor interface for programmable coefficients loads the coefficients from a register file. The Coefficient memory pulldown menu lets you specify alternative RAM-based storage for programmable coefficients.
Coefficient memory displays for FIR filters, when both the following conditions are met:
The Coefficient source option specifies Processor interface.
The Architecture option specifies a Fully serial, Partly serial, or Cascade serial architecture.
The following figure shows the Coefficient memory options for a fully serial FIR filter.
The following table summarizes the Coefficient memory options.
| Coefficient Memory Pulldown Selection | Description |
|---|---|
| Registers | default: Store programmable coefficients in a register file. |
| Single Port RAMs | Store programmable coefficients in single-port RAM. The coder writes RAM interface code to one or more separate files, depending on the filter partitioning. |
| Dual Port RAMs | Store programmable coefficients in dual-port RAM. The coder writes RAM interface code to one or more separate files, depending on the filter partitioning. |
You can also use the CoefficientMemory command-line property to specify alternative RAM-based storage for programmable coefficients. The following table summarizes the options.
| CoefficientMemory Setting | Description |
|---|---|
| 'CoefficientMemory', 'Registers' | default: Store programmable coefficients in a register file. |
| 'CoefficientMemory', 'SinglePortRAMs' | Store programmable coefficients in single-port RAM. The coder writes RAM interface code to one or more separate files, depending on the filter partitioning. |
| 'CoefficientMemory', 'DualPortRAMs' | Store programmable coefficients in dual-port RAM. The coder writes RAM interface code to one or more separate files, depending on the filter partitioning. |
The commands in the following example create an asymmetric filter Hd, and generate VHDL code for the filter using a partly serial architecture, with a dual-port RAM interface for programmable coefficients.
coeffs = fir1(22,0.45); Hd = dfilt.dfasymfir(coeffs); Hd.arithmetic = 'fixed'; generatehdl(Hd,'SerialPartition',[7 4],'CoefficientSource',... 'ProcessorInterface','CoefficientMemory','DualPortRAMs');
Tip When you use this property, be sure to set CoefficientSource to'ProcessorInterface'. The coder ignores CoefficientMemory unless it is generating an interface for programmable coefficients. |
Timing Considerations. In a serial implementation for a FIR filter, the rate of the system clock (clk) is generally a multiple of the filter's input data rate (i.e., the nominal sample rate of the filter). The exact relationship between the clock rate and the filter's data rate is determined by the choice of serial architecture and partitioning.
Programmable coefficients load into the coeffs_in port at either the system clock rate (faster) or the input data (slower) rate. If your design requires loading of coefficients at the faster rate, observe the following points:
When write_enable asserts, coefficients load from thecoeffs_in port into coefficient memory at the address specified by write_address.
write_done can assert on any clock cycle for any duration. If write_done asserts at least two clk cycles before the arrival of the next data input value, new coefficients will be applied with the next data sample. Otherwise, new coefficients will be applied for the data after the next sample.
The next two code generation examples illustrate how serial partitioning affects the timing of coefficient loading. Both examples generate code for a filter Hd. Hd is an asymmetric filter that requires 11 coefficients. The following code creates the filter Hd:
rand('state',13893);
b = rand(1,23);
Hd = dfilt.dfasymfir(b);
Hd.Arithmetic='fixed';
The following command generates VHDL code for Hd, using a partly serial architecture with the serial partition [7 4]. CoefficientSource specifies that a processor interface is generated, with the default CoefficientStimulus.
generatehdl(Hd,'SerialPartition',[7 4],'CoefficientSource', 'ProcessorInterface'); ... ### Clock rate is 7 times the input sample rate for this architecture. ### HDL latency is 2 samples
As reported by the coder, this partitioning results in a clock rate that is 7 times the input sample rate.
The following timing diagram illustrates the timing of coefficient loading relative to the timing of input data samples. While write_enable is asserted, 11 coefficient values are loaded, via coeffs_in, to 11 sequential memory addresses. On the next clk cycle, write_enable is deasserted and write_done is asserted for one clock period. The coefficient loading operation is completed within 2 cycles of data input, allowing 2 clk cycles to elapse before the arrival of the data value 07FFF. Therefore the newly loaded coefficients are applied to that data sample.
The following code generation example defines a serial partition of [6 5] for the same filter. This results in a slower clock rate, 6 times the input sample rate.
generatehdl(Hd,'SerialPartition',[6 5],'CoefficientSource', 'ProcessorInterface'); ... ### Clock rate is 6 times the input sample rate for this architecture. ### HDL latency is 2 samples
The following timing diagram illustrates that write_done deasserts too late for the coefficients to be applied to the arriving data value 278E. They are applied instead to the next sample, 7FFF.
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 IIR filters, the coder provides GUI options and corresponding command-line properties that let you:
Generate an interface for loading coefficients from memory. Coefficients stored in memory are called programmable coefficients.
Test the interface.
To use programmable coefficients, a port interface (referred to as a processor interface) is 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.
For IIR filters, the current release supports programmable coefficients that are stored in a register file.
Note You can also generate a processor interface for loading FIR filter coefficients.Specifying Programmable Filter Coefficients for FIR Filters for further information. |
The following IIR filter types support programmable filter coefficients:
Second-order section (SOS) infinite impulse response (IIR) Direct Form I (dfilt.df1sos )
SOS IIR Direct Form I transposed (dfilt.df1tsos)
SOS IIR Direct Form II (dfilt.df2sos)
SOS IIR Direct Form II transposed (dfilt.df2tsos)
This section describes how to use the CoefficientSource property to specify that a processor interface for loading coefficients 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 processor interface. Coefficients are obtained from the filter object and hard-coded.
'ProcessorInterface': Generate a processor 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
write_address: Write address for coefficient memory (See also Addressing Scheme for Loading IIR Coefficients.)
write_enable: Write enable signal for coefficient memory
write_done: Signal to indicate completion of coefficient write operation
Example. In the following command-line example, a processor interface is generated in VHDL code for an SOS IIR Direct Form II filter.
Fs = 48e3; % Sampling frequency
Fc = 10.8e3; % Cut-off frequency
N = 5; % Filter Order
f_lp = fdesign.lowpass('n,f3db',N,Fc,Fs);
Hd = design(f_lp,'butter','FilterStructure','df2sos');
Hd.arithmetic = 'fixed';
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 std_logic_vector(15 DOWNTO 0); -- sfix16_En15
write_enable : IN std_logic;
write_done : IN std_logic;
write_address : IN std_logic_vector(4 DOWNTO 0); -- ufix5
coeffs_in : IN std_logic_vector(15 DOWNTO 0); -- sfix16
filter_out : OUT std_logic_vector(15 DOWNTO 0) -- sfix16_En12
);
END Hd;This section describes how to use the TestbenchCoeffStimulus property to specify how the test bench drives the coefficient ports. You can also use the Coefficient stimulus option for this purpose.
When a coefficient memory interface has been generated for a filter, all coefficient ports have associated test vectors. The TestbenchCoeffStimulus property determines how the test bench drives the coefficient ports.
The TestBenchStimulus property determines the filter input stimuli, as with any filter.
The TestbenchCoeffStimulus specified the source of coefficients used for the test bench. The valid values for TestbenchCoeffStimulus 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 memory.
A cell array containing the following elements:
New_Hd.ScaleValues: column vector of scale values for the IIR filter
New_Hd.sosMatrix: second-order section (SOS) matrix for the IIR filter
You can specify the elements of the cell array in any of the following forms:
{New_Hd.ScaleValues , New_Hd.sosMatrix}
{New_Hd.ScaleValues ; New_Hd.sosMatrix}
{New_Hd.sosMatrix , New_Hd.ScaleValues}
{New_Hd.sosMatrix ; New_Hd.ScaleValues}
{New_Hd.ScaleValues}
{New_Hd.sosMatrix}
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 cell array, 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 register file. The test bench also provides an example of how the memory interface can be used to program the filter with different sets of coefficients.
If you omit New_Hd.ScaleValues, the test bench uses the scale values loaded from the filter object twice. Likewise, if you omit New_Hd.sosMatrix, the test bench uses the SOS matrix loaded from the filter object twice.
The following table gives the address generation scheme for the write_address port when loading IIR coefficients into memory. This addressing scheme allows all types of coefficients (scale values, numerator coefficients, and denominator coefficients) to be loaded via a single port (coeffs_in).
Note that all types of coefficients have the same word length, but may have different fractional lengths.
The address for each coefficient is divided into two fields:
Section address: Width is ceil(log2N) bits, where N is the number of sections.
Coefficient address : Width is 3 bits
The total width of the write_address port is therefore ceil(log2N) + 3bits.
| Section Address | Coefficient Address | Description |
|---|---|---|
| S S ... S | 000 | Section scale value |
| S S ... S | 001 | Numerator coefficient: b1 |
| S S ... S | 011 | Numerator coefficient: b2 |
| S S ... S | 100 | Numerator coefficient: b3 |
| S S ... S | 101 | Denominator coefficient: a2 |
| S S ... S | 110 | Denominator coefficient: a3 (if order = 2; otherwise unused) |
| S S ... S | 110 | Unused |
| 0 0 ... 0 | 111 | Last scale value |
The following GUI options let you specify programmable coefficients:
The Coefficient source list on the Generate HDL dialog box lets you select whether coefficients are obtained from the filter object and hard-coded (Internal), or from memory (Processor interface). The default is Internal.
The corresponding command-line property is CoefficientSource (see Generating a Port Interface for Programmable IIR Filter Coefficients).
The Coefficient stimulus option on the Test Bench pane of the Generate HDL dialog box lets you lets specify how the test bench tests the generated memory interface.
The corresponding command-line property is TestbenchCoeffStimulus (see Generating a Test Bench for Programmable IIR Coefficients).
 | Customizing Reset Specifications | Capturing Code Generation Settings to a Script |  |
Includes the most popular MATLAB recorded presentations with Q&A sessions led by MATLAB experts.
| © 1984-2010- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |
