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

I also run into this issue frequently. Another possible approach
would be to add a long int type rather than modifying the existing
integer type.

At 02:10 PM 2/25/2010, Jones, Andy D wrote:
>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.

--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.