Linting in VLSI is the process of checking the program code (static code analysis) against a set of design rules and generating a report with all details of violations.
After the compilation and elaboration step, the design will be free of syntax errors. However, still all the design rules need not be satisfied. Lint is now the solution to this. In order to have our design to be completely synthesizable, correcting lint errors are essential.
Synopsys Spyglass Tool is a popular industry standard tool used to perform Linting on Verilog HDL code. Cadence HAL is one another such tool.
The lint report may be large and will consist of various criterions of design violations. However, let us look at some of the major violations:
- Combinational Loops
- Inferred Latches
- Multi-driven signals
- Width Mismatches
- Undriven Inputs
1. Combinational Loops
Combinational loops are strictly not allowed in Verilog. Example of a combinational loop snippet:
always @ *
a = a & b;
a = a & b;
This computes the AND operation of a with b and sends it back to a. This will lead to an infinite loop, completely occurring at zero simulation time.
Incase, we really need to perform this operation, we need to use non-blocking assignments.
always @ (posedge clock)
a <= a & b;
This ensures that a AND b is computed first, and then updated to a only in the next clock cycle.
Each clock cycle, a AND b is computed and the result is updated in a in the following clock cycle.
Each clock cycle, a AND b is computed and the result is updated in a in the following clock cycle.
2. Inferred Latches
Inferred latches is a major issue that can possibly cause the design to malfunction.
This happens when the Verilog code does not account for the value held by a variable at certain times.
It occurs due to incomplete usage of certain constructs.
Example:
1. If condition without else block
always @ (posedge clk)
if (a > b)
c <= a;
If this is all the given code, how do we know what happens to c when a > b condition fails?
This is called inferred latches when the tool infers that under such circumstances, the previous value of the variable is maintained.
To avoid the tool making such an inference, it is always desirable for the designer to explicitly mention what happens in such a case. Even if the value is maintained, it can be explicitly coded as shown:
always @ (posedge clk)
if (a > b)
c <= a;
else
c <= c;
This will ensure that the latches are not 'inferred' by the tool.
3. Multi-Driven Signals
Multi-driven signals are also forbidden in Verilog. When the same signal is driven with multiple values at the same time instant, it becomes multi-driven and causes undesired outputs to occur, usually in simulations it goes to a don't care (x) state.
Example:
always @ (posedge clk)
if (a > b)
c <= a;
c <= b;
else
c <= c;
As can be seen above, the same signal c is simultaneously trying to obtain the value of a as well as b. This is not allowed. At a particular clock cycle, we can drive the signal c with only one value, either that of a or that of b.
4. Width Mismatches
This is one of the more common issues that can be discovered only by lint. Mismatches in the width of signals being used on LHS as well as RHS.
As a simple example:
wire [3:0] a;
wire [7:0] b;
assign a = b;
This will cause a width mismatch. The width of signal a is 4-bits while the width of b is 8-bits.
When you assign b to a, a will be able to store only the least significant 4-bits of b, ie., b[3:0].
The remaining 4-bits of b will be lost.
Hence to avoid potential data loss, it is advised to ensure that the signals used in the LHS as well as RHS of an expression is of the same width.
5. Undriven Inputs
This situation occurs when one or more inputs used in a module is not being driven externally.
If the input is not being driven, then the design may not work as expected.
The above points are just few examples of violations flagged by lint that need to be noted. Many others can be added to this lint depending on the design requirement.
Tcl Shell Commands using Spyglass
The above image shows the Spyglass GUI Window, but we can utilize the tool more easily using Tcl scripts.
Let us now see how we can invoke the Spyglass Tool using Tcl commands.
1. Create a new project
new_project command is used to create a new project.
Usage: new_project project_name
2. Read required files
read_file command is used to read the design files. It comes along with a -type argument.
Consider you are reading a single file example_design.v
Usage: read_file -type verilog example_design.v
(Note: Ensure that you mention the full path of example_design.v if not in current folder)
To read a heirarchy of files specified in a filelist, we use:
read_file -type sourcelist filelist
We might need to add waivers to waive off certain violations. For waivers mentioned in a TCL file, the command to read that would be:
read_file -type awl waivers.tcl
The waivers.tcl file would look something like this:
#whatever rule you want to waive is mentioned in brackets, along with msg and optional comment
waive -rule {W287b} - msg { } - comment {waivable}
waive -rule {W415a} - msg { } - comment {waivable}
Sometimes you might have some design constraints like setting clock and reset values, and you might need to read those as well.
Such design constraints are saved in a .sgdc file and are read using:
read_file -type sgdc constraints.sgdc
Once the desired files are read, proceed with the next step.
3. Set desired options
set_option command is used to set custom options for the run. Example:
For a hierarchy of files, we can set the top module using: set_option top topmodule
There are a number of arguments available for the set_option command that can be explored using the Spyglass userguide.
Another usage: set_option handlememory true can be used to handle memories in an optimized manner.
4. Perform the desired run
run_goal command to perform the desired run.
In order to perform lint, we use the command like this:
run_goal lint/lint_rtl
5. Save and Exit
At the end, use the following command to save the project before exiting:
exit -save
These commands can be saved in a Tcl file, and should be enough to invoke the tool and run the selected goal (lint) on the desired files.
The spyglass reports will be in the following path:
'your design path'/lint/lint_rtl/spyglass_reports
The moresimple.rpt will contain a summary report of all lint violations.
With this, we conclude the topic on Lint and its analysis using Spyglass Tool.
Refer the Spyglass tool documents for more information.
References:
Spyglass Lint User Guide
No comments:
Post a Comment