[vhdl-200x] Standard Package enhancements

From: Daniel Kho <daniel.kho@gmail.com>
Date: Thu Apr 16 2015 - 05:06:31 PDT
Hi all,
There are a few enhancements I would like to propose for some of our
standard packages. Do let me know what you think.

standard.vhd:
    type BOOLEAN_VECTOR is array (INTEGER range <>) of BOOLEAN;
    type BIT_VECTOR is array (INTEGER range <>) of BIT;
    type INTEGER_VECTOR is array (INTEGER range <>) of INTEGER;
    type REAL_VECTOR is array (INTEGER range <>) of REAL;
    type TIME_VECTOR is array (INTEGER range <>) of TIME;

Propose to change the ranges from (natural range <>) to (integer range <>).
I notice that quite often I have to change my types to std_ulogic* types
because the ranges can't be made negative. Just to give you an example. I
have a signal declared like this (it's a bundle of flags which gets
outputted from some computational operation):
    flags: out boolean_vector(-8 to 8);

Because boolean_vector can't support negative ranges, I had to change this
to std_ulogic_vector or unsigned instead.

Have type conversion functions, or better, make conversions implicit
between the following types:
    boolean <-> bit
    boolean <-> std_ulogic
    boolean_vector <-> std_ulogic_vector
    boolean_vector <-> bit_vector
    boolean_vector <-> unsigned

I wrote to_stdulogic and to_stdulogicvector functions for these, and can
share them if there's a place for me to deposit the source.

I feel it convenient and clear to use boolean / bit types for RTL design,
especially for flags and indicators. However, I also want to play it safe,
so I would like a way to force my compilation to fail when I accidentally
drive my flags from multiple sources, hence the suggestion for unresolved
types for boolean/bit.
    type unresolved_boolean is (false, true);
    type unresolved_bit is ('0', '1');

    alias u_boolean is unresolved_boolean;
    alias u_bit is unresolved_bit;

    subtype boolean is resolved u_boolean;
    subtype bit is resolved u_bit;

    type u_boolean_vector is array(integer range <>) of u_boolean;
    type u_bit_vector is array(integer range <>) of u_bit;
    subtype boolean_vector is (resolved) u_boolean_vector;
    subtype bit_vector is (resolved) u_bit_vector;


Another thing is regarding the "abs" function in numeric_std. I feel it
awkward to have to keep type casting my signals back to unsigned even after
performing an "abs" on my signed number. Wouldn't it make more sense for
"abs" to return an unsigned value instead of a signed value? Yes, the
inputs into "abs" must be signed, but it makes more sense that the returned
output be automatically made unsigned.

So, if I have an unsigned signal "sig", this assignment would be valid:
    signal sig: unsigned(15 downto 0);
    signal computed: signed(15 downto 0);

    sig <= abs(computed);

and no type casting should be needed. Currently, the following is needed:
    sig <= unsigned(abs(computed));

I know this would break legacy code, but I feel it's a good thing to have
for the next LRM revision. People usually clean up their code when porting
over to tools supporting newer language versions anyway. Also, it makes new
code cleaner, clearer, and less confusing.

What do you think?

Best regards,
Daniel

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Apr 16 05:07:17 2015

This archive was generated by hypermail 2.1.8 : Thu Apr 16 2015 - 05:08:15 PDT