Hi,
The subtype idea is great, though I would also like the library to include these as primitives. Well, this is just my personal opinion.
I've created and used 'byte' and 'nibble' as special subtypes in my own package, though I wish those types were included as primitives. I guess adding 4-bit, 8-bit, 16-bit, and 64-bit types would be a good idea. I'm in favor of adding new primitives like nibble, byte, word, dword (or int32), int64 or uint64. Also, I'd like to see vector primitives for those, such as byte_vector, word_vector, etc. similar to std_logic and std_logic_vector.
If anyone needs a special less-used type, say for example a 12-bit datatype, they can still declare their own subtype.
I would also like to see simpler type conversions, similar to what you guys did sometime ago for direct conversion of hex to std_logic_vector [e.g.: s: std_logic_vector(7 downto 0) := x"5b"].
Anyway, I have a question I'd like to ask. Current synthesizers (the ones I know of) seem to not be able to recognize 3D array structures as memory. I had the following in my package:
type ram_vector is array(natural range <>) of std_logic_vector(dataWidth-1 downto 0);
type ram_matrix is array(natural range <>) of ram_vector(patternLength-1 downto 0);
shared variable patternData_vector:ram_vector(2**addressWidth-1 downto 0):=(others=>(others=>'0'));
shared variable patternData_matrix:ram_matrix(2**addressWidth-1 downto 0):=(others=>(others=>(others=>'0')));
Currently, the synthesizers I've seen recognizes patternData_vector as RAM blocks; the tools manage to synthesize the structure into memory blocks in an FPGA (not too sure about ASIC or synthesis tools from Mentor/Synopsis for FPGAs), but they fail to recognize patternData_matrix as a memory structure. I'm not sure if anyone knows of a tool that is able to recognize 3D array structures like this one as memory? Or am I missing something?
Regards,
Daniel
________________________________
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jonas Nilsson
Sent: Thursday, March 04, 2010 3:17 PM
To: Wolfgang.Ecker@infineon.com; paul.butler@ni.com; vhdl-200x@eda.org
Subject: RE: Re: [Fwd: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]]
I like the subtype idea better than just increasing the
minimum range to 64 bits or adding new formal base types.
Using subtypes would introduce subtle differences from the current
definition, one being that INTEGER would no longer be a base type. I
don't see this as a big problem. I don't know the language details that
well to be able to identify other issues.
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 Wolfgang.Ecker@infineon.com
Sent: Wednesday, March 03, 2010 7:32 PM
To: paul.butler@ni.com; vhdl-200x@eda.org
Subject: AW: Re: [Fwd: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]]
Hi,
Since VHDL only requires a minimum value range, a bigger range is not forbidden.
Using new integer types as int32, int64, uint32, and uint64 would be the clearest option in my opinion.
Declaring them - and todays integer - as a "superinteger" subtype would not contradict with the current paractice. Type conversion can be omitted but assignment of those values to integer
need range checking.
By the way, the synthesis tools synthesize an integer to a full 32-bit variable without value restrictions.
Regards and all the best,
- Wolfgang, tried to achieve that 15 years ago ;-(
________________________________
Von: owner-vhdl-200x@eda.org
An: vhdl-200x@eda.org
Gesendet: Wed Mar 03 16:52:22 2010
Betreff: Re: [Fwd: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]]
I'm in favor of extending the minimum implementation for integer to something more than 32 bits.
Unfortunately, some users might experience code compatibility problems with bigger integers -- at least one well known simulator allows (integer'high + 1) to roll over to -2**32.
Paul.Butler@ni.com
National Instruments
Austin, TX
From:
Jim Lewis <Jim@synthworks.com>
To:
vhdl-200x@eda.org
Date:
02/26/2010 01:25 PM
Subject:
[Fwd: RE: [vhdl-200x] [Fwd: [Accellera:vhdl] Time to start up?]]
Sent by:
owner-vhdl-200x@eda.org
________________________________
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<http://www.synopsys.com/>> / www.synplicity.com
<http://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<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<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<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 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<http://www.mailscanner.info/>, 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. ________________________________ Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Mar 4 02:37:12 2010
This archive was generated by hypermail 2.1.8 : Thu Mar 04 2010 - 02:40:09 PST