Jim Foley, Director of R&D, Real Intent
Jim Foley, prior to his role as R&D Director at Real Intent, was Head for Power Analysis Products at Sequence Design, and has held product management and development roles at Cadence Design Systems. Jim received a BS in Electrical Engineering from Worcester Polytechnic Institute. Go Engineers!
Ascent Lint Rule of the Month: NULL_RANGE
April 18th, 2013 by Jim Foley, Director of R&D, Real Intent
In recent postings I’ve been writing about the nits and details of the semantics of Verilog, so, in the interest of balance, it’s appropriate to spend some time on VHDL as well.
VHDL has a stronger type system than Verilog, and is rather more explicit in how logic is specified, so you might think that that VHDL is less prone to legal but unintentionally incorrect modeling. It turns out that VHDL has coding gotchas of its own that are different from the ones in Verilog and SystemVerilog.
When you specify a subrange for a type or data declaration, it’s necessary to specify the direction using either ‘to’ or ‘downto’:
signal aa : std_logic_vector(7 downto 0); — descending range, use ‘downto’
signal bb : std_logic_vector(16 to 31); — ascending range, use ‘to’
What happens if you specify the direction using the wrong keyword?
generic ( THREE : integer := 3 … ) …
signal cc : std_logic_vector(THREE to 0);
The subrange bounds are descending, but the direction ‘to’ specifies an ascending range.
You might think that the compiler will report this as an error. Or perhaps it will silently correct the problem, with the understanding that if the range bounds are descending, then you must have really meant ‘downto’ instead of ‘to’. As it turns out, the compiler will go forth and process this as a “null range”, meaning a range containing no elements. A null range seems to have little use for hardware. At best, it’s a rather roundabout and verbose way of specifying nothing. A VHDL simulator, however, is perfectly happy with it, calculating a null range and passing it along as a perfectly valid result of an operation, where it may, or may not, cause some problem in a result downstream.
If you’ve coded a model that includes a null range, it’s very likely a coding error, in spite of it having a valid and legal simulation semantic in VHDL. Lint can point out where and under what conditions the null range occurs, so you can review it and fix the problem, or at least consider whether the empty vector you’ve created can be coded in a less obscure way. This is an example where linting shows its value in catching coding gotchas even in strongly typed VHDL.