RE: [vhdl-200x] Standard Package enhancements

Hi Daniel,

Please see my comment inlined.

Regards,
dhiRAj

From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Daniel Kho
Sent: Thursday, April 16, 2015 5:37 PM
To: vhdl-200x@eda.org
Subject: [vhdl-200x] Standard Package enhancements

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;
[dhiRAj]: Yes, I don’t see any harm in this rather it will give increase the memory size by 2X( integer range ~= 2 of natural range)
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
[dhiRAj] Do we want to go from strict type check to relax type check like System Verilog? I assume that we don’t want to relax type checking so instead of going for implicit, we can have conversion function for this.
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));
[dhiRAj]: This make sense as when user is calling ‘abs’, user intention is more on value holding in signal not the value with type(signed/unsigned).

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<http://www.mailscanner.info/>, and is
believed to be clean.


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.