Re: [vhdl-200x] Modular types, alternative solutions

From: Ray Andraka, Andraka Consulting Group, Inc <ray@andraka.com>
Date: Wed Oct 29 2014 - 04:05:41 PDT
> I'd like to understand why array of numeric_std is awkward for
> large tables.  I think that decimal bit-string literals (when
> available) should improve the situation.

Numeric_std, in its current form as implemented by vendors doesn't
allow you to express it as a list of integers, rather it needs to be
vectors of the appropriate type.  This makes importing a list of integers,
say from Matlab or a list of filter coefficients awkward because you
then need to add conversions for every element.  That precludes
simply copying and pasting a list of integers.  It also makes
the list more difficult to comprehend to the human eye.  I'm talking
about large tables such as sin/cosine tables, large FIR filter coefficient
tables and things like that.

>
> > While I agree the long integer
> > issue  is mostly a vendor issue, the fact that there is not an
> > explicit long integer type in the standard
> > makes longer than 32 bit integers risky due to sporadic and not
> > required support for them.
>
> I see the point.  But I am not sure that having a standard 64 bit
> situation would magically change the vendor implementation.  I still
> think that user requests are a better way to change vendor
> implementation.

No, it won't magically change it, but if there is a standard then it becomes
a lot easier to ask a vendor for it and expect to have consistency from
vendor to vendor if/when a vendor does implement it, and the vendor
has an industry standard to claim to adhere to.


>
> > I generally do use numeric_std for description of the logic, and
> > usually in my test benches.  You do
> > have to convert to/from integer to get access to the ieee.math_real
> > library in order to get to the
> > trig and other math functions for use in a testbench, and there the
> > 32 bits can become an issue as well.
>
> I don't really understand here.  ieee.math_real is mostly about the
> real type.  Why do you need to convert from/to integer ?  Is it
> because you are using numeric_x for fixed point ?

Yes, most of my work is fixed point, and I predominantly use numeric_std
for the hardware implementation.  I use integer types for passing tables
through generics because arrays of numeric_std have not been consistently
supported across vendors to the extent arrays of integers have for generics.

I use math_real and integer types in testbenches to speed up the processing
and to get access to the real math functions, which then need to convert 
first
to integer then to numeric_std in order to match the std_logic_vector ports
on the UUT.


>
> Tristan.
>


-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

   "They that give up essential liberty to obtain a little
    temporary safety deserve neither liberty nor safety."
                                            -Benjamin Franklin, 1759
  


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Oct 29 04:06:19 2014

This archive was generated by hypermail 2.1.8 : Wed Oct 29 2014 - 04:06:33 PDT