Regardless of the subtype, VHDL promotes the results of operators, expressions, etc. to the full length of the base type. Simulation storage is not decreased for smaller subtypes either. So extending the base type and making integer a subtype would not increase performance in simulation.
If your design is dependent upon the LRM minimum acceptable range of integer not increasing, then you have a problem, because any simulator or synthesis tool today is free to implement a larger integer than the LRM standard (some already do, to the full 32 bit two's complement range).
Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX
From: Jonas Nilsson [mailto:Jonas.Nilsson@synopsys.com]
Sent: Friday, February 26, 2010 9:13 AM
To: Jones, Andy D; 'Jarek Kaczynski'; 'Ray Andraka, Andraka Consulting Group, Inc'
Cc: 'Hoy, Scott - IS'; 'Jim Lewis'; 'vhdl-200x@eda.org'
Subject: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]
Andy wrote:
Ø If you create a separate, longer type you have the overhead of type conversions, duplicate (quadruplicate?)
How about redefining INTEGER as a subtype of a new larger base type with a different name?
Ø Type conversions won't be needed
Ø Less compatibility issues for old code
Ø Existing code using INTEGERS could be optimized to use 32 bits by simulators/synthesis tools
(at least for storage, maybe not for intermediate results in expression evaluations)
Can you guys with more in-depth knowledge of the
language find any significant drawbacks with this?
INTEGER'BASE_TYPE will not be INTEGER anymore, but I don't think
I've ever seen this attribute used with INTEGER or it's subtypes.
Regards,
Jonas Nilsson
Technical Staff
Synplicity Business Group
Synopsys, Inc.
Kalkstensvägen 3
SE-224 78 LUND
SWEDEN
Phone : +46-46-16 29 04
Fax : +46-46-16 29 01
E-mail: jonas@synopsys.com<mailto:jonas@synopsys.com>
web : www.synopsys.com<http://www.synopsys.com> / www.synplicity.com<http://www.synplicity.com>
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jones, Andy D
Sent: Thursday, February 25, 2010 9:46 PM
To: 'Jarek Kaczynski'; 'Ray Andraka, Andraka Consulting Group, Inc'
Cc: 'Hoy, Scott - IS'; 'Jim Lewis'; 'vhdl-200x@eda.org'
Subject: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]
I don't see how extending the minimum required range of the base integer type would cause compatibility problems. The language already explicitly allows it, just nobody implements it.
If you create a separate, longer type you have the overhead of type conversions, duplicate (quadruplicate?) operator definitions to support mixing it with "standard" integer, etc. Yuck. All those different integer types work in C only because C is so loosely typed.
I don't really think the simulation overhead would kill you out to probably 256 bits (signed) or so, and simulation speed would hardly be "crippled" considering the alternative: signed or sfixed (255 downto 0), or even (31 downto 0). A 256 bit integer will still be faster than a 4 bit signed/sfixed.
Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX
Cell: 817-422-3124
From: Jarek Kaczynski [mailto:jarekk@aldec.com]
Sent: Thursday, February 25, 2010 1:57 PM
To: Ray Andraka, Andraka Consulting Group, Inc
Cc: Jones, Andy D; Hoy, Scott - IS; Jim Lewis; vhdl-200x@eda.org
Subject: Re: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]
Adding new type with higher size requirements is probably better idea than changing the current definition (mainly for compatibility reasons).
Calling the longer type 'long integer' may confuse some users due to clash with C integer types:
C integer: 16-bit or more
C long integer: 32-bit or more
C long long integer: 64-bit or more
Current VHDL integer is pseudo-32-bit (due to symmetrical value range - can we change it?). All simulators I have used let you extend this incomplete range to the full 2's complement range if you specify '-relax' switch or something similar, maybe we should sanction it...
Adding new integer type with at least 64-bit value range seems reasonable: all VHDL simulators must support such type internally anyway, just to handle all required values of TIME type.
Standardizing longer integer types may trigger resistance: if I remember correctly, even on 64 MPUs there is a performance penalty while doing 128-bit arithmetic operations. Simulator vendors may not want support data type that cripples simulation speed.
And one more remark: I'm definitely for the revival of work VHDL standard update. Let's show the community that _not_ the entire world revolves around SystemVerilog...
Jerry Kaczynski
On Thu, Feb 25, 2010 at 11:22 AM, Ray Andraka, Andraka Consulting Group, Inc <ray@andraka.com<mailto:ray@andraka.com>> wrote:
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> [mailto: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<mailto: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<mailto: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> [mailto: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<mailto: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<mailto:lancet@us.ibm.com>>
To: vhdl <vhdl@lists.accellera.org<mailto: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<mailto:lancet@us.ibm.com>
office: 507.253.0145
mobile: 507.261.3607
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com<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<mailto: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. -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Feb 26 10:52:23 2010
This archive was generated by hypermail 2.1.8 : Fri Feb 26 2010 - 10:57:42 PST