« Prev | Next » Block-level design constraints in ALINT-PRO Introduction This application note demonstrates how block-level constraints can be used to describe behavioral non-synthesizable design cells, representing vendor-specific primitives, blocks with analog implementation, and IP cores treated as black boxes - to provide high quality linting results in ALINT-PRO. The source code of the examples used in the article can be downloaded here. The file contains a single workspace with multiple projects. The ADC_components library project contains the definition of all components used in this article together with the constraints. All other projects depend on the ADC_components library project and use components from it. Projects from the workspace are referenced later in these instructions. Block-level design constraints Block-level design constraints are a set of TCL commands that describe various properties of design units, which are significant for linting and CDC analysis. This kind of description overrides (or replaces missing) HDL description, and is used to provide additional data to the tool in case it is not possible to extract it directly from the HDL code. Constraints commands are used to describe encrypted IP modules, non-synthesizable and behavioral descriptions, black boxes, and custom synchronization cells. Block-level design constraints are applied to the design units from the current library, and cannot modify contents of attached libraries, global libraries or project libraries of other projects. Constraint commands should be specified in the *.adc files and added to the project as regular source files. Block-level constraints can be divided into two groups: Block-level getters - the commands are used to retrieve information about library cells or pins. This includes: get_libs, get_lib_pins, get_lib_cells, get_lib_cell_paths. Block-level setters - the commands are used to specify characteristics of a design unit. This includes: set_cell, set_pin, create_cell_clock, create_generated_cell_clock, set_input_cell_delay, set_output_cell_delay, create_lib_cell_path. Port and cell roles The most common usage of the block-level constraints is to specify cell and pin roles for a given cell. The cell role is used by different algorithms that analyze the entire cell. For example, a rule checker, which prevents instantiation of any logic except I/O cells and clock buffers at the top level, will refer to cell type to perform the check. The role can be specified using set_cell command: set_cell [-kind <cell_kind>] [-function <lib_function>] <lib_cells_pattern> [-if <boolean_condition>] [-f <list_file>] The command accepts the -kind <cell_kind> argument to define a cell's role, and the output of the get_lib_cells (<lib_cells_pattern>) to select lib cells to which the new role should be assigned to. There are also two optional arguments: -if - specifies a conditional expression for when the constraint should be applied (see the Generic Dependent Constraints for additional details), and -f - a common argument that specifies the file with additional arguments to the command. The -f and -if are common arguments shared by all constraint commands. Let's consider the IBUF cell from the ADC_componets library: entity IBUF is port ( data_in: in std_logic_vector(7 downto 0); data_out: out std_logic_vector(7 downto 0) ); end entity IBUF; To assign the inout_pad role use the following set_cell command: set_cell -kind inout_pad [get_lib_cells ADC_components/IBUF] Now, this cell will be properly recognized as an input pad by the ALINT-PRO engine during the linting, if instantiated in the design. The -kind argument can accept a number of cell types, like flip-flop, latch, multiplexer and several others. However, specifying only a cell type is not enough for such components to be properly handled during the analysis, because it is important to declare explicit intent on the pins of the cell, and the timing dependencies between those pins. Let's assume we are going to describe a flip-flop, which resides in the ADC_componets library: entity FF is port ( clk: in std_logic; rst: in std_logic; data: in std_logic; Q: out std_logic ); So, first, we'll assign the flip-flop role using the set_cell command: set_cell -kind flip-flop [get_lib_cells ADC_components/FF] Now, we have to describe all the pins of the flip-flop. This can be done using the set_pin command: set_pin [-kind <pin_kind>] [-function <lib_function>] [-polarity <signal_polarity> | -level <signal_level>] <lib_pins_pattern> [-if <boolean_condition>] [-f <list_file>] The command accepts the -kind argument to specify the cell's kind. Optional arguments are: -polarity (used to specify polarity for control signals) and -level (used when some output pin is constantly driven by the value). The command also accepts the output of the get_lib_pins (<lib_pins_pattern>) command, which defines pins to work with. These arguments allow constraining all pins independently from each other. We create the following constraints to describe pins of this particular flip-flop cell: set_pin -kind async-reset -polarity active-high [get_lib_pins ADC_components/FF/rst] set_pin -kind input [get_lib_pins ADC_components/FF/data] set_pin -kind output [get_lib_pins ADC_components/FF/Q] These commands describe all pins of the flip-flop except the clk pin. To describe clock pins the create_cell_clock constraint should be used: create_cell_clock [-edge <signal_edge>] [-name <clock_name>] <source_objects> [-if <boolean_condition>] [-f <list_file>] The command accepts -edge (specifies clock edge and can be rising or falling), -name (specifies clock name and can be used for referencing from the create_generated_cell_clock command) and output of the get_lib_pins constraint (defines clock pins). For the out flip-flop, the constraint will look like the following: create_cell_clock -edge rising [get_lib_pins ADC_components/FF/clk] So now, as we have added a description for the custom flip-flop cell, it will be properly recognized by ALINT-PRO engine during the linting, if instantiated within the design's hierarchy. Please refer to the ADC_components library project for the full description of the component. Figure 1. The constrained elements. There is an alternative shorter syntax to describe some of the simplest cells (such as flip-flop, multiplexer, combinational gate, etc.) using a single command. The simplification can be achieved using special higher level block-level constraints commands called "library functions", which are used to form an expression of input pins of a particular library cell. The library function is associated with corresponding output pin of the cell using the -function argument. Relationships between input and output pins specified in this way provide more accurate design analysis results because combinational paths can be properly handled during detection of clock gating schemes, DFT checks, etc. Additionally, the cell type can be deduced from the library function. For simple cells this is a preferable description style because library functions provide more information to the tool. For our flip-flop description the following constraint can be used instead of the earlier version: set_pin -kind output -function [lib_dff \ -in [get_lib_pins ADC_components/FDR/data] \ -clr [get_lib_pins ADC_components/FDR/rst] \ -clock [get_lib_pins ADC_components/FDR/clk]] \ [get_lib_pins ADC_components/FDR/Q] All control pins obtain active-high polarity when described in this manner. I.e., to switch to a clock pin with falling edge the create_cell_clock command should be invoked for the clock pin additionally to the set_pin constraint with -function argument. Now let's try analyzing the project, which uses these components. The ADC_constrained_elements contains two cells: FDR, which is properly constrained, and FF_EMPTY, which is not constrained. Data is being sent from one cell to the other and different clocks are applied to the cells. To run the analysis, do the following: Run the ADC_constrained_elements project - click the Run button from the context menu in the Project Manager on the ADC_constrained_elements node (the ADC_components library project is set as dependent on the ADC_constrained_elements one and will be run first) Open RTL Schematic window - click the Show RTL Schematic button from the context menu in the Project Manager on the ADC_constrained_elements node The above actions will bring you an RTL Schematic with the scheme represented on Figure 1. As you can see, entered constraints affect components representation in the RTL Schematic - the uFF instance of the FDR component is displayed as a flip-flop. And the FF_EMPTY cell is displayed as a black box. If you navigate to Violation Viewer (to open Violation Viewer, click the View | Linting Windows | Violation Viewer button from the main menu or choose Alt+7), you will see the following violations detected for the ADC_constrained_elements project (Figure 2). Figure 2. The violations detected in the ADC_constrained_elements project. To receive violations on a CDC path between the flip-flops from asynchronous clock domains, constraints should be added to the second cell as well. There is the ADC_crossings project in the workspace. It has the same structure as the ADC_constrained_elements project, but the second cell is constrained. If you run an analysis of the ADC_crossings project and open the Violation Viewer, you'll see that now there are extra violations reported on non-synchronized crossing between clock domains (Figure 3). Not only is a new CDC path detected and reported as unsynchronized, but also the number of automatically detected clocks has increased (violation of rule ALDEC_CDC.3.1) simply because the clock extraction algorithm now can take another valid clock endpoint, the uFFB flip-flop, into account. Also, violations of the ALDEC_CDC.1.10 indicate that an asynchronous reset is now connected without de-assertion synchronization to two control pins of flip-flops from different domains. Figure 3. More violations reported on properly constrained cells. Generated clocks Another application for the design constraints is description of clock generators - e.g. cells that accept a clock, referred to as master clock, and generate another clock, referred to as generated clock, as an output. To constrain this output clock the create_generated_cell_clock command should be used: create_generated_cell_clock -source <master_source> | -master_clock <cell_clock_name> [-divide_by <divide_by>] [-multiply_by <multiply_by>] [-phase_shift <phase_shift>] [-name <name>] [-invert] [-combinational] <source_objects> [-if <boolean_condition>] [-f <list_file>] The command accepts -source and -master_clock arguments to specify the master clock pin or master clock name. The -multiply_by and -divide_by arguments allow setting frequency changes of the generated clock, the -invert argument defines a clock with the inverted phase, and the -combinational argument defines a clock with the same frequency/phase as a the master clock, the -phase_shift argument specifies difference in phase between master and generated clocks, and the -name argument specifies the name of the generated clock. Let's assume that we have the following clock generator: entity CLK_GEN is generic ( DIVA : integer := 2; DIVB : integer := 2 ); port ( CLK: in std_logic; CLK_OUT: out std_logic; CLK_OUT_DIVA: out std_logic; CLK_OUT_DIVB: out std_logic ); end entity CLK_GEN; This component has one input clock and three generated clocks, there are also two generic values, which define the frequency of the generated clocks. First, we should define the cell role, in our case it is a clock generator, this can be done with the set_cell command: set_cell -kind clock_generator [get_lib_cells ADC_components/CLK_GEN] Now we have to define the input clock, we can do it with the help of create_cell_clock_command: create_cell_clock -edge falling [get_lib_pins ADC_components/CLK_GEN/CLK] Once the main clock is defined we can proceed to creating the generated clocks. First clock output (CLK_OUT) is a clock with the same frequency, to define such a clock, we should use the -combinational argument: create_generated_cell_clock -combinational -source [get_lib_pins ADC_components/CLK_GEN/CLK] \ [get_lib_pins ADC_components/CLK_GEN/CLK_OUT] Here we specify the pin of the master clock in the source argument and the pin of the generated clock as a value without argument. The actual frequency of the two other clocks depends on the generic value. To define such clocks, we'll have to specify an expression as a value of -divide_by argument. The expression should follow regular TCL syntax and have to be written in curly brackets (the '{' and '}' characters). Generic variables can be referenced by their name with the preceding dollar sign. In our example the expressions are simple - just the generic value itself, so we'll use the following description: create_generated_cell_clock -divide_by {$DIVA} -source [get_lib_pins ADC_components/CLK_GEN/CLK] \ [get_lib_pins ADC_components/CLK_GEN/CLK_OUT_DIVA] create_generated_cell_clock -divide_by {$DIVB} -source [get_lib_pins ADC_components/CLK_GEN/CLK] \ [get_lib_pins ADC_components/CLK_GEN/CLK_OUT_DIVB] The above constraints are enough to describe the clock generator cell for correct linting. There is an ADC_generator_unconstrained project in the workspace. This project contains a clock generator cell, which drives two flip-flops with different clocks (Figure 4). Figure 4. The unconstrained clock generator cell. ALINT-PRO automatically detects clock and resets used in the design. To view the detected clocks, do the following: Set the ADC_generator_unconstrained project as an active project - click the Set Project as Active button from the context menu in the Project Manager on the ADC_generator_unconstrained node Run the ADC_generator_unconstrained project - click the Run button from the context menu in the Project Manager on the ADC_constrained_elements node (the ADC_components library project is set as dependent on the ADC_constrained_elements one and will be run first) Open Clocks and Resets Viewer - click the View | Netlist Windows | Clocks and Resets Viewer button from the main menu or choose Alt+5. In the Clocks and Resets Viewer, you'll see that ALINT-PRO detected two clocks (Figure 5). The detected clock tree is not ideal: first - the detected clocks are separate clocks, and second - no clocks are detected for the TOP/clk port. Figure 5. The detected clocks with unconstrained clock generator. To improve auto-detect results, we should specify constraints for the clock generator cell. There is the ADC_generator project, which has the same structure as ADC_generator_unconstrained project with only one difference - the clock generator cell is described with constraints. If you run the analysis and open Clocks and Resets Viewer, you'll see that now four clocks are detected (Figure 6): master clock - TOP/clk, and three generated clocks - TOP/clka, TOP/clkb, and TOP/uCLK_GEN/CLK_OUT. The TOP/uCLK_GEN/CLK_OUT clock is not connected to any clock pin so there in no clock path under the TOP/uCLK_GEN/CLK_OUT node in the Clocks and Resets Viewer tree. So, we see that the detected clock tree is correct and correct linting results can be obtained. Figure 6. The detected clocks with constrained clock generator. Detected clocks can be saved in the *.adc file with the help of the save_all_clocks command. The command will save constraints to the main.adc file attached to the ADC_generator project and is specified in the Save constraints commands to: option of the project Properties. After saving constraints you'll receive the following records for clocks: create_clock -period 10 -name TOP/clk [ get_ports TOP/clk ] create_generated_clock -source [ get_ports TOP/clk ] -combinational -name TOP/uCLK_GEN/CLK_OUT [ get_pins TOP/uCLK_GEN/CLK_OUT ] create_generated_clock -source [ get_ports TOP/clk ] -divide_by 2 -name TOP/clka [ get_pins TOP/uCLK_GEN/CLK_OUT_DIVA ] create_generated_clock -source [ get_ports TOP/clk ] -divide_by 7 -name TOP/clkb [ get_pins TOP/uCLK_GEN/CLK_OUT_DIVB ] So, we see, that generic values, supplied in the HDL code, were recognized by the engine and are inserted in the description of the generated clocks. Describing Cells with Multiple Clocks It is possible that a single cell receives multiple clocks and its pins depend on different clocks. To handle such a situation, there are set_input_cell_delay and set_output_cell_delay constraints: set_input_cell_delay -clock <cell_clock_name> -reference_pin <lib_pin> [-add_delay] <objects> [-if <boolean_condition>] [-f <list_file>] set_output_cell_delay -clock <cell_clock_name> -reference_pin <lib_pin> [-add_delay] <objects> [-if <boolean_condition>] [-f <list_file>] These constraints accept the clock name (-clock argument) or clock pin name (-reference_pin argument) and output of the get_lib_cells command (<objects>). Once executed, the command informs the ALINT-PRO engine that these pins are sampled/driven by the specified clock. Let's consider a simple dual clock bus: entity SD_BUS is port ( clk_tx : in std_logic; clk_rx : in std_logic; data_in : in std_logic_vector(31 downto 0); ctrl : in std_logic_vector(7 downto 0); data_out : out std_logic_vector(31 downto 0) ); end entity SD_BUS; All pins should be described with create_cell_clock and set_pin constraints as shown above. In addition, set_input_cell_delay/set_output_cell_delay constraints should be specified for each non-clock pin of the cell. In our case, the constraints might look like this: # Bus Inputs set_input_cell_delay -reference_pin [get_lib_pins ADC_components/SD_BUS/clk_tx] [get_lib_pins ADC_components/SD_BUS/data_in] set_input_cell_delay -reference_pin [get_lib_pins ADC_components/SD_BUS/clk_tx] [get_lib_pins ADC_components/SD_BUS/ctrl] # Bus Output set_output_cell_delay -reference_pin [get_lib_pins ADC_components/SD_BUS/clk_rx] [get_lib_pins ADC_components/SD_BUS/data_out] When such constraints are defined for the cell and the data connected to the pin and the pin itself are controlled by different clocks, then a violation will be reported. You can run the ADC_bus project to examine violations reported on such cells. The project contains an SD_RAM instance with all its inputs and outputs driven by the flip-flops, one of them is controlled by a wrong clock (Figure 7). Figure 7. The detected CDC path that starts from a properly constrained dual-clock bus. There are special shortcuts for frequently occurring dual-clock components, such as RAMs and asynchronous FIFOs. The following library functions are provided for user convenience: lib_ram and lib_async_fifo. These library functions should be used as an expression for the -function argument of the set_cell command. In this case not only the cell type but also dependencies between clocks and other I/O can be deduced and there is no need to specify set_input_cell_delay and set_output_cell_delay constraints. Let's take a look on the RAM cell: entity RAM is port ( clka : in std_logic; addra : in std_logic_vector(5 downto 0); dataa : in std_logic_vector(7 downto 0); qa : out std_logic_vector(7 downto 0); clkb : in std_logic; addrb : in std_logic_vector(5 downto 0); datab : in std_logic_vector(7 downto 0); qb : out std_logic_vector(7 downto 0) ); end entity RAM; Write and read interfaces of the RAM should be described separately using the lib_interface library function. All non-clock ports of the interface are set to be dependent on the interface clock. set_cell -function [lib_ram \ [lib_interface \ -clock [get_lib_pins ADC_components/RAM/clka] \ -in [get_lib_pins ADC_components/RAM/dataa] \ -addr [get_lib_pins ADC_components/RAM/addra] \ -out [get_lib_pins ADC_components/RAM/qa]] \ [lib_interface \ -clock [get_lib_pins ADC_components/RAM/clkb] \ -in [get_lib_pins ADC_components/RAM/datab] \ -addr [get_lib_pins ADC_components/RAM/addrb] \ -out [get_lib_pins ADC_components/RAM/qb]]] \ [get_lib_cells ADC_components/RAM] The ADC_RAM project contains a RAM instance with all its inputs and outputs driven by the flip-flops, which are controlled by a wrong clock domain (Figure 8). Run the project to examine the reported violations. Figure 8. The detected CDC paths that start and end with a properly constrained RAM cell. Generic Dependent Constraints It is possible that some design constraints will be valid only under certain values of generics/parameters. For example, the specific pin may play a role of an asynchronous or synchronous reset depending on the value of a generic. To cover such a situation, the -if argument should be used. This argument takes a TCL expression as a parameter. The generic values can be referenced by the preceding dollar character '$' before the generic name. In the following example, there is a flip-flop with the ASYNC_RESET generic which controls if synchronous or asynchronous reset is inferred on the rst pin: entity FF_GENERIC is generic ( ASYNC_RESET: boolean := true ); port ( clk: in std_logic; rst: in std_logic; data: in std_logic_vector(7 downto 0); Q: out std_logic_vector(7 downto 0) ); end entity FF_GENERIC; To describe such a unit, we'll require two constraints for rst pin: set_pin -kind async-reset -polarity active-low [get_lib_pins ADC_components/FF_GENERIC/rst] \ -if {$ASYNC_RESET == true} set_pin -kind sync-reset -polarity active-low [get_lib_pins ADC_components/FF_GENERIC/rst] \ -if {$ASYNC_RESET == false} Here we have one constraint, which defines rst pin as asynchronous pin, and one, which defines the same pin as synchronous. However, these constraints have different expressions specified in the -if argument. The corresponding constraint will be applied only if the expression evaluates to true, so only one of these constraints will be applied to a particular cell. The ADC_generic_dependent project contains two instances of the FF_GENERIC cell with different generic values applied to them. The schematic for this project is shown on Figure 9. As you can see the uFF_ARST cell has asynchronous reset pin (the rst pin is displayed at the bottom of the cell) and the uFF_SRST cell has synchronous reset pin (the rst pin is displayed on the left side of the cell). This also affects violations detected by the checkers during design linting. Figure 9. The cells with generic dependent constraints. Similarly to generic/parameter values, constants values of ports can be used in the conditional expression. If a constant line is connected to the cell's port in the design, the port value is represented as one of the following characters: '0', '1', 'X', 'Z'. Otherwise, the port value is equal to '-'. Port values always form a binary string regardless of the port type (e.g. "0011" is not converted to decimal 3). Generics/parameters and port names, as well as errors in expression (such as incorrect syntax, division by zero etc.) are verified in the constraint phase during the command execution. Custom synchronizer cells description Description of a synchronizer cell is based on the set_cell command with the lib_synchronizer library function. To create a custom synchronizer, the synchronization circuit description should be placed into a separate design unit. Let's take a look at the simple 2dff synchronizer cell: entity NDFF_SYNCHRONIZER is port ( clk: in std_logic; data: in std_logic_vector(7 downto 0); sync: out std_logic_vector(7 downto 0) ); end entity NDFF_SYNCHRONIZER; The following constraint should be applied to the cell: set_cell -function [ lib_synchronizer \ -in [get_lib_pins ADC_components/NDFF_SYNCHRONIZER/data] \ -out [get_lib_pins ADC_components/NDFF_SYNCHRONIZER/sync] \ -read_clock [get_lib_pins ADC_components/NDFF_SYNCHRONIZER/clk] ] \ [get_lib_cells ADC_components/NDFF_SYNCHRONIZER] The ADC_synchronizer project constraints wrongly used NDFF_SYNCHRONIZER cell (Figure 10). Figure 10. The custom synchronizer. The uNDFF_SYNCHRONIZER synchronizer is misplaced in the design: it receives data from the same domain, and synchronized data is not used in the target domain. This result in the violations from ALDEC_CDC.5.1 and ALDEC_CDC.5.2 checkers, which can be observed in the Violations Viewer (Figure 11). Figure 11. The violations for incorrectly used synchronizer. Verifying values assigned by the constraints A common task, when creating block-level constraints, is to verify which constraints are applied to the particular pin. In ALINT-PRO there is a report_attributes TCL command. This command reports in the text format various characteristics of the supplied object. As an input, it accepts output of block and chip level getters (e.g. get_clocks, get_resets, get_lib_pins etc.). For example, to check what constraints are applied to the data_in pin of the SD_BUS cell from the above example, we can use the following command: report_attributes [get_lib_pins ADC_components/SD_BUS/data_in] Which will return a set of attributes and their values: type: library pin name: ADC_components/SD_BUS/data_in kind: input direction: in sampled_by: clk_tx Here we can see, that this pin is a regular data input pin (kind: input) and is controlled by the clk_tx clock pin (sampled_by: clk_tx). If attributes of a given pin depend on the generic values, then, instead of a plain value, a corresponding expression will be printed in the command output. Let's take a look at the attributes of the rst pin of FF_GENERIC component from the above example: type: library pin name: ADC_components/FF_GENERIC/rst kind: ($ASYNC_RESET == false) ? sync-reset : ($ASYNC_RESET == true) ? async-reset : <unknown> direction: in polarity: ($ASYNC_RESET == false) ? active-low : ($ASYNC_RESET == true) ? active-low : <unknown> Here the ternary expression was composed for the kind and polarity attributes. Ternary expressions have the following structure (<conditional_expression>) ? <true_condition> : <false_condition> and can be nested into each other. The conditional expression in this expression is the expression which was entered as a value of the -if argument of the corresponding constraint command. To check attributes of the generated clock, the following getter should be used: get_lib_cell_paths. This command accepts starting and ending library cell pin and returns relations between pins, which were introduced by the design constraints. For example, if we want to check attributes of the CLK_OUT_DIVA generated clock of the CLK_GEN cell from the above example, we can use the following command: report_attributes [get_lib_cell_paths -from ADC_components/CLK_GEN/CLK -to ADC_components/CLK_GEN/CLK_OUT_DIVA] Following attributes will be reported: type: library cell path name: ADC_components/CLK_GEN/CLK:CLK_OUT_DIVA kind: cell_clock source_port: CLK destination_port: CLK_OUT_DIVA connection_kind: all-to-all divide_by: $DIVA inverted: false combinational: false Here we can examine all characteristics of the generated clock, and if some value is generic dependent we'll see the corresponding expression (e.g. divide_by: $DIVA). Also there is an option that shows summary for block-level constraints applied to a library cell in an HTML format. To generate such a summary, use the Generate Constraints Report item from the context menu for a library node in the Library Viewer window (View | Design Management Windows | Clocks and Resets Viewer button from the main menu or choose Alt+3). Summary Block level design constraints is a powerful mechanism which allows describing in the clear TCL format library cells of any complexity. This includes specifying pin roles (clock, reset, enable, data etc.), creating generated clocks, specifying dependencies between pins and clocks. It is also possible to specify design constraints, which are applied to the cell only when generics have a specific value. To facilitate the constraints creation process, ALINT-PRO offers the report_attributes TCL command, which allows examining values assigned to a particular pin. Once entered, design constraints enable precise linting of a design, allowing utilization of a complete set of rules, available in the product, for non-synthesizable and behavioral portions of the project. Please, refer the Command Reference document (Help menu) for detailed descriptions of the commands, arguments, and related examples. ALINT-PRO applies the identical constraints mechanism to properly handle FPGA vendor primitives. The users are not supposed to describe the vendor primitives on their own, in fact this could be a very error-prone task, especially for complex primitives like dual-port RAMs or multi-clock FIFOs. The constraints are already defined and prepackaged into the product for the most frequently used FPGA vendor libraries (Xilinx, Altera, Microsemi). Previous article Next article
