Reposting to reflector since this bounced
-------- Original Message --------
Subject: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]
Date: Fri, 26 Feb 2010 16:13:19 +0100
From: Jonas Nilsson <Jonas.Nilsson@synopsys.com>
To: Jones, Andy D <andy.d.jones@lmco.com>, 'Jarek Kaczynski'
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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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.Received on Fri Feb 26 11:20:27 2010
This archive was generated by hypermail 2.1.8 : Fri Feb 26 2010 - 11:25:11 PST