I am sure you have heard this phrase before – “A sledgehammer to crack a nut”; the below picture describes it all!
Would you use a HUGE hammer to crack a small, tiny nut?
(If you are further interested in this phrase read: http://www.phrases.org.uk/meanings/sledgehammer-to-crack-a-nut.html).
I recently had a small design error introduced in a piece of RTL as below: It is an interrupt masking logic, code snippet as below:
Note the use of “ANDing” logic – simply, AND- mask with data to produce result.The subtlety in Verilog/System Verilog is that you have 2 seemingly similar operators for doing AND operation;
- The logical AND: &&
- The bitwise AND: &
Given the “loose” data type checking, assignment rules etc. one can get away by using either one of the above many-a-times. In the above case the user used:
result = data && mask;
With result being a vector the above is a “logical/design error” but usually a Verilog compiler would let this go through (as it is not an error as per LRM).
Now one can “verify” this by writing a testbench, simulate, look at waveform and debug. Depending on luck and the expertise of the engineer, it could take some 30-minutes to few hours. But as a Verification power-house CVC suggests to rethink – use the right tool/technology for the right class of design errors. These are things that are very easy for a static verification technology such as HDL-Linting to flag in less than a minute.
For instance, let’s try the above code with a popular Linter – ALINT from Aldec (http://www.aldec.com/products/alint/).
ALINT has nice rule sets pre-packaged for various policies such as STARC (http://www.starc.jp/index-e.html). It produces the following:
This will trigger 2 rules:
- rule about logic operation having a vector operand
- rule about bit width mismatch in the assignment – LHS vs RHS.
ALINT: Warning: test.v : (4, 1): Module “top”. “STARC_VLOG.2.1.4.5″ Logical operator has vector argument(s). Use bit-wise operators for multi-bit arguments and logical operators only for 1-bit arguments. Level: Recommendation 1.
ALINT: Warning: test.v : (4, 1): Module “top”. “STARC_VLOG.2.10.3.4″ Assignment source bit width “1″ is less than destination bit width “8″. Upper bits of the right-hand side will be filled with zeroes. Match bit widths exactly to improve the readability of the description. Level: Recommendation 2.
Now from a business perspective too – this is a far better option for your management – usually LINT tools are far cost efficient than full blown SystemVerilog simulator(s) such as Aldec’s Riviera-Pro http://www.aldec.com/Riviera
So next time when you receive a RTL code to verify, do yourself a favor by running a quick Lint run before looking for “hard bugs” that demand popular, powerful techniques such as Constrained-random, coverage-driven, UVM based etc.
BTW – CVC offers training sessions (http://www.cvcblr.com/trainings) on Aldec’s ALINT and HDL-Lint in general. Contact us (http://www.cvcblr.com/about_us) to see how we can help your teams!
Happy Verification ahead!
