Vitis Compiler Command

--advanced.param

--advanced.param <param_name>=<param_value>

Specifies advanced parameters as described in the table below.

--advanced.prop

--advanced.prop <arg>

Specifies advanced kernel or solution properties for kernel compilation where <arg> is one of the values described in the table below.

--advanced.misc

--advanced.misc <arg>

Specifies advanced tool directives for kernel compilation.

--clock.defaultFreqHz

--clock.defaultFreqHz <arg>

Specifies a default clock frequency in Hz to use for all kernels. This lets you override the default platform clock and assign the specified clock frequency as the default. <arg> is specified as the clock frequency in Hz.

For example:

v++ --link --clock.defaultFreqHz 300000000

[clock]
defaultFreqHz=300000000

--clock.defaultId

--clock.defaultId <arg>

For example:

v++ --link --clock.defaultId 1

[clock]
defaultId=1

--clock.defaultTolerance

--clock.defaultTolerance <arg>

Specifies a default clock tolerance as a value, or as a percentage of the default clock frequency. When specifying clock.defaultFreqHz, you can also specify the tolerance with either a value or percentage. This updates the timing constraints to reflect the accepted tolerance.

The tolerance value, <arg>, can be specified as a whole number, indicating the clock.defaultFreqHz ± the specified tolerance; or as a percentage of the default clock frequency specified as a decimal value.

For example:

v++ --link --clock.defaultFreqHz 300000000 --clock.defaultTolerance 0.10

[clock]
defaultTolerance=0.10

--clock.freqHz

--clock.freqHz <arg>

Specifies a clock frequency in Hz and assigns it to a list of associated compute units (CUs) and optionally specific clock pins on the CU. <arg> is specified as <frequency_in_Hz>:<cu_0>[.<clk_pin_0>][,<cu_n>[.<clk_pin_n>]]:

• <frequency_in_Hz>: Defines the clock frequency specified in Hz.
• <cu_0>[.<clk_pin_0>][,<cu_n>[.<clk_pin_n>]]: Applies the defined frequency to the specified CUs, and optionally to the specified clock pin on the CU.

v++ --link --clock.freqHz 300000000:vadd_1,vadd_3

[clock]
freqHz=300000000:vadd_1,vadd_3

--clock.id

--clock.id <arg>

Specifies an available clock ID from the target platform and assigns it to a list of associated compute units (CUs) and optionally specific clock pins on the CU. <arg> is specified as <reference_ID>:<cu_0>[.<clk_pin_0>][,<cu_n>[.<clk_pin_n>]]:

• <reference_ID>: Defines the clock ID to use from the target platform.
  TIP: You can determine the available clock IDs for a target platform using the platforminfo utility as described in platforminfo Utility.
• <cu_0>[.<clk_pin_0>][,<cu_n>[.<clk_pin_n>]]: Applies the defined frequency to the specified CUs and optionally to the specified clock pin on the CU.

For example:

v++ --link --clock.id 1:vadd_1,vadd_3

[clock]
id=1:vadd_1,vadd_3

--clock.tolerance

--clock.tolerance <arg>

Specifies a clock tolerance as a value, or as a percentage of the clock frequency. When specifying --clock.freqHz, you can also specify the tolerance with either a value or percentage. This updates the timing constraints to reflect the accepted tolerance. <arg> is specified as <tolerance>:<cu_0>[.<clk_pin_0>][,<cu_n>[.<clk_pin_n>]]

• <tolerance>: Can be specified either as a whole number, indicating the clock.freqHz ± the specified tolerance value; or as a percentage of the clock frequency specified as a decimal value.
• <cu_0>[.<clk_pin_0>][,<cu_n>[.<clk_pin_n>]]: Applies the defined clock tolerance to the specified CUs, and optionally to the specified clock pin on the CU.

For example:

v++ --link --clock.tolerance 0.10:vadd_1,vadd_3 

[clock]
tolerance=0.10:vadd_1,vadd_3

--connectivity.nk

--connectivity.nk <arg>

Where <arg> is specified as <kernel_name>:#:<cu_name1>.<cu_name2>...<cu_name#>.

This instantiates the specified number of CU (#) for the specified kernel (kernel_name) in the generated FPGA binary (.xclbin) file during the linking process. The cu_name is optional. If the cu_name is not specified, the instances of the kernel are simply numbered: kernel_name_1, kernel_name_2, and so forth. By default, the Vitis compiler instantiates one compute unit for each kernel.

For example:

v++ --link --connectivity.nk vadd:3:vadd_A.vadd_B.vadd_C

[connectivity]
nk=vadd:3:vadd_A.vadd_B.vadd_C

--connectivity.sc

--connectivity.sc <arg>

Create a streaming connection between two compute units through their AXI4-Stream interfaces. Use a separate --connectivity.sc option for each streaming interface connection. The order of connection must be from a streaming output port of the first kernel to a streaming input port of the second kernel. Valid values include:

<cu_name>.<streaming_output_port>:<cu_name>.<streaming_input_port>[:<fifo_depth>]

Where:

• <cu_name> is the compute unit name specified in the --connectivity.nk option. Generally this is <kernel_name>_1 unless a different name was specified.
• <streaming_output_port>/<streaming_input_port> is the function argument for the compute unit port that is declared as an AXI4-Stream.
• [:<fifo_depth>] inserts a FIFO of the specified depth between the two streaming ports to prevent stalls. The value is specified as an integer.

For example, to connect the AXI4-Stream port s_out of the compute unit mem_read_1 to AXI4-Stream port s_in of the compute unit increment_1, use the following:

--connectivity.sc mem_read_1.s_out:increment_1.s_in

[connectivity]
sc=mem_read_1.s_out:increment_1.s_in

The inclusion of the optional <fifo_depth> value lets the v++ linker add a FIFO between the two kernels to help prevent stalls. This uses BRAM resources from the device when specified, but eliminates the need to update the HLS kernel to contain FIFOs. The tool also instantiates a Clock Converter (CDC) or Datawidth Converter (DWC) IP if the connections have different clocks, or different bus widths.

--connectivity.slr

--connectivity.slr <arg>

Use this option to assign a CU to a specific SLR on the device. The option must be repeated for each kernel or CU being assigned to an SLR.

Valid values include:

<cu_name>:<SLR_NUM>

Where:

• <cu_name> is the name of the compute unit as specified in the --connectivity.nk option. Generally this is <kernel_name>_1 unless a different name was specified.
• <SLR_NUM> is the SLR number to assign the CU to. For example, SLR0, SLR1.

For example, to assign CU vadd_2 to SLR2, and CU fft_1 to SLR1, use the following:

v++ --link --connectivity.slr vadd_2:SLR2 --connectivity.slr fft_1:SLR1

[connectivity]
slr=vadd_2:SLR2
slr=fft_1:SLR1

--connectivity.sp

--connectivity.sp <arg>

Use this option to specify the assignment of kernel arguments to system ports within the platform. A primary use case for this option is to connect kernel arguments to specific memory resources. A separate --connectivity.sp option is required to map each argument of a kernel to a particular memory resource. Any argument not explicitly mapped to a memory resource through the --connectivity.sp option is automatically connected to an available memory resource during the build process.

Valid values include:

<cu_name>.<kernel_argument_name>:<sptag[min:max]>

Where:

• <cu_name> is the name of the compute unit as specified in the --connectivity.nk option. Generally this is <kernel_name>_1 unless a different name was specified.
• <kernel_argument_name> is the name of the function argument for the kernel, or the compute unit interface port.
• <sptag> represents a system port tag, such as for memory controller interface names from the target platform. Valid <sptag> names include DDR, PLRAM, and HBM.
• [min:max] enables the use of a range of memory, such as DDR[0:2]. A single index is also supported: DDR[2].

The following example maps the input argument (A) for the specified CU of the VADD kernel to DDR[0:3], input argument (B) to HBM[0:31], and writes the output argument (C) to PLRAM[2]:

v++ --link --connectivity.sp vadd_1.A:DDR[0:3] --connectivity.sp vadd_1.B:HBM[0:31] \
--connectivity.sp vadd_1.C:PLRAM[2]

[connectivity]
sp=vadd_1.A:DDR[0:3]
sp=vadd_1.B:HBM[0:31]
sp=vadd_1.C:PLRAM[2]

--connectivity.connect

--connectivity.connect <X:Y>

This option can be used to make connections through the Vivado IP integrator, but v++ does not perform any error checking on the specified connections. Use this to specify general connections between kernels and non-AXI elements of the target platform, such as connections to GT ports.

src/hierarchy_name/cell_name/pin_name:dst/hierarchy_name/cell_name/pin_name

These cannot include connections between AXI4-Stream interfaces which require the use of --conectivity.sc, or M_AXI interfaces which require the use of --connectivity.sp as described above.

[connectivity]
connect=<X:Y>

--debug.chipscope

--debug.chipscope <cu_name>[:<interface_name>]

Adds the System Integrated Logic Analyzer debug core to the specified CUs in the design.

For example, the following command adds an ILA core to the vadd_1 CU:

v++ --link --debug.chipscope vadd_1

--debug.list_ports

Shows a list of valid compute units and port combinations in the current design. This is informational to help you with crafting a command line or config file for the --debug command.

This option needs to be specified during linking, but does not run the linking process. The required elements of the command line are shown in the following example, which returns the available ports when linking the specified kernels with the listed platform:

v++ --platform <platform> --link --debug.list_ports <kernel.xo>

--debug.protocol

--debug.protocol all|<cu_name>[:<interface_name>]

Adds the AXI Protocol Checker debug core to the design. This can be specified with the keyword all, or the <cu_name> and optional <interface_name> to add the protocol checker to the specified CU and interface.

For example:

v++ --link --debug.protocol all

--hls.clock

--hls.clock <arg>

Specifies a frequency in Hz at which the listed kernel(s) should be compiled by Vitis HLS.

Where <arg> is specified as: <frequency_in_Hz>:<cu_name1>,<cu_name2>,..,<cu_nameN>

• <frequency_in_Hz>: Defines the kernel frequency specified in Hz.
• <cu_name1>,<cu_name2>,...: Defines a list of kernels or kernel instances (CUs) to be compiled at the specified target frequency.

For example:

v++ -c --hls.clock 300000000:mmult,mmadd --hls.clock 100000000:fifo_1

[hls]
clock=300000000:mmult,mmadd
clock=100000000:fifo_1

--hls.export_mode

--hls.export_mode <file_type>:<file_path>

Specifies the RTL export mode for Vitis HLS and the path and name of the exported file. As a v++ compiler option, the only supported <file_type> is XO.

For example:

v++ --hls.export_mode xo:./kernel.xo

[hls]
export_mode=xo:./kernel.xo

--hls.export_project

--hls.export_project <arg>

Specifies a directory where the Vitis HLS project setup script is exported.

For example:

v++ --hls.export_project ./hls_export

[hls]
export_project=./hls_export

--hls.jobs

--hls.jobs <arg>

Specifies the number of jobs for launching HLS runs.

This option specifies the number of parallel jobs Vitis HLS uses to synthesize the RTL kernel code. Increasing the number of jobs allows the tool to spawn more parallel processes and complete faster.

For example:

v++ --hls.jobs 4

[hls]
jobs=4

--hls.lsf

--hls.lsf <arg>

Specifies a bsub command to submit a job to LSF for HLS runs.

Specifies the bsub command line as a string to pass to an LSF cluster. This option is required to use the IBM Platform Load Sharing Facility (LSF) for Vitis HLS synthesis.

For example:

v++ --compile --hls.lsf '{bsub -R \"select[type=X86_64]\" -N -q medium}'

[hls]
lsf='{bsub...

--hls.post_tcl

--hls.post_tcl <arg>

Specifies a Tcl file containing Tcl commands for vitis_hls to source after csynth_design.

For example:

v++ --hls.post_tcl ./runPost.tcl

[hls]
post_tcl=./runPost.tcl

--hls.pre_tcl

--hls.pre_tcl <arg>

Specifies a Tcl file containing Tcl commands for vitis_hls to source before running csynth_design.

For example:

v++ --hls.pre_tcl ./runPre.tcl

config_interface -m_axi_auto_max_ports=1
config_interface -m_axi_max_bitwidth 512

[hls]
pre_tcl=./runPre.tcl

--linkhook.custom

--linkhook.custom <step name, path to script file>

Specifies a Tcl script to execute at a predefined point in the build process. The path to specify the script can be an absolute path, or partial path relative to the build directory.

For example, the following command runs the specified Tcl script before the SysLink step in the build:

v++ -l --linkhook.custom preSysLink,./runScript.tcl

-linkhook.do_first

--linkhook.do_first <step name, path to script file>

Specifies a Tcl script to execute before the given step name. The path to specify the script can be an absolute path, or partial path relative to the build directory.

For example, the following command runs the specified Tcl script before the place_design step in the build:

v++ -l --linkhook.do_first vpl.impl.place_design,runScript.tcl

-linkhook.do_last

--linkhook.do_last <step name, path to script file>

Specifies a Tcl script to execute immediately after the given step completes. The path to specify the script can be an absolute path, or partial path relative to the build directory.

For example, the following command runs the specified Tcl script after the place_design step in the build:

v++ -l --linkhook.do_last vpl.impl.place_design,runScript.tcl

-linkhook.list_steps

--linkhook.list_steps

List default and optional build steps that support script hooks for a specified target. This command requires the --target to be specified as well as the --link option.

For example:

v++ --target hw -l --linkhook.list_steps

The command returns both default steps that are always enabled during the build process, and optional steps that you can enable if needed. Refer to Managing Vivado Synthesis and Implementation Results for directions on enabling optional steps.

Introduction

The v++ --package, or -p step, packages the final product at the end of the v++ compile and link build process. This is a required step for all embedded platforms, including Versal devices, AI Engine, and Zynq devices.

The various options of --package include the following:

--package.aie_debug_port

--package.aie_debug_port <arg>

Where <arg> specifies a TCP port where emulator listens for incoming connections from the debugger to debug Versal AI Engine cores.

For example:

v++ -l --package.aie_debug_port 1440 

--package.bl31_elf

--package.bl31_elf <arg>

Where <arg> specifies the absolute or relative path to Arm trusted FW ELF that executes on A72 #0 core.

For example:

v++ -l --package.bl31_elf ./arm_trusted.elf 

--package.boot_mode

--package.boot_mode <arg>

For example:

v++ -l --package.boot_mode sd 

--package.defer_aie_run

--package.defer_aie_run

Where this option specifies that the Versal AI Engine cores are enabled by an embedded processor (PS) application. When not specified, the tool generates CDO commands to enable the AI Engine cores during PDI load instead.

For example:

v++ -l --package.defer_aie_run

--package.domain

--package.domain <arg>

Where <arg> specifies a domain name.

For example:

v++ -l --package.domain xrt

--package.dtb

--package.dtb <arg>

Where <arg> specifies the absolute or relative path to device tree binary (DTB) used for loading Linux on the APU.

For example:

v++ -l --package.dtb ./device_tree.image

--package.enable_aie_debug

--package.enable_aie_debug

When enabled, the tool generates CDO commands to stop the AI Engine cores during PDI load.

For example:

v++ -l --package.enable_aie_debug 

--package.image_format

--package.image_format <arg>

Where <arg> specifies <ext4 | fat32> output image file format used on the SD card.

• ext4: Linux file system
• fat32: Windows file system

For example:

v++ -l --package.image_format fat32 

--package.kernel_image

--package.kernel_image <arg>

Where <arg> specifies the absolute or relative path to a Linux kernel image file. Overrides the existing image available in the platform. The platform image file is available for download from xilinx.com. Refer to the Vitis Software Platform Installation for more information.

For example:

v++ -l --package.kernel_image ./kernel_image 

--package.no_image

--package.no_image

Bypass SD card image creation. Valid for --package.boot_mode sd.

--package.out_dir

--package.out_dir <arg>

Where <arg> specifies the absolute or relative path to the output directory of the --package command.

For example:

v++ -l --package.out_dir ./out_dir 

--package.ps_debug_port

--package.ps_debug_port <arg>

Where <arg> specifies the TCP port where emulator listens for incoming connections from the debugger to debug PS cores.

For example:

v++ -l --package.debug_port 3200 

--package.ps_elf

--package.ps_elf <arg>

Where <arg> specifies <path_to_elf_file,core>.

• path_to_elf_file: Specifies the ELF file for the PS core.
• core: Indicates the PS core it should run on.

Used when a baremetal ELF file is running on a device processor core. This option specifies an ELF file and processor core pair to be included in the boot image. The available processors for supported devices are listed below:

• Versal processor core values include: a72-0, a72-1, a72-2, and a72-3.
• Zynq UltraScale+ MPSoC processor core values include: a53-0, a53-1, a53-2, a53-3, r5-0, and r5-1.
• Zynq-7000 processor core values include: a9-0 and a9-1.

For example:

v++ -l --package.ps_elf a53_0.elf,a53-0 --package.ps_elf r5_0.elf,r5-0

--package.rootfs

--package.rootfs <arg>

Where <arg> specifies the absolute or relative path to a processed Linux root file system file. The platform RootFS file is available for download from Xilinx.com. Refer to the Vitis Software Platform Installation for more information.

For example:

v++ -l --package.rootfs ./rootfs.ext4

--package.sd_dir

--package.sd_dir <arg>

Where <arg> specifies a folder to package into the sd_card directory/image. The contents of the directory are copied to a sub-folder of the sd_card folder.

For example:

v++ -l --package.sd_dir ./test_data 

--package.sd_file

--package.sd_file <arg>

Where <arg> specifies an ELF or other data file to package into the sd_card directory/image. This option can be used repeatedly to specify multiple files to add to the sd_card.

For example:

v++ -l --package.sd_file ./arm_trusted.elf 

--package.uboot

--package.uboot <arg>

Where <arg> specifies a path to U-boot ELF file which overrides a platform U-boot.

For example:

v++ -l --package.uboot ./uboot.elf 

--profile.aie <arg>

Enables profiling of AI Engine streams in adaptive data flow (ADF) applications, where <arg> is:

<ADF_graph_argument|pin name|all>

• <ADF_graph_argument>: Specifies an argument name from the ADF graph application.
• <pin_name>: Indicates a port on an AI Engine kernel.
• <all>: Indicates monitoring all stream connections in the ADF application.

v++ --link --profile.aie:DataIn1

--profile.data <arg>

Enables monitoring of data ports through the monitor IPs. This option needs to be specified during linking.

Where <arg> is:

[<kernel_name>|all]:[<cu_name>|all]:[<interface_name>|all](:[counters|all])

• [<kernel_name>|all] defines either a specific kernel to apply the command to. However, you can also specify the keyword all to apply the monitoring to all existing kernels, compute units, and interfaces with a single option.
• [<cu_name>|all] when <kernel_name> has been specified, you can also define a specific CU to apply the command to, or indicate that it should be applied to all CUs for the kernel.
• [<interface_name>|all] defines the specific interface on the kernel or CU to monitor for data activity, or monitor all interfaces.
• [<counters|all] is an optional argument, as it defaults to all when not specified. It allows you to restrict the information gathering to just counters for larger designs, while all will include the collection of actual trace information.

For example, to assign the data profile to all CUs and interfaces of kernel k1 use the following command:

v++ --link --profile.data:k1:all:all

--profile.exec <arg>

This option records the execution times of the kernel and provides minimum port data collection during the system run. This option needs to be specified during linking.

The syntax for exec profiling is:

[<kernel_name>|all]:[<cu_name>|all](:[counters|all])

For example, to profile to execution of cu2 for kernel k1 use the following command:

v++ --link --profile.exec:k1:cu2

--profile.stall

Adds stall monitoring logic to the device binary (.xclbin) which requires the addition of stall ports on the kernel interface. To facilitate this, the stall option must be specified during both compilation and linking.

The syntax for stall profiling is:

[<kernel_name>|all]:[<cu_name>|all](:[counters|all])

For example, to monitor stalls of cu2 for kernel k1 use the following command:

v++ --compile -k k1 --profile.stall ...
v++ --link --profile.stall:k1:cu2 ...

--profile.trace_memory

When building the hardware target (-t=hw), use this option to specify the type and amount of memory to use for capturing trace data. You can specify the argument as follows:

<FIFO>:<size>|<MEMORY>[<n>]

This argument specifies trace buffer memory type for profiling.

FIFO:<size>

Specified in KB. Default is FIFO:8K. The maximum is 4G.

Memory[<N>]

Specifies the type and number of memory resource on the platform. Memory resources for the target platform can be identified with the platforminfo command. Supported memory types include HBM, DDR, PLRAM, HP, ACP, MIG, and MC_NOC. For example, DDR[1].

--vivado.impl.jobs

--vivado.impl.jobs <arg>

Specifies the number of parallel jobs the Vivado Design Suite uses to implement the device binary. Increasing the number of jobs allows the Vivado implementation step to spawn more parallel processes and complete faster jobs.

For example:

v++ --link --vivado.impl.jobs 4

--vivado.impl.lsf

--vivado.impl.lsf <arg>

Specifies the bsub command line as a string to pass to an LSF cluster. This option is required to use the IBM Platform Load Sharing Facility (LSF) for Vivado implementation.

For example:

v++ --link --vivado.impl.lsf '{bsub -R \"select[type=X86_64]\" -N -q medium}'

--vivado.impl.strategies

--vivado.impl.strategies <arg>

Specifies a comma-separated list of strategy names for Vivado implementation runs. Use ALL to run all available implementation strategies. This lets you run a variety of implementation strategies at the same time during the build process and allows you to more quickly resolve the timing and routing issues of the design.

--vivado.param

--vivado.param <arg>

Specifies parameters for the Vivado Design Suite to be used during synthesis and implementation of the FPGA binary (xclbin).

--vivado.prop

--vivado.prop <arg>

Specifies properties for the Vivado Design Suite to be used during synthesis and implementation of the FPGA binary (xclbin).

vivado.prop run.impl_1.
{STEPS.PLACE_DESIGN.ARGS.MORE 
OPTIONS}={-no_bufg_opt}

vivado.prop fileset.
current.top=foo

For example, from the command line:

v++ --link --vivado.prop run.impl_1.STEPS.PHYS_OPT_DESIGN.IS_ENABLED=true
--vivado.prop run.impl_1.STEPS.PHYS_OPT_DESIGN.ARGS.DIRECTIVE=Explore
--vivado.prop run.impl_1.STEPS.PLACE_DESIGN.TCL.PRE=/…/xxx.tcl

These options can also be specified in a configuration file under the [vivado] section head using the following format:

[vivado]
prop=run.impl_1.STEPS.PHYS_OPT_DESIGN.IS_ENABLED=true
prop=run.impl_1.STEPS.PHYS_OPT_DESIGN.ARGS.DIRECTIVE=Explore
prop=run.impl_1.STEPS.PLACE_DESIGN.TCL.PRE=/…/xxx.tcl

--vivado_prop run.impl_1.{STEPS.PLACE_DESIGN.ARGS.MORE OPTIONS}={-no_bufg_opt}

--vivado_prop run.impl_1.STEPS.PLACE_DESIGN.ARGS.{MORE OPTIONS}={-no_bufg_opt}

--vivado.synth.jobs

--vivado.synth.jobs <arg>

Specifies the number of parallel jobs the Vivado Design Suite uses to synthesize the device binary. Increasing the number of jobs allows the Vivado synthesis to spawn more parallel processes and complete faster jobs.

For example:

v++ --link --vivado.synth.jobs 4

--vivado.synth.lsf

--vivado.synth.lsf <arg>

Specifies the bsub command line as a string to pass to an LSF cluster. This option is required to use the IBM Platform Load Sharing Facility (LSF) for Vivado synthesis.

For example:

v++ --link --vivado.synth.lsf '{bsub -R \"select[type=X86_64]\" -N -q medium}'

Comment

Any line with “#” as the first non-white space character is a comment.

Supported Commands

By default, v++ recursively scans the entire working directory and promotes all error messages to the v++ output. The promote and suppress commands below provide more control on the v++ output.

• promote: This command indicates that matching messages should be promoted to the v++ output.
• suppress: This command indicates that matching messages should be suppressed or filtered from the v++ output. Note that errors cannot be suppressed.

Enter only one command per line.

Command Options

The Message Rule file can have multiple promote and suppress commands. Each command can have one and only one of the options below. The options are case-sensitive.

• -id [<message_id>]: All messages matching the specified message ID are promoted or suppressed. The message ID is in format of nnn-mmm. As an example, the following is a warning message from HLS. The message ID in this case is 204-68.

  WARNING: [V++ 204-68] Unable to enforce a carried dependence constraint (II = 1, distance = 1, offset = 1) 
  between bus request on port 'gmem' 
  (/matrix_multiply_cl_kernel/mmult1.cl:57) and bus request on port 'gmem'-severity [severity_level]

  For example, to suppress messages with message ID 204-68, specify the following: suppress -id 204-68.

• -severity [<severity_level>]: The following are valid values for the severity level. All messages matching the specified severity level will be promoted or suppressed.
  • info
  • warning
  • critical_warning

    For example, to promote messages with severity of 'critical-warning', specify the following: promote -severity critical_warning.

Precedence of Message Rules

The suppress rules take precedence over promote rules. If the same message ID or severity level is passed to both promote and suppress commands in the Message Rule file, the matching messages are suppressed and not displayed.

Example of Message Rule File

The following is an example of a valid Message Rule file:

# promote all warning, critical warning
promote -severity warning
promote -severity critical_warning
# suppress the critical warning message with id 19-2342
suppress -id 19-2342