Sledgehammer to crack a nut? – Use right tools for right class of design errors/bugs

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:

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;

  1. The logical AND: &&
  2. 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 (

ALINT has nice rule sets pre-packaged for various policies such as STARC ( 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.″ 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.″ 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

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 ( on Aldec’s ALINT and HDL-Lint in general. Contact us ( to see how we can help your teams!

Happy Verification ahead!