RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]

If you use the sfixed and ufixed data types for large integer representations this is going to be slower than defining an integer data type due to the sfixed and ufixed base data type is std_logic which is a multi-value logic level. If you have a sfixed(127 downto 0) and ufixed(3 downto -125) and convert these to a integer data type VHDL will generate a error due to the size of the above sfixed and ufixed require more than 32-bits that VHDL defines for integer types. I would like to have a mechanism where I can define large integers (signed and unsigned) and can convert sfixed, ufixed, and float types to without VHDL generating a error due to exceeding 32-bits to attempt to see a integer view of the bits. I would like to define integer subtypes than can be larger than 32-bits, i.e.

subtype uint32 is natural range 0 to 2**32;
subtype int64 is integer range 2**-31 to (2**31 - 1);
subtype bigint is integer range 2**-74 to (2**74 - 1);

For viewing the integer (signed or unsigned) view of sfixed, ufixed, and float data types, I would expect the tools to fit the data type to the appropriate native CPU integer type for speed since the C/C++ languages (assuming the VHDL tools are written in these languages) natively support signed/unsigned 8-bit, 16-bit, 32-bit, 64-bit integer sizes. For any value more than the largest native machine size, VHDL should utilize a big integer data type to allow representing of that integer type. This should prevent making the conversion to/from a integer from any data type with a std_logic base type error out when 32-bits is exceeded for signed or 31-bits for unsigned.

The work around to view the integer for the sfixed, ufixed, and float data types that exceeds the 32-bit integer is to strip off the binary point and then convert the value to a real using the to_real() function. The real version of the integer now creates more issues the designer now has to be aware of due to being a floating point value.

Scott D. Hoy
E-mail: scott.hoy@itt.com
Phone: 301-497-9900 Ext. 7162
Fax: 301-497-0207
 
ITT-AES
141 National Business Pkwy. Suite 200
Annapolis Junction, MD 20701
Phone: 301-497-9900 Fax: 301-497-0207

-----Original Message-----
From: Jones, Andy D [mailto:andy.d.jones@lmco.com]
Sent: Thursday, February 25, 2010 2:11 PM
To: Hoy, Scott - IS; 'Jim Lewis'; 'vhdl-200x@eda.org'
Subject: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]

The current standard requires at least 32 bit signed (well almost, the most negative 32 bit signed number is not actually required!), but allows vendors to support more. Almost all vendors support either the minimum standard, or full 32 bit signed, and that's it. Why don't we just increase the required minimum standard to 64, 128, 256, ... (?) bit signed integers? Go beyond 256, and you will start to get diminished simulation performance returns due to having to carry around 256+ bits whether you use them or not. And simulation performance is one big reason to use integers in the first place (in addition to usage semantics).

The way the fixed point package is set up almost gets you the usage benefits of integers (e.g. when 0 fractional bits are used), especially WRT lossless intermediate results in expressions, but it still requires the manual resizing for storage. I know the issue of overloading assignment operators is a hot-button issue, but in this case, where the numerical interpretation of the bits is well-understood, it sure would be nice to have automatic resizing (and even sfixed/ufixed conversion) upon assignment (with assertions upon numerical loss, just like integers have). Of course, the ufixed subtraction operator would have to promote the results to sfixed (why does ufixed subtraction bump the size by one, but not promote to sfixed?).

Of course the downside (other than manual resizing and promotion to signed) of the fixed point package is simulation performance, relative to integers. For simulation performance, maybe a hybrid approach would work? Instead of unconstrained arrays of bits, we could use unconstrained arrays of integer (whatever integer will be?). Of course you'd give up meta-values too, but it would be worth it for the performance improvement.

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control Dallas TX

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Hoy, Scott - IS
Sent: Thursday, February 25, 2010 9:30 AM
To: Jim Lewis; vhdl-200x@eda.org
Subject: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]

How about a large integer/big decimal package?

I have been bitten a few times on overflowing the range of an integer in VHDL in some functions in DSP libraries I have built that can overflow 32-bit integer conversions pending on settings. As an example, I have a generic numerically controlled oscillator (NCO) with frequency sweep control that, pending on user constraints, can trip a VHDL error due to exceeding the size of the integer type. I have a work around to get by this but a large integer would be very useful in this case. It would also be useful to be able to create an unsigned 32-bit integer subtype which is currently prohibited due to the requirements on the current VHDL integer types and subtypes. This and larger integer sizes would be useful in CPU modeling. This would allow VHDL to have integer data types that can be identical to the size of the C/C++ integer types. I would expect the user would be required to define the range of such an integer and that synthesis tools should be able to synthesize it due to requiring a range definition.

If VHDL currently has the ability to do this, I would like to know. From the VHDL documentation I have read, the integer types are limited to 32-bits for signed, 31-bits for unsigned.

Regards,

Scott D. Hoy
E-mail: scott.hoy@itt.com
Phone: 301-497-9900 Ext. 7162
Fax: 301-497-0207

ITT-AES
141 National Business Pkwy. Suite 200
Annapolis Junction, MD 20701
Phone: 301-497-9900 Fax: 301-497-0207

-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jim Lewis
Sent: Tuesday, February 23, 2010 10:13 AM
To: vhdl-200x@eda.org
Subject: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]

-------- Original Message --------
Subject: [Accellera:vhdl] Time to start up?
Date: Mon, 22 Feb 2010 09:18:24 -0600
From: Lance Thompson <lancet@us.ibm.com>
To: vhdl <vhdl@lists.accellera.org>

Hi everyone,

In the immortal words of Roger Waters of Pink Floyd fame, "Is there anybody out there?"

It's been a while since we released revision of VHDL to the IEEE and took it through the ballot process to come out with 1076-2009. If my memory is correct, we released it the IEEE early in 2008 and the IEEE finished the ballot process at the end of 2008 or very early in 2009.
  At that point, I imagine everyone took a well deserved break from the VHDL standardization activity. I know I did :-)

Since it's been around 2 years since we worked on details of the language, I started to wonder if we should warm up the group and start to drive any new changes to the language.

Any ideas?

Lance Thompson
IBM Technology Development
e-mail: lancet@us.ibm.com
office: 507.253.0145
mobile: 507.261.3607

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787
Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender.
Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail.
--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.