verilog assign different width

Verilog Assignments

Variable declaration assignment, net declaration assignment, assign deassign, force release.

• Procedural continuous

Legal LHS values

An assignment has two parts - right-hand side (RHS) and left-hand side (LHS) with an equal symbol (=) or a less than-equal symbol (<=) in between.

The RHS can contain any expression that evaluates to a final value while the LHS indicates a net or a variable to which the value in RHS is being assigned.

Procedural Assignment

Procedural assignments occur within procedures such as always , initial , task and functions and are used to place values onto variables. The variable will hold the value until the next assignment to the same variable.

The value will be placed onto the variable when the simulation executes this statement at some point during simulation time. This can be controlled and modified the way we want by the use of control flow statements such as if-else-if , case statement and looping mechanisms.

An initial value can be placed onto a variable at the time of its declaration as shown next. The assignment does not have a duration and holds the value until the next assignment to the same variable happens. Note that variable declaration assignments to an array are not allowed.

If the variable is initialized during declaration and at time 0 in an initial block as shown below, the order of evaluation is not guaranteed, and hence can have either 8'h05 or 8'hee.

Procedural blocks and assignments will be covered in more detail in a later section.

Continuous Assignment

This is used to assign values onto scalar and vector nets and happens whenever there is a change in the RHS. It provides a way to model combinational logic without specifying an interconnection of gates and makes it easier to drive the net with logical expressions.

Whenever b or c changes its value, then the whole expression in RHS will be evaluated and a will be updated with the new value.

This allows us to place a continuous assignment on the same statement that declares the net. Note that because a net can be declared only once, only one declaration assignment is possible for a net.

Procedural Continuous Assignment

• assign ... deassign
• force ... release

This will override all procedural assignments to a variable and is deactivated by using the same signal with deassign . The value of the variable will remain same until the variable gets a new value through a procedural or procedural continuous assignment. The LHS of an assign statement cannot be a bit-select, part-select or an array reference but can be a variable or a concatenation of variables.

These are similar to the assign - deassign statements but can also be applied to nets and variables. The LHS can be a bit-select of a net, part-select of a net, variable or a net but cannot be the reference to an array and bit/part select of a variable. The force statment will override all other assignments made to the variable until it is released using the release keyword.

• Errors and Warnings
• Edit on GitHub

Errors and Warnings ¶

Disabling warnings ¶.

Warnings may be disabled in multiple ways:

Disable the warning globally by invoking Verilator with the -Wno-{warning-code} option.

Global disables should be avoided, as they removes all checking across the source files, and prevents other users from compiling the sources without knowing the magic set of disables needed to compile those sources successfully.

Disable the warning in the design source code. When the warning is printed, it will include a warning code. Surround the offending line with a /*verilator lint_off*/ and /*verilator lint_on*/ metacomment pair:

A lint_off in the design source code will propagate down to any child files (files later included by the file with the lint_off), but will not propagate upwards to any parent file (file that included the file with the lint_off).

Disable the warning using Configuration Files with a lint_off command. This is useful when a script suppresses warnings, and the Verilog source should not be changed. This method also allows matching on the warning text.

Error And Warning Format ¶

Warnings and errors printed by Verilator always match this regular expression:

Errors and warnings start with a percent sign (historical heritage from Digital Equipment Corporation). Some errors or warnings have a code attached, with meanings described below. Some errors also have a filename, line number, and optional column number (starting at column 1 to match GCC).

Following the error message, Verilator will typically show the user’s source code corresponding to the error, prefixed by the line number and a ” | “. Following this is typically an arrow and ~ pointing at the error on the source line directly above.

List Of Warnings ¶

This error should never occur first, though it may occur if earlier warnings or error messages have corrupted the program. If there are no other warnings or errors, submit a bug report.

This error indicates that the code uses a Verilog language construct that is not yet supported in Verilator. See also Language Limitations .

Warns that an always_comb block has a variable that is set after it is used. This may cause simulation-synthesis mismatches, as not all simulators allow this ordering.

Ignoring this warning will only suppress the lint check; it will simulate correctly.

Warns that a packed vector is declared with ascending bit range (i.e. [0:7]). Descending bit range is now the overwhelming standard, and ascending ranges are now thus often due to simple oversight instead of intent (a notable exception is the OpenPOWER code base).

It also warns that an instance is declared with ascending range (i.e. [0:7] or [7]) and is connected to an N-wide signal. The bits will likely be in the reversed order from what people may expect (i.e., instance [0] will connect to signal bit [N-1] not bit [0]).

Warns that the code has an assignment statement with a delayed time in front of it, for example:

Ignoring this warning may make Verilator simulations differ from other simulators; however, this was a common style at one point, so disabled by default as a code-style warning.

This warning is issued only if Verilator is run with --no-timing .

An error that an assignment is being made to an input signal. This is almost certainly a mistake, though technically legal.

An error that a pragma is badly formed, for pragmas defined by IEEE 1800-2017. For example, an empty pragma line, or an incorrectly used ‘pragma protect’. Third-party pragmas not defined by IEEE 1800-2017 are ignored.

BLKANDNBLK is an error that a variable is driven by a mix of blocking and non-blocking assignments.

This is not illegal in SystemVerilog but a violation of good coding practice. Verilator reports this as an error because ignoring this warning may make Verilator simulations differ from other simulators.

It is generally safe to disable this error (with a // verilator lint_off BLKANDNBLK metacomment or the -Wno-BLKANDNBLK option) when one of the assignments is inside a public task, or when the blocking and non-blocking assignments have non-overlapping bits and structure members.

Generally, this is caused by a register driven by both combo logic and a flop:

Instead, use a different register for the flop:

Or, this may also avoid the error:

This indicates that the initialization of an array needs to use non-delayed assignments. This is done in the interest of speed; if delayed assignments were used, the simulator would have to copy large arrays every cycle. (In smaller loops, loop unrolling allows the delayed assignment to work, though it’s a bit slower than a non-delayed assignment.) Here’s an example

This message is only seen on large or complicated loops because Verilator generally unrolls small loops. You may want to try increasing --unroll-count (and occasionally --unroll-stmts ), which will raise the small loop bar to avoid this error.

This indicates that a blocking assignment (=) is used in a sequential block. Generally, non-blocking/delayed assignments (<=) are used in sequential blocks, to avoid the possibility of simulator races. It can be reasonable to do this if the generated signal is used ONLY later in the same block; however, this style is generally discouraged as it is error prone.

Disabled by default as this is a code-style warning; it will simulate correctly.

Other tools with similar warnings: Verible’s always-ff-non-blocking, “Use only non-blocking assignments inside ‘always_ff’ sequential blocks.”

Warns that a backslash is followed by a space then a newline. Likely the intent was to have a backslash directly followed by a newline (e.g., when making a “`define”), and there’s accidentally white space at the end of the line. If the space is not accidental, suggest removing the backslash in the code, as it serves no function.

Warns that inside a case statement, there is a stimulus pattern for which no case item is provided. This is bad style; if a case is impossible, it’s better to have a default: $stop; or just default: ; so that any design assumption violations will be discovered in the simulation.

Unique case statements that select on an enumerated variable, where all of the enumerated values are covered by case items, are considered complete even if the case statement does not cover illegal non-enumerated values (IEEE 1800-2017 12.5.3). To check that illegal values are not hit, use --assert .

Warns that a case statement has case values detected to be overlapping. This is bad style, as moving the order of case values will cause different behavior. Generally the values can be respecified not to overlap.

Warns that a case statement contains a constant with an x . Verilator is two-state so interpret such items as always false. Note that a frequent error is to use a X in a case or casez statement item; often, what the user instead intended is to use a casez with ? .

Warns that it is better style to use casez, and “?” in place of “x“‘s. See http://www.sunburst-design.com/papers/CummingsSNUG1999Boston_FullParallelCase_rev1_1.pdf

Warns that a dynamic cast ($cast) is unnecessary as the $cast will always succeed or fail. If it will always fail, the $cast is useless, and if it will always succeed, a static cast may be preferred.

Ignoring this warning will only suppress the lint check; it will simulate correctly. On other simulators, not fixing CASTCONST may result in decreased performance.

Historical, never issued since version 5.008.

Warned with a no longer supported clock domain crossing option that asynchronous flop reset terms came from other than primary inputs or flopped outputs, creating the potential for reset glitches.

Historical, never issued since version 5.000.

Warned that clock signal was mixed used with/as a data signal. The checking for this warning was enabled only if the user has explicitly marked some signal as clocker using the command line option or in-source meta comment (see --clk ).

The warning could be disabled without affecting the simulation result. But it was recommended to check the warning as it may have degraded the performance of the Verilated model.

Warns that the code is comparing a value in a way that will always be constant. For example, X > 1 will always be true when X is a single bit wide.

Warns that a :+ is seen. Likely the intent was to use +: to select a range of bits. If the intent was an explicitly positive range, suggest adding a space, e.g., use : + .

Warns that there is a delayed assignment inside of a combinatorial block. Using delayed assignments in this way is considered bad form, and may lead to the simulator not matching synthesis. If this message is suppressed, Verilator, like synthesis, will convert this to a non-delayed assignment, which may result in logic races or other nasties. See http://www.sunburst-design.com/papers/CummingsSNUG2000SJ_NBA_rev1_2.pdf

Ignoring this warning may make Verilator simulations differ from other simulators.

Warns that Verilator does not support constraint , constraint_mode , or rand_mode , and the construct was are ignored.

Ignoring this warning may make Verilator randomize() simulations differ from other simulators.

An error that a continuous assignment is setting a reg. According to IEEE Verilog, but not SystemVerilog, a wire must be used as the target of continuous assignments.

This error is only reported when

--language 1364-1995 , --language 1364-2001 , or --language 1364-2005 is used.

Ignoring this error will only suppress the lint check; it will simulate correctly.

Warns that a module or other declaration’s name doesn’t match the filename with the path and extension stripped that it is declared in. The filename a module/interface/program is declared in should match the name of the module etc., so that -y option directory searching will work. This warning is printed for only the first mismatching module in any given file, and -v library files are ignored.

Warns that the defparam statement was deprecated in IEEE 1364-2001, and all designs should now be using the #(...) format to specify parameters.

Defparams may be defined far from the instantiation affected by the defparam, affecting readability. Defparams have been formally deprecated since IEEE 1800-2005 25.2 and may not work in future language versions.

Faulty example:

Results in:

To repair use #(.PARAMETER(...)) syntax. Repaired Example:

Other tools with similar warnings: Verible’s forbid_defparam_rule.

Warning that a Verilator metacomment, or configuration file command uses syntax that has been deprecated. Upgrade the code to the replacement typically suggested by the warning message.

Historical, never issued since version 3.862.

Was an error when Verilator tried to deal with a combinatorial loop that could not be flattened, and which involves a datatype that Verilator could not handle, such as an unpacked struct or a large unpacked array.

Error at simulation runtime when model did not correctly settle.

Verilator sometimes has to evaluate combinatorial logic multiple times, usually around code where an UNOPTFLAT warning was issued but disabled.

Results in at runtime (not when Verilated):

This is because the signals keep toggling even without time passing. Thus to prevent an infinite loop, the Verilated executable gives the DIDNOTCONVERGE error.

To debug this, first, review any UNOPTFLAT warnings that were ignored. Though typically, it is safe to ignore UNOPTFLAT (at a performance cost), at the time of issuing a UNOPTFLAT Verilator did not know if the logic would eventually converge and assumed it would.

Next, run Verilator with --prof-cfuncs -CFLAGS -DVL_DEBUG . Rerun the test. Now just before the convergence error, you should see additional output similar to this:

The CHANGE line means that the signal ‘a’ kept changing on the given filename and line number that drove the signal. Inspect the code that modifies these signals. Note that if many signals are getting printed, then most likely, all of them are oscillating. It may also be that, e.g. “a” may be oscillating, then “a” feeds signal “c”, which then is also reported as oscillating.

One way DIDNOTCONVERGE may occur is flops are built out of gate primitives. Verilator does not support building flops or latches out of gate primitives, and any such code must change to use behavioral constructs (e.g. always_ff and always_latch).

Another way DIDNOTCONVERGE may occur is if # delays are used to generate clocks if Verilator is run with --no-timing . In this mode, Verilator ignores the delays and gives an ASSIGNDLY or STMTDLY warning. If these were suppressed, due to the absence of the delay, the design might oscillate.

Finally, rare, more difficult cases can be debugged like a C++ program; either enter gdb and use its tracing facilities, or edit the generated C++ code to add appropriate prints to see what is going on.

Warns that a class member is declared local or protected , but is being accessed from outside that class (if local) or a derived class (if protected).

An error that a label attached to a “end”-something statement does not match the label attached to the block start.

IEEE requires this error. Ignoring this warning will only suppress the lint check; it will simulate correctly.

To repair, either fix the end label’s name, or remove it entirely.

Other tools with similar warnings: Verible’s mismatched-labels, “Begin/end block labels must match.” or “Matching begin label is missing.”

An error that an enum data type value is being assigned from another data type that is not implicitly assignment compatible with that enumerated type. IEEE requires this error, but it may be disabled.

The ideal repair is to use the enumeration value’s mnemonic:

Alternatively use a static cast:

Warns that a file does not end in a newline. POSIX defines that a line must end in a newline, as otherwise, for example cat with the file as an argument may produce undesirable results.

Repair by appending a newline to the end of the file.

Other tools with similar warnings: Verible’s posix-eof, “File must end with a newline.”

Indicated that the specified signal was generated inside the model and used as a clock.

Warns that a generate block was unnamed and “genblk” will be used per IEEE.

The potential issue is that adding additional generate blocks will renumber the assigned names, which may cause eventual problems with synthesis constraints or other tools that depend on hierarchical paths remaining consistent.

Blocks that are empty may not be reported with this warning, as no scopes are created for empty blocks, so there is no harm in having them unnamed.

To fix this assign a label (often with the naming convention prefix of gen_ or g_ ), for example:

Other tools with similar warnings: Verible’s generate-label, “All generate block statements must have a label.”

Warns that the top module is marked as a hierarchy block by the /*verilator hier_block*/ metacomment, which is not legal. This setting on the top module will be ignored.

Warns that if/if else statements have exceeded the depth specified with --if-depth , as they are likely to result in slow priority encoders. Statements below unique and priority if statements are ignored. Solutions include changing the code to a case statement, or using a SystemVerilog unique if or priority if statement.

Warns that a non-void function is being called as a task, and hence the return value is being ignored. IEEE requires this warning.

The portable way to suppress this warning (in SystemVerilog) is to use a void cast, for example:

Warned that the scheduling of the model is not perfect, and some manual code edits may result in faster performance. This warning defaulted to off, was not part of -Wall , and had to be turned on explicitly before the top module statement was processed.

Warns that a wire is being implicitly declared (it is a single-bit wide output from a sub-module.) While legal in Verilog, implicit declarations only work for single-bit wide signals (not buses), do not allow using a signal before it is implicitly declared by an instance, and can lead to dangling nets. A better option is the /*AUTOWIRE*/ feature of Verilog-Mode for Emacs, available from https://www.veripool.org/verilog-mode

Other tools with similar warnings: Icarus Verilog’s implicit, “warning: implicit definition of wire ‘…’”.

Warns that the lifetime of a task or a function was not provided and so was implicitly set to static. The warning is suppressed when no variables inside the task or a function are assigned to.

This is a warning because the static default differs from C++, differs from class member function/tasks. Static is a more dangerous default then automatic as static prevents the function from being reentrant, which may be a source of bugs, and/or performance issues.

If the function is in a module, and does not require static behavior, change it to “function automatic”.

If the function is in a module, and requires static behavior, change it to “function static”.

If the function is in a package, it defaults to static, and label the function’s variables as static.

Warns that an import {package}::* statement is in $unit scope. This causes the imported symbols to pollute the global namespace, defeating much of the purpose of having a package. Generally, import ::* should only be used inside a lower scope, such as a package or module.

Warns that a task or function that has been marked with a /*verilator no_inline_task*/ metacomment, but it references variables that are not local to the task, and Verilator cannot schedule these variables correctly.

Warns that an “`include” filename specifies an absolute path. This means the code will not work on any other system with a different file system layout. Instead of using absolute paths, relative paths (preferably without any directory specified) should be used, and +incdir used on the command line to specify the top include source directories.

Warns that a while or for statement has a condition that is always true, and thus results in an infinite loop if the statement ever executes.

This might be unintended behavior if Verilator is run with --no-timing and the loop body contains statements that would make time pass otherwise.

Ignoring this warning will only suppress the lint check; it will simulate correctly (i.e. hang due to the infinite loop).

Warns that the code has a delayed assignment inside of an initial or final block. If this message is suppressed, Verilator will convert this to a non-delayed assignment. See also COMBDLY .

Warns that the combination of selected options may defeat the attempt to protect/obscure identifiers or hide information in the model. Correct the options provided, or inspect the output code to see if the information exposed is acceptable.

Warns that a signal is not assigned in all control paths of a combinational always block, resulting in the inference of a latch. For intentional latches, consider using the always_latch (SystemVerilog) keyword instead. The warning may be disabled with a lint_off pragma around the always block.

Error when a variable is referenced in a process that can outlive the process in which it was declared. This can happen when using ‘fork..join_none’ or ‘fork..join_any’ blocks, which spawn process that can outlive their parents. This error occurs only when Verilator can’t replace the reference with a reference to copy of this variable, local to the forked process. For example:

In the example above ‘local_var’ exists only within scope of ‘foo’, once foo finishes, the stack frame containing ‘i’ gets removed. However, the process forked from foo continues, as it contains a delay. After 10 units of time pass, this process attempts to modify ‘local_var’. However, this variable no longer exits. It can’t be made local to the forked process upon spawning, because it’s modified and can be referenced somewhere else, for example in the other forked process, that was delayed by 20 units of time in this example. Thus, there’s no viable stack allocation for it.

In order to fix it, if the intent is not to share the variable’s state outside of the process, then create a local copy of the variable.

For example:

If you need to share its state, another strategy is to ensure it’s allocated statically:

However, if you need to be able to instantiate at runtime, the solution would be to wrap it in an object, since the forked process can hold a reference to that object and ensure that the variable stays alive this way:

The naming of this warning is in contradiction with the common interpretation of little endian. It was therefore renamed to ASCRANGE . While LITENDIAN remains for backwards compatibility, new projects should use ASCRANGE .

Warns that minimum, typical, and maximum delay expressions are currently unsupported. Verilator uses only the typical delay value.

Warns that the indentation of a statement is misleading, suggesting the statement is part of a previous if or while block while it is not.

Verilator suppresses this check when there is an inconsistent mix of spaces and tabs, as it cannot ensure the width of tabs. Verilator also ignores blocks with begin / end , as the end visually indicates the earlier statement’s end.

For example

To fix this repair the indentation to match the correct earlier statement, for example:

Other tools with similar warnings: GCC -Wmisleading-indentation, clang-tidy readability-misleading-indentation.

Warns that a module has multiple definitions. Generally, this indicates a coding error, or a mistake in a library file, and it’s good practice to have one module per file (and only put each file once on the command line) to avoid these issues. For some gate level netlists duplicates are sometimes unavoidable, and MODDUP should be disabled.

Ignoring this warning will cause the more recent module definition to be discarded.

Warns that the specified signal comes from multiple always blocks, each with different clocking. This warning does not look at individual bits (see the example below).

This is considered bad style, as the consumer of a given signal may be unaware of the inconsistent clocking, causing clock domain crossing or timing bugs.

Ignoring this warning will only slow simulations; it will simulate correctly. It may, however, cause longer simulation runtimes due to reduced optimizations.

Warns that multiple top-level modules are not instantiated by any other module, and both modules were put on the command line (not in a library). Three likely cases:

1. A single module is intended to be the top. This warning then occurs because some low-level instance is being read in but is not needed as part of the design. The best solution for this situation is to ensure that only the top module is put on the command line without any flags, and all remaining library files are read in as libraries with -v , or are automatically resolved by having filenames that match the module names.

2. A single module is intended to be the top, the name of it is known, and all other modules should be ignored if not part of the design. The best solution is to use the --top option to specify the top module’s name. All other modules that are not part of the design will be for the most part, ignored (they must be clean in syntax, and their contents will be removed as part of the Verilog module elaboration process.)

3. Multiple modules are intended to be design tops, e.g., when linting a library file. As multiple modules are desired, disable the MULTITOP warning. All input/outputs will go uniquely to each module, with any conflicting and identical signal names being made unique by adding a prefix based on the top module name followed by __02E (a Verilator-encoded ASCII “.”). This renaming is done even if the two modules’ signals seem identical, e.g., multiple modules with a “clk” input.

Error when a timing-related construct, such as an event control or delay, has been encountered, without specifying how Verilator should handle it (neither --timing nor --no-timing option was provided).

Warns that a feature requires a newer standard of Verilog or SystemVerilog than the one specified by the --language option. For example, unsized unbased literals ( ‘0 , ‘1 , ‘z , ‘x ) require IEEE 1800-2005 or later.

To avoid this warning, use a Verilog or SystemVerilog standard that supports the feature. Alternatively, modify your code to use a different syntax that is supported by the Verilog/SystemVerilog standard specified by the --language option.

Warns that no latch was detected in an always_latch block. The warning may be disabled with a lint_off pragma around the always block, but recoding using a regular always may be more appropriate.

Error when a timing-related construct that requires --timing has been encountered. Issued only if Verilator is run with the --no-timing option.

Warns that a null port was detected in the module definition port list. Null ports are empty placeholders, i.e., either one or more commas at the beginning or the end of a module port list, or two or more consecutive commas in the middle of a module port list. A null port cannot be accessed within the module, but when instantiating the module by port order, it is treated like a regular port, and any wire connected to it is left unconnected. For example:

This is considered a warning because null ports are rarely used, and is commonly the result of a typing error, such as a dangling comma at the end of a port list.

Warns that an instance has a pin that is connected to .pin_name() , e.g., not another signal, but with an explicit mention of the pin. It may be desirable to disable PINCONNECTEMPTY, as this indicates the intention to have a no-connect.

Warns that a module has a pin that is not mentioned in an instance. If a pin is not missing it should still be specified on the instance declaration with an empty connection using (.pin_name()) .

Other tools with similar warnings: Icarus Verilog’s portbind, “warning: Instantiating module … with dangling input port (…)”. Slang’s unconnected-port, “port ‘…’ has no connection”.

Warns that an instance has a pin that is not connected to another signal.

Warns that an instance port or parameter was not found in the module being instantiated. Note that Verilator raises these errors also on instances that should be disabled by generate/if/endgenerate constructs:

In the example above, b is instantiated with a port named x, but module b has no such port. In the following line, b is instantiated with a nonexistent PX parameter. Technically, this code is incorrect because of this, but other tools may ignore it because module b is not instantiated due to the generate/if condition being false.

This error may be disabled with a lint_off PINNOTFOUND metacomment.

Warns that an output port is connected to a constant.

In the example above, out is an output but is connected to a constant, implying it is an input.

This error may be disabled with a lint_off PORTSHORT metacomment.

An error that a package/class appears to have been referenced that has not yet been declared. According to IEEE 1800-2017 26.3, all packages must be declared before being used.

An error that a procedural assignment is setting a wire. According to IEEE, a var/reg must be used as the target of procedural assignments.

Warns that threads were scheduled using estimated costs, even though that data was provided from profile-guided optimization (see Thread Profile-Guided Optimization ) as fed into Verilator using the profile_data configuration file option. This usually indicates that the profile data was generated from a different Verilog source code than Verilator is currently running against.

It is recommended to create new profiling data, then rerun Verilator with the same input source files and that new profiling data.

Ignoring this warning may only slow simulations; it will simulate correctly.

Warning that a ‘pragma protected’ section was encountered. The code inside the protected region will be partly checked for correctness but is otherwise ignored.

Suppressing the warning may make Verilator differ from a simulator that accepts the protected code.

Historical, never issued since version 5.018, when randc became fully supported.

Warned that the randc keyword was unsupported and was converted to rand .

Warns that a real number is being implicitly rounded to an integer, with possible loss of precision.

If the code is correct, the portable way to suppress the warning is to add a cast. This will express the intent and should avoid future warnings on any linting tool.

Warns that the code has redefined the same macro with a different value, for example:

The best solution is to use a different name for the second macro. If this is infeasible, add an undef to indicate that the code overriding the value. This will express the intent and should avoid future warnings on any linting tool:

Other tools with similar warnings: Icarus Verilog’s macro-redefinition, “warning: redefinition of macro … from value ‘…’ to ‘…’”. Yosys’s “Duplicate macro arguments with name”.

Warns that rising, falling, and turn-off delays are currently unsupported. The first (rising) delay is used for all cases.

Warns that a selection index will go out of bounds.

Verilator will assume zero for this value instead of X. Note that in some cases, this warning may be false, when a condition upstream or downstream of the access means the access out of bounds will never execute or be used.

Repaired example:

Other tools with similar warnings: Icarus Verilog’s select-range, “warning: … […] is selecting before vector” or “is selecting before vector”.

Warns that Verilator does not support shortreal , and they will be automatically promoted to real .

The recommendation is to replace any shortreal in the code with real , as shortreal is not widely supported across industry tools.

Ignoring this warning may make Verilator simulations differ from other simulators if the increased precision of real affects the modeled values, or DPI calls.

Warns that an expression has a side effect that might not properly be executed by Verilator.

This often represents a bug in Verilator, as opposed to a bad code construct, however the Verilog code can typically be changed to avoid the warning.

This example warns because Verilator does not currently handle side effects inside array subscripts; the a++ may be executed multiple times.

Rewrite the code to avoid expression side effects, typically by using a temporary:

Warns that a variable with a /*verilator split_var*/ metacomment was not split. Some possible reasons for this are:

The datatype of the variable is not supported for splitting. (e.g., is a real).

The access pattern of the variable can not be determined statically. (e.g., is accessed as a memory).

The index of the array exceeds the array size.

The variable is accessed from outside using a dotted reference. (e.g. top.instance0.variable0 = 1 ).

The variable is not declared in a module, but in a package or an interface.

The variable is a parameter, localparam, genvar, or queue.

The variable is tristate or bidirectional. (e.g., inout ).

Warns that a static variable declared in a loop with declaration assignment was converted to automatic. Often such variables were intended to instead be declared “automatic”.

Ignoring this warning may make Verilator differ from other simulators, which will treat the variable as static. Verilator may in future versions also treat the variable as static.

Warns that the code has a statement with a delayed time in front of it.

This warning is issued only if Verilator is run with --no-timing . All delays on statements are ignored in this mode. In many cases ignoring a delay might be harmless, but if the delayed statement is, as in this example, used to cause some important action later, it might be an important difference.

Some possible workarounds:

Move the delayed statement into the C++ wrapper file, where the stimulus and clock generation can be done in C++.

Convert the statement into an FSM, or other statement that tests against $time.

Run Verilator with --timing .

Warning that a symbol matches a C++ reserved word, and using this as a symbol name would result in odd C++ compiler errors. You may disable this warning, but Verilator will rename the symbol to avoid conflict.

Warns that the specified net is used in at least two different always statements with posedge/negedges (i.e., a flop). One usage has the signal in the sensitivity list and body, probably as an async reset, and the other has the signal only in the body, probably as a sync reset. Mixing sync and async resets is usually a mistake. The warning may be disabled with a lint_off pragma around the net or flopped block.

Error when a call to a task or function has an inout from that task tied to a non-simple signal. Instead, connect the task output to a temporary signal of the appropriate width, and use that signal to set the appropriate expression as the next statement. For example:

Change this to:

Verilator doesn’t do this conversion for you, as some more complicated cases would result in simulator mismatches.

Warns that the number of ticks to delay a $past variable is greater than 10. At present, Verilator effectively creates a flop for each delayed signal, and as such, any large counts may lead to large design size increases.

Ignoring this warning will only slow simulations; it will simulate correctly.

Warns that “`timescale” is used in some but not all modules.

This may be disabled, similar to other warnings. Ignoring this warning may result in a module having an unexpected timescale.

IEEE recommends this be an error; for that behavior, use -Werror-TIMESCALEMOD .

Recommend using --timescale argument, or in front of all modules use:

Then in that file, set the timescale.

Other tools with similar warnings: Icarus Verilog’s timescale, “warning: Some design elements have no explicit time unit and/or time precision. This may cause confusing timing results.” Slang’s: “[WRN:PA0205] No timescale set for “…””.

Warns that the specified signal has no source. Verilator is relatively liberal in the usage calculations; making a signal public, or setting only a single array element marks the entire signal as driven.

Other tools with similar warnings: Odin’s “[NETLIST] This output is undriven (…) and will be removed”.

Warned that due to some construct, optimization of the specified signal or block was disabled.

Ignoring this warning only slowed simulations; it simulated correctly.

Warns that due to some construct, optimization of the specified signal is disabled. The signal reported includes a complete scope to the signal; it may be only one particular usage of a multiply-instantiated block. The construct should be cleaned up to improve simulation performance.

Often UNOPTFLAT is caused by logic that isn’t truly circular as viewed by synthesis, which analyzes interconnection per bit, but is circular to the IEEE event model which analyzes per-signal.

This statement needs to be evaluated multiple times, as a change in shift_in requires “x” to be computed three times before it becomes stable. This is because a change in “x” requires “x” itself to change its value, which causes the warning.

For significantly better performance, split this into two separate signals:

And change all receiving logic to instead receive “xout”. Alternatively, change it to:

And change all driving logic to drive “xin” instead.

With this change, this assignment needs to be evaluated only once. These sorts of changes may also speed up your traditional event-driven simulator, as it will result in fewer events per cycle.

The most complicated UNOPTFLAT path we’ve seen was due to low bits of a bus generated from an always statement that consumed high bits of the same bus processed by another series of always blocks. The fix is the same; split it into two separate signals generated from each block.

Occasionally UNOPTFLAT may be indicated when there is a true circulation. e.g., if trying to implement a flop or latch using individual gate primitives. If UNOPTFLAT is suppressed, the code may get a DIDNOTCONVERGE error. Verilator does not support building flops or latches out of gate primitives, and any such code must change to use behavioral constructs (e.g., always_ff and always_latch ).

Another way to resolve this warning is to add a /*verilator split_var*/ metacomment described above. This will cause the variable to be split internally, potentially resolving the conflict. If you run with --report-unoptflat , Verilator will suggest possible candidates for /*verilator split_var*/ .

The UNOPTFLAT warning may also occur where outputs from a block of logic are independent, but occur in the same always block. To fix this, use the /*verilator isolate_assignments*/ metacomment described above.

Before version 5.000, the UNOPTFLAT warning may also have been due to clock enables, identified from the reported path going through a clock gating instance. To fix these, the clock_enable meta comment was used.

To assist in resolving UNOPTFLAT, the option --report-unoptflat can be used, which will provide suggestions for variables that can be split up, and a graph of all the nodes connected in the loop. See the Arguments section for more details.

Warns that the thread scheduler could not partition the design to fill the requested number of threads.

One workaround is to request fewer threads with --threads .

Another possible workaround is to allow more MTasks in the simulation runtime by increasing the value of --threads-max-mtasks . More MTasks will result in more communication and synchronization overhead at simulation runtime; the scheduler attempts to minimize the number of MTasks for this reason.

Warns that unpacked structs and unions are not supported.

Ignoring this warning will make Verilator treat the structure as packed, which may make Verilator simulations differ from other simulators. This downgrading may also result in what would typically be a legal unpacked struct/array inside an unpacked struct/array becoming an illegal unpacked struct/array inside a packed struct/array.

Warns that the code is comparing an unsigned value in a way that implies it is signed; for example X < 0 will always be false when X is unsigned.

An error that a construct might be legal according to IEEE but is not currently supported by Verilator.

A typical workaround is to rewrite the construct into a more common alternative language construct.

Alternatively, check if other tools support the construct, and if so, please consider submitting a github pull request against the Verilator sources to implement the missing unsupported feature.

This error may be ignored with --bbox-unsup , however, this will make the design simulate incorrectly and is only intended for lint usage; see the details under --bbox-unsup .

Disabling/enabling UNUSED is equivalent to disabling/enabling the UNUSEDGENVAR , UNUSEDPARAM , and UNUSEDSIGNAL warnings.

Never issued since version 5.000. Historically warned that a variable, parameter, or signal was unused.

Warns that the specified genvar is never used/consumed.

Warns that the specified parameter is never used/consumed.

Warns that the specified signal is never used/consumed. Verilator is relatively liberal in the usage calculations; making a signal public, a signal matching the --unused-regexp option (default “*unused*” or accessing only a single array element marks the entire signal as used.

A recommended style for unused nets is to put at the bottom of a file code similar to the following:

The reduction AND and constant zeros mean the net will always be zero, so won’t use simulation runtime. The redundant leading and trailing zeros avoid syntax errors if there are no signals between them. The magic name “unused” (controlled by the --unused-regexp option) is recognized by Verilator and suppresses warnings; if using other lint tools, either teach the tool to ignore signals with “unused” in the name, or put the appropriate lint_off around the wire. Having unused signals in one place makes it easy to find what is unused and reduces the number of lint_off pragmas, reducing bugs.

A SystemVerilog elaboration-time assertion error was executed. IEEE 1800-2017 20.11 requires this error.

To resolve, examine the code and rectify the cause of the error.

A SystemVerilog elaboration-time assertion fatal was executed. IEEE 1800-2017 20.11 requires this error.

To resolve, examine the code and rectify the cause of the fatal.

A SystemVerilog elaboration-time assertion print was executed. This is not an error or warning, and IEEE 1800-2017 20.11 requires this behavior.

A SystemVerilog elaboration-time assertion warning was executed. IEEE 1800-2017 20.11 requires this warning.

Warns that a task, function, or begin/end block is declaring a variable by the same name as a variable in the upper-level module or begin/end block (thus hiding the upper variable from being able to be used.) Rename the variable to avoid confusion when reading the code.

To resolve this, rename the variable to an unique name.

Warns that a wait statement awaits a constant condition, which means it either blocks forever or never blocks.

As a special case wait(0) with the literal constant 0 (as opposed to something that elaborates to zero), does not warn, as it is presumed the code is making the intent clear.

Warns that based on the width rules of Verilog:

Two operands have different widths, e.g., adding a 2-bit and 5-bit number.

A part select has a different size then needed to index into the packed or unpacked array, etc.

Verilator attempts to track the minimum width of unsized constants and will suppress the warning when the minimum width is appropriate to fit the required size.

The recommendation is to fix these issues by:

Resize the variable or constant to match the needed size for the expression. E.g., 2'd2 instead of 3'd2 .

Using '0 or '1 , which automatically resize in an expression.

Using part selects to narrow a variable; e.g., too_wide[1:0] .

Using concatenate to widen a variable; e.g., {1'b1, too_narrow} .

Using cast to resize a variable; e.g., 23'(wrong_sized) .

For example, this is a missized index:

Results in a WIDTHEXPAND warning:

One possible fix:

A more granular WIDTH warning, for when a value is truncated.

A more granular WIDTH warning, for when a value is zero expanded.

A more granular WIDTH warning, for when a value is X/Z expanded.

Warns that based on the width rules of Verilog, a concatenate, or replication has an indeterminate width. In most cases, this violates the Verilog rule that widths inside concatenates and replicates must be sized and should be fixed in the code.

An example where this is technically legal (though still bad form) is:

The correct fix is to either size the 1 ( 32'h1 ), add the width to the parameter definition ( parameter [31:0] ), or add the width to the parameter usage ( {PAR[31:0], PAR[31:0]} ).

Warns that #0 delays do not schedule the process to be resumed in the Inactive region. Such processes do get resumed in the same time slot somewhere in the Active region. Issued only if Verilator is run with the --timing option.

404 Not found

• Digital Systems
• Resource Document: Parameterized Verilog Modules

Parameterized Verilog Modules

Creating more generic and reusable modules.

Introduction

When designing verilog modules, you can add instantiation parameters. These allow the module to be customized when it is instantiated, allowing you to create more reusable code.

Defining Parameterized Modules

Take the example of a register comprised of multiple D-FlipFlops. In some cases, a designiner might need a 32-bit register, a 96-bit register, or even a massive 512-bit register. Instead of writing modules for each different size of register required, in verilog the designer can write a single register module and configure the size when the module is instantiated.

The code shown below is for a 8-bit register with write enable:

A Parameterized Version

To parameterize this design so it can be used for any size of register it can be modified into the following:

When defining a parameterized module, the entires within the parenthesis preceded by a pound sign becomes the parameter list. Typically parameters should be given names with all caps, as this makes it easy to distinguish which variables in the module definition are parameter and which are not. All parameters must be also given a default value, this is so if a module is instantiated without changing a given parameter, there is a fallback value. In the example above, the default size for the register is defined to be 8 bits.

The general form for a parameterized module definition is shown below:

In the module, anywhere a parameter variable is used, it will be replaced with the passed value for that variable. Note that for this module, the bus width of D, Q, and val are given as [WIDTH-1:0].

Instantiating Parameterized Modules

A parameterized module can be configured by passing values when instantiating the module; After the module name but before the instance name, place a pound-sign followed by a pair of parenthesis. Here the parameters of a module can be changed from their defaults. It is best practice to set parameters by using name reference, this also allows you to only change the parameters you need to. As with assigning ports by name, in the parameter list precede the parameter’s name with a period and place its value in the parenthesis following the name. The value given must be constant, it can’t be assigned from another type as the value cannot be known at synthesis time. Following the instance name, the port list can be defined as per usual instantiation.

The general format for setting parameters when instantiating a module is below

Instantiation Examples

Below are some examples of instantiating the register modules defined earlier.

Using Parameters with Generate Statements

The following module is a parameterized shift register with both parameters for bit-width (the width of each register) and depth (number of register stages). It illustrates a more complex use of parameters, as well as being used in conjunction with the generate statement. The use of generate statements and parameters can make very flexible and large circuits with a small amount of code, however care must be taken when using either and especially when using both. Look at the example module and notice the the index calculations for the register interconnects, one small error and the module may fail to synthesize, or make incorrect connections.

Examples of instantiating the given shift register module with different parameters is shown below.

Using Parameters as constant values

The previous examples showed the use of parameters to set the width of a bus and the depth of a shift register. Often you may want to use a parameter to set a constant value that affects the behavior of your module. Some examples are a comparator with one input as a constant value, a counter that rolls over at a value that is not a power of 2, or a register that resets to a specific value. It’s worth remembering that parameters are NOT inputs to your modules; They are constant values passed prior to synthesis and used to determine the resulting circuit.

A Note on Bit-Width

When using parameters as values, bit-widths must be considered; If a constant is being assigned to a wire that has too few bits to contain it, it will be truncated. It is often best to consider the possibility of wildly different values being passed as parameters when a module is instantiated.

Take the example of the module defined below. It is a comparator which compares the single input to the constant parameter. It is written in such a way that the input value can only be 8-bits wide; If the constant value is greater than 255, the ‘less-than’ input will always be high.

A couple strategies to account for the possible bit-width of parameters are discussed below.

Adding a ‘Width’ Parameter

The simplest method is to add an additional parameter stating the width required in the module. This places the responsibility on the user who instantiates the module to provide the necessary width for correct operation.

Using $clog2 to determine width during synthesis

Another way is to calculate the neccessary size when synthesizing the module. For our example, we can use the ceiling of log2(COMP_VAL). Many synthesis tools support the function $clog2() to facilitate this.

Using clog2 works well when you need to calulate the bit-width required to hold/compare a parameter. However as always, when using arithmetic operations consider bit growth and possible truncation of the result.

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verilog rules for bit widths in expressions are subtle and easy to get wrong #219

cbiffle commented May 3, 2017 • edited

Cbiffle commented may 3, 2017.

Sorry, something went wrong.

christiaanb commented May 3, 2017

No branches or pull requests