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