Introduction
The main purpose of HDL languages is to describe a design to be synthesized and implemented in hardware. However, both VHDL and Verilog also provide additional features for writing verification code to check a design by simulating its behavior. In order to do so, you can write testbenches that provide stimulus to DUT inputs and assert whether their outputs have unexpected values. More sophisticated language constructs can be used to do more complex checks. The problem with such verification code is that it’s not synthesizable.
You should not use this verification subset of language features in an actual design. For better synthesis Quality of Results (QoR), you should also follow many other rules. However, since these rules only apply to a synthesizable design, there’s usually no need to restrict oneself to following them in verification code.
To provide better feedback, Sigasi Visual HDL (SVH) detects what parts of the code are supposed to be synthesizable and verifies synthesis rules for that code. In order to do so, it detects a description style for design units as one of the following:
- Testbench - top level verification module
- Behavioral - additional design units that are supposed to be used for verification purposes
- RTL - design units that are part of an actual design to be synthesized
SVH allows you to specify a different severity for rules in RTL and non-RTL (testbench or behavioral) code.
It’s also possible to disable some checks for RTL or non-RTL code by setting the corresponding severity to ignore
.
VHDL
In VHDL, a description style is detected for every architecture, either by detecting verification code or based on architecture names.
The detecting verification code method is the default. In this case, an architecture is detected as:
- Testbench, if the corresponding entity does not have any ports, otherwise
- Behavioral, if it
- contains non-synthesizable processes, e.g., no sensitivity list or multiple wait statements
- uses the
std.textio
package or declares file types
- RTL, in all other cases
This mechanism provides good results in most cases. However, if you require more fine-grained control, you can choose to detect the description style based on architecture names, in which case you have to specify name patterns to be matched against them. An architecture is then detected as:
- RTL, if its name matches the valid pattern and does not match the invalid pattern, otherwise
- Testbench, if the corresponding entity does not have any ports, or
- Behavioral, in all other cases
Verilog
For now, there are no rules that would benefit from a design unit description style, so no detection of description styles is performed.