parameter Definition

A parameter is an attribute of a megafunction, macrofunction, design instance, or certain primitives that determines the logic created or used to implement the function, that is, a characteristic that determines the size, behavior, or silicon implementation of a function. The parameter information is used to customize the logic of the function.

A parameterized function or module is a function whose description is controlled by one or more parameters. Some logic functions, such as the functions in the library of parameterized modules (LPM), are inherently parameterized and require parameter values to be assigned. When you use an existing parameterized function, such as an LPM function, you can customize the function by assigning parameter values on an instance-by-instance basis. In a Block Design File (.bdf), you can customize an instance (that is, a symbol) using the Parameters tab in the Block Properties dialog box. In a Text Design File (.tdf), you can declare parameters and assign values when you create an instance with an Instance Declaration or an in-line logic function reference. In a VHDL Design File (.vhd), you can assign parameter values to an instance of a logic function in the Generic Map of its Component Instantiation Statement. In non-VHDL files, parameter values can be inherited from top-level entities in a project. The Compiler searches for parameter values in the parameter value search order.

The Quartus® Prime Standard Edition software allows you to assign global, project-wide default values for parameters. When you create a parameterized design file, you can specify the parameters used within that file and optional default parameter values (which are used only if no parameter values are specified elsewhere). In a Block Design File, you specify the parameters used within the current file with PARAM primitives; in a Text Design File, the parameters used within the current file are specified in a Parameters Statement; in a VHDL Design File, parameters are specified in the Generic Clause of the Entity Declaration.

A parameter name can contain up to 32 name characters. Once you create a parameterized design file, you can use the Create AHDL Include Files for Current File command, and the Create Symbol Files for Current File command to create default AHDL Function Prototypes in AHDL Include Files (.inc) and symbols in Block Symbol Files, respectively, that include the names (but not the values) of parameters used within the file. You can edit the parameters and parameter values for a Block Design File on the Parameters tab in the Symbol Properties dialog box. These parameter names and values then appear as the defaults for each instance of the symbol when it is first entered in a Block Design File. Once you enter the symbol in a Block Design File, these default parameters and values can be customized on Parameters tab in the Block Properties dialog box on an instance-by-instance basis.

The Quartus® Prime Standard Edition software allows you to assign global, project-wide default values for parameters on the Default Parameter Settings page in the Settings dialog box.

The following general guidelines apply to parameters:

Passing Parameters Between Two Design Languages

You can specify parameters for instantiated modules in your design source files, using the syntax provided for that language. Some designs instantiate entities in a different language; for example, they might instantiate a VHDL entity from a Verilog design file. You can pass parameters or generics between VHDL, Verilog HDL, AHDL, and Block Design File schematic entry, and from EDIF or VQM to any of these languages. In most cases, you do not have to do anything special to pass parameters from one language to another. However, in some cases you might have to specify the type of the parameter you are passing.

When passing a parameter between two different languages, a design block that is higher in the design hierarchy instantiates a lower-level subdesign block and provides the parameter information. It is essential that the parameter be correctly interpreted by the subdesign language (the design entity that is instantiated). It must be legal ( parsible) syntax in the language of the sub-module, for example, avoiding any reserved words and using the correct type format. Using the information provided by the higher-level design and the value format, and sometimes the parameter type of the subdesign entity, the Quartus® Prime Standard Edition software interprets the type and value of the passed parameter.

When passing a parameter whose value is an enumerated type value or literal from a language that does not support enumerated types to one that does (for example, from Verilog to VHDL), it is essential that the enumeration literal is spelled correctly in the higher-level design. The parameter value is passed as a string literal, and it is up to the language of the lower-level design to correctly interpret the string literal as the correct enumeration literal.

If the lower-level language is SystemVerilog, it is essential that the enum value is spelled in the correct case. In SystemVerilog, it is recommended that two enumeration literals don not only differ in case. For example, enum (item, ITEM) is not a good choice of item names. These names create confusion among design users and it is more difficult to pass parameters from case-insensitive HDLs, such as VHDL.

Arrays have different support in different design languages. For details about the array parameter format, refer to the Analysis & Synthesis Parameter report of a design that contains array parameters or generics.