Open side-bar Menu
 Real Talk
Jim Foley, Director of R&D, Real Intent
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.

Related posts:

2 Responses to “Ascent Lint Rule of the Month: NULL_RANGE”

  1. JimLewis says:

    Do you have a name based methodology to ignore flagging errors on null ranges.

    In OSVVM, CoveragePkg uses a null ranged object, however, I always name these NULL_*. For example:

    constant NULL_BIN : CovBinType(1 to 0) := (others => ( BinVal => ALL_RANGE, … )) ;

    This allows inputs of some methods (procedure in a protected type optional). The following declaration of AddCross, requires at least two CovBinType inputs, however, by initializing the others with the NULL_BIN, the remaining 18 inputs are optional and since I can check for a NULL range value, they are easy to detect.
    procedure AddCross(
    AtLeast : integer ;
    Bin1, Bin2 : CovBinType ;
    Bin3, Bin4, Bin5, Bin6, Bin7, Bin8, Bin9, Bin10, Bin11, Bin12, Bin13,
    Bin14, Bin15, Bin16, Bin17, Bin18, Bin19, Bin20 : CovBinType := NULL_BIN
    ) ;

    I do note that the VHDL compiler I use throws a warning everytime this package is compiled.

    I also use them in parametrized code a some.

  2. Jim Foley, Director of R&D, Real Intent Jim Foley, Director of R&D, Real Intent says:

    Hi Jim,

    As the CoveragePkg is used to measure code coverage, and is not
    intended as part of the logic of the design, it might be best to
    waive the entire CoveragePkg package, to avoid all lint violations
    that are designed to check for synthesizable RTL.

    But otherwise, yes, you can waive by a substring or pattern match
    to block reporting of a specific instance of a violation by name.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

S2C: FPGA Base prototyping- Download white paper

Internet Business Systems © 2016 Internet Business Systems, Inc.
595 Millich Dr., Suite 216, Campbell, CA 95008
+1 (408)-337-6870 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy Policy