Signed, Unsigned syntax issues. Please help, I'm stumped
nitrog...@gmail.com
issues. I'm working with ISE 10.1
After running "check syntax", I get the following errors.
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 114. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 145. = has two
or more possible definitions in this scope. For example, parameter 2
(string value) can be: SIGNED or UNSIGNED
here are the lines being referred to:
Line 92: if setup_sample = "1111111" then
Line 114: curval <= countupstuff when setup_sample = "1111110";
Line 145: elsif apnea_count = "1101001101010101100100000" then
The errors seem to be implying that I haven't specified these signals
as either signed or unsigned. But the following part of my code does
specify all these signals as unsigned
(these are lines 39 through 47)
architecture Behavioral of SS08 is
signal countupstuff, curval, sample, count_1khz : unsigned (15 downto
0);
signal apnea_reset, alarm_out, clock1k, clock1k_int, inc_apnea_count,
inc_not_apnea, clock32x, clock32x_int, settozero : std_logic;
signal apnea_count, not_apnea : unsigned (24 downto 0);
signal count_1Mhz : unsigned (4 downto 0);
signal setup_sample : unsigned (6 downto 0);
begin
Interesting note, I was previously running this code on ISE 9.1 and it
didn't have a problem with it.
Can any one shed some light on why I'm getting these errors? It would
be very much appreciated. Let me know if you need any more
information.
Thanks,
Jeff
Mike Treseler
> ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 145. = has two
> or more possible definitions in this scope. For example, parameter 2
> (string value) can be: SIGNED or UNSIGNED
> Line 145: elsif apnea_count = "1101001101010101100100000" then
> The errors seem to be implying that I haven't specified these signals
> as either signed or unsigned. But the following part of my code does
> specify all these signals as unsigned
Declare the constants also:
> architecture Behavioral of SS08 is
>
subtype cnt25_t is unsigned(24 downto 0);
signal apnea_count, not_apnea : cnt25_t;
constant cnt25_c :: cnt25_t := "1101001101010101100100000";
...
etc.
Put this at the top:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
-- Mike Treseler
KJ
<nitrog...@gmail.com> wrote in message
news:62d67656-1b11-4741...@w5g2000prd.googlegroups.com...
> After running "check syntax", I get the following errors.
>
> ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
> or more possible definitions in this scope. For example, parameter 2
> (string value) can be: SIGNED or UNSIGNED
> ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 114. = has two
> or more possible definitions in this scope. For example, parameter 2
> (string value) can be: SIGNED or UNSIGNED
> ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 145. = has two
> or more possible definitions in this scope. For example, parameter 2
> (string value) can be: SIGNED or UNSIGNED
>
>
> here are the lines being referred to:
>
> Line 92: if setup_sample = "1111111" then
>
> Line 114: curval <= countupstuff when setup_sample = "1111110";
>
> Line 145: elsif apnea_count = "1101001101010101100100000" then
>
>
> The errors seem to be implying that I haven't specified these signals
> as either signed or unsigned. But the following part of my code does
> specify all these signals as unsigned
But the thing you're comparing them to (i.e. "1111111" and "1111110" are
ambiguous). You need to tell it if it is signed or unsigned like this
unsigned'("1111110")
Note the tick mark.
KJ
Mike Treseler
Jonathan Bromley
>After running "check syntax", I get the following errors.
>ERROR:HDLParsers:3292 - "D:/PFiles/SS08/SS08.vhd" Line 92. = has two
>or more possible definitions in this scope. For example, parameter 2
>(string value) can be: SIGNED or UNSIGNED
[etc]
>Line 92: if setup_sample = "1111111" then
[etc]
>The errors seem to be implying that I haven't specified these signals
>as either signed or unsigned. But the following part of my code does
>specify all these signals as unsigned
Intriguingly, this exact issue came up here only a couple
of days ago.
It's almost certainly because you are accepting the goofy
Xilinx default VHDL code template which has, inter alia,
USE IEEE.STD_LOGIC_ARITH.all;
No-one can explain why Xilinx (and others too) continue
to recommend in this way the use of a package that was
superseded by the better, more complete, properly
standardised IEEE.NUMERIC_STD over a decade ago.
The specific issue is that STD_LOGIC_ARITH provides
definitions of the "=" operator for all the following
combinations of types:
UNSIGNED = UNSIGNED
UNSIGNED = SIGNED
SIGNED = UNSIGNED
SIGNED = SIGNED
If the things on the opposite sides of the "=" are
simple variables or signals, that's fine - but if they
are expressions, or literals like your "111111", there
is a type ambiguity because the literal might be either
SIGNED or UNSIGNED, and VHDL can't work out which it is.
The preferred fix is to replace STD_LOGIC_ARITH with
NUMERIC_STD. This will fix the type ambiguity issue, but
it may give you a few other compile errors because the
conversion functions' names have changed: conv_integer()
is now to_integer, and conv_unsigned() is now called
to_unsigned(). Obviously, those will be rather easy
to deal with. This is by far the most satisfactory
solution. NUMERIC_STD defines equality for
UNSIGNED=UNSIGNED and for SIGNED=SIGNED, but not
for combinations of the two - so, in your comparison,
there is only one possible interpretation of the
constant and VHDL will get it right automatically.
The less satisfactory fix (hack) is to make the type
of your constants explicit:
if setup_sample = UNSIGNED'("1111111") then
This is known as a "type qualification"; note the
apostrophe between the type name and the opening
parenthesis.
I have no idea why this didn't throw an error in ISE9.1.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
KJ
"Jonathan Bromley" <jonathan...@MYCOMPANY.com> wrote in message
news:q0a344h9akcforb27...@4ax.com...
> On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:
>
>
> Intriguingly, this exact issue came up here only a couple
> of days ago.
>
A regular conspiracy going on ;)
> It's almost certainly because you are accepting the goofy
> Xilinx default VHDL code template which has, inter alia,
>
> USE IEEE.STD_LOGIC_ARITH.all;
>
> No-one can explain why Xilinx (and others too) continue
> to recommend in this way the use of a package that was
> superseded by the better, more complete, properly
> standardised IEEE.NUMERIC_STD over a decade ago.
>
That would bring them up to the 90s now wouldn't it....only 15 or so years
behind the standards.
>
> The less satisfactory fix (hack) is to make the type
> of your constants explicit:
>
> if setup_sample = UNSIGNED'("1111111") then
>
> This is known as a "type qualification"; note the
> apostrophe between the type name and the opening
> parenthesis.
>
If for some reason you reeeeeally didn't want to properly define a constant
to do the job, I think using the type qualifier is better (not a hack)
since, even if the compiler has no ambiguity, the reader may and having the
type qualifier makes it explicit to the reader as to the intended
type...documentation comes in all forms.
Kevin Jennings
Andy Peters
> "Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message
>
> news:q0a344h9akcforb27...@4ax.com...
>
> > On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:
>
> > Intriguingly, this exact issue came up here only a couple
> > of days ago.
>
> A regular conspiracy going on ;)
>
> > It's almost certainly because you are accepting the goofy
> > Xilinx default VHDL code template which has, inter alia,
>
> > USE IEEE.STD_LOGIC_ARITH.all;
>
> > No-one can explain why Xilinx (and others too) continue
> > to recommend in this way the use of a package that was
> > superseded by the better, more complete, properly
> > standardised IEEE.NUMERIC_STD over a decade ago.
>
> That would bring them up to the 90s now wouldn't it....only 15 or so years
> behind the standards.
I opened up a Web Case about this. Let's see if they give a shit.
Oh, yeah, in that same Web Case, I suggested that their templates use:
if rising_edge(clk) then
instead of
if (clk'event and clk = '1') then
It's almost halfway through 2008 ...
=-a
rickman
wrote:
I can't sat that Numemric_std is a panacea. VHDL is still a tough
language to master in terms of the strong typing. It is hard to even
figure out what the true nature of the problem is in many cases. Here
is one that I am currently dealing with. I just changed a number of
slvs to unsigned and now I get this error.
if (CTPCurCmd(VER_RNG) = '1') and (DataOutReg /= CTPCurCmd(DAT_RNG))
then
---No matching overload for "/="---
DataOutReg is slv and CTPCurCmd is unsigned. I thought that the two
types were "closely related" which means I don't have to use
conversions to intermix them. I also get errors when trying to
concatenate slv with unsigned. What exactly is wrong with either of
these? I guess it doesn't know what type to make the result of a
concatenation, but the equality comparison shouldn't have that
problem.
Rick
Mike Treseler
> ---No matching overload for "/="---
>
> DataOutReg is slv and CTPCurCmd is unsigned. I thought that the two
> types were "closely related" which means I don't have to use
> conversions to intermix them.
No, closely related means I can use
a cast instead of a conversion as in:
unsigned(DataOutReg) /= CTPCurCmd(DAT_RNG)
Let's look up the "/=" functions available
in the numeric_std source here:
http://www.cs.umbc.edu/help/VHDL/packages/numeric_std.vhd
function "/=" (L,R: UNSIGNED ) return BOOLEAN;
function "/=" ( L,R: SIGNED) return BOOLEAN;
function "/=" ( L: NATURAL; R: UNSIGNED) return BOOLEAN;
function "/=" ( L: INTEGER; R: SIGNED) return BOOLEAN;
function "/=" ( L: UNSIGNED; R: NATURAL) return BOOLEAN;
function "/=" ( L: SIGNED; R: INTEGER) return BOOLEAN;
For your example, a cast is needed to match the first signature.
-- Mike Treseler
Andy
"closely related" types only means you don't have to write a
conversion function between them, but you still have to use one. It is
invoked as the name of the type you are converting to.
if unsigned(my_slf) < my_unsigned then...
Andy
rickman
I have seen to_unsigned(), unsigned() and unsigned'. I understand
that the first to are conversion and type casting respectively. What
is the third called? I expect this is only for use where a literal or
expression can be interpreted more than one way and explains to the
tool what is intended, right?
I read back a bit and see that it is a "type qualification". I think
I got all that now. So even when types are closely related, you still
have to explicitly tell the tool to change the interpretation.
I think I wish I had started with Verilog instead of VHDL. At least
now if I start coding in Verilog, it will be an informed decision.
The little Verilog I have coded was very easy to do and I did it with
*no* additional training. I just picked up a little from a book and
the rest came pretty easy.
Does Verilog support user libraries in a similar manner to VHDL?
Rick
Jim Lewis
> I have seen to_unsigned(), unsigned() and unsigned'. I understand
> that the first to are conversion and type casting respectively. What
> is the third called? I expect this is only for use where a literal or
> expression can be interpreted more than one way and explains to the
> tool what is intended, right?
http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf
Or if you don't like going directly to pdf, go to:
http://www.synthworks.com/papers/
and select the paper, "VHDL Math Tricks of the Trade" from the
conference, MAPLD 2003.
Best,
Jim
SynthWorks VHDL Training
Mike Treseler
> I have seen to_unsigned(), unsigned() and unsigned'. I understand
> that the first to are conversion and type casting respectively. What
> is the third called? I expect this is only for use where a literal or
> expression can be interpreted more than one way and explains to the
> tool what is intended, right?
That's it.
> I read back a bit and see that it is a "type qualification". I think
> I got all that now. So even when types are closely related, you still
> have to explicitly tell the tool to change the interpretation.
Yes, but keep in mind that I don't need *any* of these
functions if I declare my variable and constant
vectors correctly in the first place.
Here's an example of how I do this using subtypes:
http://mysite.verizon.net/miketreseler/sync_template.vhd
And don't leave home without your cheat sheets:
http://www.vhdl.org/rassp/vhdl/guidelines/vhdlqrc.pdf
http://www.vhdl.org/rassp/vhdl/guidelines/1164qrc.pdf
> I think I wish I had started with Verilog instead of VHDL. At least
> now if I start coding in Verilog, it will be an informed decision.
I expect that it would take longer
to learn verilog well than to learn
the vhdl numeric libraries.
If Andy were here, he would remind you
that integer ranges also work fine for synthesis
and require no libraries.
> The little Verilog I have coded was very easy to do and I did it with
> *no* additional training. I just picked up a little from a book and
> the rest came pretty easy.
It's a rose for easy projects, but just thorns for debugging
complicated modules with signed and unsigned math.
> Does Verilog support user libraries in a similar manner to VHDL?
No.
-- Mike Treseler
Andy
A long time ago there was a live design/coding contest between being
Verilog and VHDL to code a small module that had a few strange
requirements, but was otherwise pretty straight forward. Verilog
trounced VHDL. But if you stopped there, and assumed Verilog was
better than VHDL for most digital design, you missed the point.
Anything that can be converted from spec to synthesized gates in an
hour or two will almost necessarily be the easiest/quickest to design
in the simplest, most constrained language capable of doing that
simple job, namely verilog. Is that the basis upon which you want to
choose your development language?
To keep Mike an honest man: VHDL synthesis tools support arithmetic
for integers without additional libraries. However, bit-wise logic
operations on integers are not supported without custom libraries, and
standard ranges for integers limit data widths to 31 bits unsigned and
32 bit signed.
One more point: just try to design a fixed or floating point
arithmetic design with verilog!
Andy
rickman
I recall that competition and I seem to recall that it was *very*
inconclusive. Although the Verilog teams seemed to be further along,
not one team produced working code in the time alloted. I guess this
could be a different contest though.
> To keep Mike an honest man: VHDL synthesis tools support arithmetic
> for integers without additional libraries. However, bit-wise logic
> operations on integers are not supported without custom libraries, and
> standard ranges for integers limit data widths to 31 bits unsigned and
> 32 bit signed.
I don't care if libraries are required for various features. I was
asking about support for user libraries in Verilog. I believe the
answer was no. Is that still valid?
> One more point: just try to design a fixed or floating point
> arithmetic design with verilog!
Is that a point? What was the point? Are you trying to say that
users don't design arithmetic circuits in Verilog??? I am pretty sure
that the limited work I have done in Verilog has included arithmetic.
I must be missing your point.
BTW, here is one of the reasons I am getting tried of using VHDL. I
have coded FPGAs in VHDL off and on for some 10 years. Every time I
start a new design (sometimes as long as 18 months since the last one)
I have to pick up all of my books again to remember the details and to
read my notes on the various shortcuts to efficient use. I typically
find that the shortcuts are not very short and look for new ones. The
notation is just so verbose for simple things. Here is an example.
CTPBitCnt is an unsigned.
What I mean...
CTPBitCnt <= 1;
What I have to write...
CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
Doesn't that seem a bit wordy? I guess this example goes back to the
inability to overload the assignment operator which someone has
indicated may be changed in the next revision of the language.
Rick
KJ
I agree it is too wordy and also prone to error (like if you get
sloppy and type "8" instead of "CTPBitCnt'length" and then later
change the range of "CTPBitCnt")
If this were legal...
CTPBitCnt <= to_unsigned(1)
I wouldn't think it to be too wordy since it is specifying a type
conversion and having explicit type conversions is preferrable (to
me).
In the meantime one could create a procedure like the following and
put it into a package of commonly used VHDL shortcuts...
procedure set(L: out unsigned; R: in integer) is
begin
L := to_unsigned(R, L'length);
end procedure set;
which could then be used like this...
set(Test_Set, 1);
But then you'd need to overload it so you could pass signals instead
of variables...and hope that the name 'set' (or whatever you come up
with) sticks in your mind as to be clear about what it's purpose
is....sigh
Kevin Jennings
Mike Treseler
> What I mean...
> CTPBitCnt <= 1;
>
> What I have to write...
> CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
>
> Doesn't that seem a bit wordy?
Yes. Declare CTPBitCnt unsigned instead of std_logic_vector.
CTPBitCnt <= x"0001";
-- Mike Treseler
KJ
> rickman wrote:
> > What I mean...
> > CTPBitCnt <= 1;
>
> > What I have to write...
> > CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
>
> > Doesn't that seem a bit wordy?
>
> Yes. Declare CTPBitCnt unsigned instead of std_logic_vector.
>
He did declare it as unsigned.
> CTPBitCnt <= x"0001";
>
Doesn't work though if the length of CTPBitCnt is anything other than
a multiple of 4 bits (i.e. CTPBitCnt: unsigned(12 downto 0));
KJ
rickman
> On Jun 11, 2:14 pm, Mike Treseler <mike_trese...@comcast.net> wrote:
>
> > rickman wrote:
> > > What I mean...
> > > CTPBitCnt <= 1;
>
> > > What I have to write...
> > > CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
>
> > > Doesn't that seem a bit wordy?
>
> > Yes. Declare CTPBitCnt unsigned instead of std_logic_vector.
>
> He did declare it as unsigned.
>
> > CTPBitCnt <= x"0001";
This works with signed, unsigned and SLV!
> Doesn't work though if the length of CTPBitCnt is anything other than
> a multiple of 4 bits (i.e. CTPBitCnt: unsigned(12 downto 0));
Worse, I have to hard code the width of the signal which I try to
avoid. That is why I want to assign it a value from an integer and
not specify every bit in the vector. For example, all of my address
values are currently 8 bits. My customer may decide to change the
protocol to use 6 bits since that is plenty enough. I would hate to
have to go through the entire body of code changing 8 bit constants to
6 bits.
VHDL just makes life hard in some ways.
Rick
KJ
Slight correction to the previous. You can't overload the 'set'
function to have one that works with signals and another that works
with variables, you'd need to have two distinctly named functions
(i.e. 'setsig' and 'setvar')...all for the lack of being able to
overload the assignment operators....
KJ
Brian Drummond
wrote:
>BTW, here is one of the reasons I am getting tried of using VHDL. I
>have coded FPGAs in VHDL off and on for some 10 years. Every time I
>start a new design (sometimes as long as 18 months since the last one)
>I have to pick up all of my books again to remember the details and to
>read my notes on the various shortcuts to efficient use. I typically
>find that the shortcuts are not very short and look for new ones. The
>notation is just so verbose for simple things. Here is an example.
>
>CTPBitCnt is an unsigned.
>
>What I mean...
> CTPBitCnt <= 1;
>
>What I have to write...
> CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
>
>Doesn't that seem a bit wordy? I guess this example goes back to the
>inability to overload the assignment operator which someone has
>indicated may be changed in the next revision of the language.
Ironically, thanks to overloaded operators,
CTPBitCnt <= (others => '0') + 1;
will work, and I would hope any synthesis tool would realise both inputs
are constant.
It's not pretty though...
- Brian
Mike Treseler
> This works with signed, unsigned and SLV!
Yes sorry, I didn't read your post carefully.
>> Doesn't work though if the length of CTPBitCnt is anything other than
>> a multiple of 4 bits (i.e. CTPBitCnt: unsigned(12 downto 0));
That is annoying,
and that is why I declare a subtype for vector constants:
subtype vec_t is unsigned(vec_len-1 downto 0);
constant vec_zero_c : vec_t := (others => '0');
constant vec_one_c : vec_t := vec_init_c + 1;
constant vec_load_c : vec_t := vec_init_c + 42;
CTPBitCnt <= vec_one_c;
> VHDL just makes life hard in some ways.
And easy in other ways ;)
-- Mike Treseler
Jim Lewis
> BTW, here is one of the reasons I am getting tried of using VHDL. I
> have coded FPGAs in VHDL off and on for some 10 years. Every time I
> start a new design (sometimes as long as 18 months since the last one)
> I have to pick up all of my books again to remember the details and to
> read my notes on the various shortcuts to efficient use. I typically
> find that the shortcuts are not very short and look for new ones. The
> notation is just so verbose for simple things. Here is an example.
>
> CTPBitCnt is an unsigned.
>
> What I mean...
> CTPBitCnt <= 1;
>
> What I have to write...
> CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
>
> Doesn't that seem a bit wordy? I guess this example goes back to the
> inability to overload the assignment operator which someone has
> indicated may be changed in the next revision of the language.
Jonathan just submitted a language feature request WRT to overloading
assignment, however, the standard is already at the balloting point so
it will not make the 2008 revision.
What has been added is a decimal notation for bit string literals
and a sizing indication.
signal CTPBitCnt : unsigned (14 downto 0) ; -- 15 bits
. . .
-- Representing 1 as a 15 bit object in either hex or decimal
CTPBitCnt <= 15D"1" ; -- Decimal notation
CTPBitCnt <= 15X"1" ; -- Hex notation
BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
if your vendors were looking out for your interests, they would
have already should implemented these.
Make sure to submit these as bug/enhancement requests. This is important
as this is what lets them know the VHDL community wants the new features.
Best,
Jim
P.S. Did you grab the paper I referenced:
http://www.synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf
rickman
Yes, I looked at it. I especially like the comment at the bottom of
page 5
"Some think VHDL is difficult because of strong typing
Master the above simple rules and it is easy"
No, it is not "easy". It is cumbersome and crude. Strong typing is
not the problem, verbosity is! Strong typing may keep you from
screwing up certain things that novices might do, but VHDL is a clumsy
language. Just as you point out above, there are any number of ways
to make the language more succinct and readable, not to mention
helping to let my tendinitis heal. It is hard to imagine that it has
taken over 20 years for many of these simple ideas to be
implemented.
Maybe I am being overly critical. Right now I am pretty ticked off
about the Lattice/Aldec tools I paid a kilobuck for. It won't even
let me make a test bench out of the file I wrote for another chip.
I have a mind to abandon VHDL so that I can use the open source
Verilog tools. It may be too late to use them on this design, but I
will look very hard at open source before I start my next design.
Rick
rickman
Oh, BTW, some of the features you list above are not really a great
solution. If I write...
CTPBitCnt <= 15D"1" ; -- Decimal notation
I am sprinkling my code with numerical constants that have to be
changed, one at a time, if my declaration changes. What exactly is
the problem that is solved by not allowing...
CTPBitCnt <= 1;
Isn't the meaning of this very clear? If I am assigning it to a
signed signal, then it should be treated as signed, right? If I am
assigning it to an unsigned signal, then it should be treated as
unsigned, right? Maybe I do have a problem with strong typing if it
requires me to be so verbose that the size of my files triple without
adding anything to the clarity of the code.
CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
What am I missing?
Rick
KJ
>
> > CTPBitCnt is an unsigned.
>
> > What I mean...
> > CTPBitCnt <= 1;
>
>
> Jonathan just submitted a language feature request WRT to overloading
> assignment, however, the standard is already at the balloting point so
> it will not make the 2008 revision.
>
> What has been added is a decimal notation for bit string literals
> and a sizing indication.
>
> signal CTPBitCnt : unsigned (14 downto 0) ; -- 15 bits
> . . .
> -- Representing 1 as a 15 bit object in either hex or decimal
>
> CTPBitCnt <= 15D"1" ; -- Decimal notation
> CTPBitCnt <= 15X"1" ; -- Hex notation
>
The type of syntax only a mother could love...
Let's take a look at some notations
A: CTPBitCnt <= 1;
B: CTPBitCnt <= to_unsigned(1);
C: CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
D: set(CTPBitCnt, "<=", 1);
E: CTPBitCnt <= 15D"1"
F: CTPBitCnt <= CTPBitCnt'length D"1";??
'A' has the advantage of clarity of intent...it has the drawback of
requring loose type checking in the language.
'B' has the advantage of clarity of intent...and it meets the
requirements of strong type checking and is not overly wordy.
Requires the "<=" and the ":=" operators to be overriddent in the
language (in other words just like all the other operators).
'C' is valid VHDL'93 syntax. It is too verbose and subject to error
if one inadverantly does not have the same signal name preceding the
'length attribute that is on the left hand side of the statement.
'D' is kludgy but fairly succint in getting the intent across. Has
the drawback that one would need separately named functions to assign
signals versus variables (why the language does not allow an override
in this case is pointless...but a separate grouse).
'E' is valid VHDL'2008 that has lost the designer's intent...15B??
hmmm....
'F' might be valid VHDL'2008, not sure. But in order to write code
that you don't have to keep re-writing when the width of 'CTPBitCnt'
changes is how you would want to express it. Even if it were legal,
it is just a butt ugly version of what is currently available with
VHDL'93. It's not an improvement, it's worse. Not only do you have
to specify the width (as you do today) but now the intent of the
statement is only clear to those who understand that a 'D' or an 'X'
preceding a constant is specifying the bit width of the
constant....ummmm....OK, I think I'll stick with today's to_unsigned
notation.
Were I to rank them in order of preference it would be
1. 'B', it has everything that a strongly typed language requires and
succintly captures the designer's intent which is to assign an integer
value to an unsigned signal.
2. 'D' has all the same benefits of 'B' but is somewhat klunky and is
only a kludge to get around the unneeded language limitation that
prohibits overriding '<=' and ':='
3. 'C'...all the benefits of 'B' but is overly wordy as has already
been pointed out.
4. 'A'...I'd be comfortable with relax strong type checking in this
particular narrow instance before I'd take the final choices
5. 'E' and 'F'. Absolutely nothing about it is better than what we
have with today's to_unsigned() function and it is far worse in that
the designer's intent has been lost.
> BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
> if your vendors were looking out for your interests, they would
> have already should implemented these.
>
> Make sure to submit these as bug/enhancement requests. This is important
> as this is what lets them know the VHDL community wants the new features.
>
I think I'll sit out requesting this particular enhancement from the
vendors.
Kevin Jennings
Mike Treseler
> No, it is not "easy". It is cumbersome and crude. Strong typing is
> not the problem, verbosity is! Strong typing may keep you from
> screwing up certain things that novices might do, but VHDL is a clumsy
> language. Just as you point out above, there are any number of ways
> to make the language more succinct and readable, not to mention
> helping to let my tendinitis heal.
VHDL-2002 is what it is.
The tendinitis might do better if you pick
one of the working solutions we have offered
and use it, rather than dissertating on vhdl-2010.
-- Mike Treseler
rickman
Thanks for your commments Mike. If you are tired of the conversation,
feel free to not participate.
Rick
rickman
This is the issue that I am struggling with understanding. Strong
type checking is good in many contexts. But I fail to understand why
it has to prevent me in this case. In fact, I think that someone said
that this is being proposed for the next, next rev of the language.
So obviously it does not present any real issues to make it
incompatible with strong type checking.
I see it as akin to the issue that had previously existed with string
literals. It has been quite a while, so maybe I don't recall
correctly, but I think there was a time when hex constants could not
be used with the slv type. Since then this has been added so I don't
have to convert a bit string literal to an slv literal. I don't know
how they did it and I don't care a lot. I just see that it was pretty
durn obvious that it would have been desirable to support this from
the start and it was not done.
Likewise it seems to me that making version A acceptable is obviously
desirable and it sounds like it is going to happen. But why did it
take 20 years for someone to figure it out?
> 'B' has the advantage of clarity of intent...and it meets the
> requirements of strong type checking and is not overly wordy.
> Requires the "<=" and the ":=" operators to be overriddent in the
> language (in other words just like all the other operators).
I honestly don't understand why the intent is not clear in example A.
I specified that CTPBitCnt was an unsigned signal in the declaration.
Does it make any sense to assume that I mean the literal 1 to be
anything other than an unsigned equivalent? Maybe my software courses
in college were too long ago for me to have learned why strong typing
has to be so cumbersome.
> 'C' is valid VHDL'93 syntax. It is too verbose and subject to error
> if one inadverantly does not have the same signal name preceding the
> 'length attribute that is on the left hand side of the statement.
Yes, and errors are what we are trying to prevent. Of course this
will be caught before it is turned in to a chip, but that whole cycle
of edit-compile-test, even if it is shortened to edit-compile is a
PITA. Maybe I am admitting to being a poor programmer, but today I
actually spend over 15 minutes dealing with compiler complaints about
locally static stuff that is totally obvious to anyone reading the
code. And all that was from a 2 minute code change! I don't memorize
things very well. I expect my tools to be obvious and intuitive...
maybe I should stick to hammers, chisels and sanders? I may get
frustrated, but this stuff does pay a lot better.
> 'D' is kludgy but fairly succint in getting the intent across. Has
> the drawback that one would need separately named functions to assign
> signals versus variables (why the language does not allow an override
> in this case is pointless...but a separate grouse).
I assume this is a special procedure to perform the required function
by reading the middle term? Interesting...
> 'E' is valid VHDL'2008 that has lost the designer's intent...15B??
> hmmm....
To be honest, I don't see how this one can even work. Is this
intended to indicate a signed or an unsigned value? How do you
indicate the other? I don't need to say anything about the 15 part...
The more I read about this, the more I like Verilog... at least until
I start using it ;^)
Rick
KJ
"rickman" <gnu...@gmail.com> wrote in message
news:37c87ac4-768f-405f...@x35g2000hsb.googlegroups.com...
> You present a nice list. Thanks.
>
>> requring loose type checking in the language.
>
> This is the issue that I am struggling with understanding. Strong
> type checking is good in many contexts. But I fail to understand why
> it has to prevent me in this case. In fact, I think that someone said
> that this is being proposed for the next, next rev of the language.
> So obviously it does not present any real issues to make it
> incompatible with strong type checking.
>
It breaks the rules of strong type checking because 'CTPBitCnt' is of type
'unsigned' and '1' is of type integer and assigning something of one type to
something that is of another type directly without some form of conversion
function breaks what is considered to be strong type checking.
Relaxation of the rules in certain instances (like this one) can be a
productivity enhancer and a 'good' thing for the language but you should
also accept that this relaxing of the rules IS a violation of strong type
checking.
<snip>
>
>> 'B' has the advantage of clarity of intent...and it meets the
>> requirements of strong type checking and is not overly wordy.
>
> I honestly don't understand why the intent is not clear in example A.
Flip back and you'll see that I said that both 'A' and 'B' are clear about
the designer's intent.
> I specified that CTPBitCnt was an unsigned signal in the declaration.
> Does it make any sense to assume that I mean the literal 1 to be
> anything other than an unsigned equivalent?
I hate having to flip back to the declaration to see what the type of a
particular signal is.
> Maybe my software courses
> in college were too long ago for me to have learned why strong typing
> has to be so cumbersome.
>
It needn't be...overrides for "<=" and ":=" would solve the wordiness
problem and still provide for the strong type checking....as someone else
stated, other languages have it. The needed conversion function can be the
function that provides an operator overload....just like how one can
overload "and", "or", etc. to work with custom types today.
<snip>
>
>> 'D' is kludgy but fairly succint in getting the intent across.
>
> I assume this is a special procedure to perform the required function
> by reading the middle term? Interesting...
>
Yes, it would be a homegrown procedure that one would put into a package of
commonly used functions. Just as you get into the habit of including the
std_logic stuff at the begining of every VHDL file you would start to
include your package of homegrown stuff and then always have these shortcuts
handy.
By the way, the middle term "<=" wouldn't even be used by the procedure it
would simply be there to aid the reader since something like this
set (this, that)
would always cause someone to say, well does that mean
this <= that
or
that <= this?
whereas
set (this "<=" that);
would be more clear...at the expense of more typing....for a parameter that
doesn't functionally contribute anything...I can hear the moans and groans
already, but you can make your homegrowns your way, I'll make 'em mine.
The procedure should have an assert to make sure that the middle term is
"<=" though so that some smarty pants that said
set (this, "=>" that)
would get hammered in simulation by firing an assertion.
>
>> 'E' is valid VHDL'2008 that has lost the designer's intent...15D??
>> hmmm....
>
> To be honest, I don't see how this one can even work. Is this
> intended to indicate a signed or an unsigned value? How do you
> indicate the other? I don't need to say anything about the 15 part...
>
VHDL has a lot of nice things....this one isn't one of them...well, assuming
that it actually gets approved.
>
> The more I read about this, the more I like Verilog... at least until
> I start using it ;^)
>
comp.lang.verilog is always looking for members....and from what I read
Verilog is finally catching up to VHDL.
KJ
rickman
> "rickman" <gnu...@gmail.com> wrote in message
>
> news:37c87ac4-768f-405f...@x35g2000hsb.googlegroups.com...
>
> > You present a nice list. Thanks.
>
> >> 'A' has the advantage of clarity of intent...it has the drawback of
> >> requring loose type checking in the language.
>
> > This is the issue that I am struggling with understanding. Strong
> > type checking is good in many contexts. But I fail to understand why
> > it has to prevent me in this case. In fact, I think that someone said
> > that this is being proposed for the next, next rev of the language.
> > So obviously it does not present any real issues to make it
> > incompatible with strong type checking.
>
> It breaks the rules of strong type checking because 'CTPBitCnt' is of type
> 'unsigned' and '1' is of type integer and assigning something of one type to
> something that is of another type directly without some form of conversion
> function breaks what is considered to be strong type checking.
>
> Relaxation of the rules in certain instances (like this one) can be a
> productivity enhancer and a 'good' thing for the language but you should
> also accept that this relaxing of the rules IS a violation of strong type
> checking.
I think my point is that calling 1 an integer is arbitrary. It has
been defined as an integer, just like X"5A69" was originally defined
as a bit vector. But we can also see it as a std_logic_vector and
understand its meaning. I feel that calling 1 an integer is
arbitrary. I can consider it to be a unconstrained slv literal just
as easily as an integer. I understand that this is not part of the
language, but I don't see any reason that it can't be. I don't see
any ambiguity in considering integer numbers to represent slv of
indeterminate length.
> >> 'B' has the advantage of clarity of intent...and it meets the
> >> requirements of strong type checking and is not overly wordy.
>
> > I honestly don't understand why the intent is not clear in example A.
>
> Flip back and you'll see that I said that both 'A' and 'B' are clear about
> the designer's intent.
>
> > I specified that CTPBitCnt was an unsigned signal in the declaration.
> > Does it make any sense to assume that I mean the literal 1 to be
> > anything other than an unsigned equivalent?
>
> I hate having to flip back to the declaration to see what the type of a
> particular signal is.
Then how would you know to write unsigned(... rather than
signed(... ? Once the code is written, the meaning is obvious, assign
the numerical value 1 to the signal in whatever format is
appropriate. Do you need to know that the signal is signed or
unsigned to understand this assignment?
> > Maybe my software courses
> > in college were too long ago for me to have learned why strong typing
> > has to be so cumbersome.
>
> It needn't be...overrides for "<=" and ":=" would solve the wordiness
> problem and still provide for the strong type checking....as someone else
> stated, other languages have it. The needed conversion function can be the
> function that provides an operator overload....just like how one can
> overload "and", "or", etc. to work with custom types today.
Yes, I think we all agree that would be a good idea. I just don't
understand why it has taken the experts over 20 years to figure this
out. I have only worked with this stuff part of the time and even
then I was just trying to get something done with it, not invent the
language... and I can clearly see the need.
> >> 'D' is kludgy but fairly succint in getting the intent across.
>
> > I assume this is a special procedure to perform the required function
> > by reading the middle term? Interesting...
>
> Yes, it would be a homegrown procedure that one would put into a package of
> commonly used functions. Just as you get into the habit of including the
> std_logic stuff at the begining of every VHDL file you would start to
> include your package of homegrown stuff and then always have these shortcuts
> handy.
>
> By the way, the middle term "<=" wouldn't even be used by the procedure it
> would simply be there to aid the reader since something like this
>
> set (this, that)
>
> would always cause someone to say, well does that mean
> this <= that
> or
> that <= this?
>
> whereas
> set (this "<=" that);
> would be more clear...at the expense of more typing....for a parameter that
> doesn't functionally contribute anything...I can hear the moans and groans
> already, but you can make your homegrowns your way, I'll make 'em mine.
Personally, I think set (this, that) is just fine. It is a strange
construct to begin with. But once someone learns about it, it is very
easy to remember that the order is the same as in an assignment. No
confusion there. Or you could name it set_to(this, that) as in "set
this to that". This is starting to sound a bit like Forth...!
> The procedure should have an assert to make sure that the middle term is
> "<=" though so that some smarty pants that said
>
> set (this, "=>" that)
>
> would get hammered in simulation by firing an assertion.
>
>
>
> >> 'E' is valid VHDL'2008 that has lost the designer's intent...15D??
> >> hmmm....
>
> > To be honest, I don't see how this one can even work. Is this
> > intended to indicate a signed or an unsigned value? How do you
> > indicate the other? I don't need to say anything about the 15 part...
>
> VHDL has a lot of nice things....this one isn't one of them...well, assuming
> that it actually gets approved.
>
>
>
> > The more I read about this, the more I like Verilog... at least until
> > I start using it ;^)
>
> comp.lang.verilog is always looking for members....and from what I read
> Verilog is finally catching up to VHDL.
>
> KJ
Well, I still need to get this one done. I'll wait and see if I am
still inclined to jump ship when I start the next project.
Rick
MikeWhy
>> > I specified that CTPBitCnt was an unsigned signal in the declaration.
>> > Does it make any sense to assume that I mean the literal 1 to be
>> > anything other than an unsigned equivalent?
>>
>> I hate having to flip back to the declaration to see what the type of a
>> particular signal is.
>
> Then how would you know to write unsigned(... rather than
> signed(... ? Once the code is written, the meaning is obvious, assign
> the numerical value 1 to the signal in whatever format is
> appropriate. Do you need to know that the signal is signed or
> unsigned to understand this assignment?
In C/C++, "promotion" of signed integer values is sign-bit extension;
unsigned promotion is zero-extension. It seems a resaonable enough approach
to the problem you define. You only need to clearly establish whether your
literal constant is signed or unsigned.
>> > Maybe my software courses
>> > in college were too long ago for me to have learned why strong typing
>> > has to be so cumbersome.
C++ clearly defines type coercions, but we needn't go there on this, I
think. I can tell you that allowing C-style typecasts, similar to VHDL
typecasts, defeats its type system. VHDL, by not allowing more reasonable
constructs, encourages the same abuse and misuse.
>> It needn't be...overrides for "<=" and ":=" would solve the wordiness
>> problem and still provide for the strong type checking....as someone else
>> stated, other languages have it.
Yikes. Are there times when the two would be defined differently?
>> The needed conversion function can be the
>> function that provides an operator overload....just like how one can
>> overload "and", "or", etc. to work with custom types today.
>
> Yes, I think we all agree that would be a good idea. I just don't
> understand why it has taken the experts over 20 years to figure this
> out. I have only worked with this stuff part of the time and even
> then I was just trying to get something done with it, not invent the
> language... and I can clearly see the need.
I can see some issues. But so far, it sounds like you only want to better
define assignment of signed/unsigned integer values and literal constants.
Size promotion rules will cover it without fighting that battle.
What other use would you have for assignment overload?
Jonathan Bromley
>>> ...overrides for "<=" and ":=" would solve the wordiness
>>> problem and still provide for the strong type checking
>
>Yikes. Are there times when the two would be defined differently?
I don't think so. My proposal to ISAC suggests that only ":=" be
overloaded, and "<=" be redefined as a variable assignment to
an internal temporary of the same subtype as the signal, followed
by all the usual signal assignment rigmarole. So the overload of
"<=" would follow automatically from any redefined ":=".
>What other use would you have for assignment overload?
I'm clear about why _I_ want it...
Reason 1: In any fixed-point package,
I want to be able to do mixed-width arithmetic and have the
result automatically truncated and rounded (using whatever
T&R policy is currently set as the default) as part of
assignment. Right now this has to be done with an explicit
call to a resize() function; the IEEE fixed-point package
sugar-coats this by allowing you to specify the target
object as a second argument to resize(), so that resize()
can use that argument to decide what subtype to return.
But overloaded := would be a gazillion times nicer and
more elegant.
More important still, it would prevent errors that are
currently unavoidable: if you use := or <= to copy a
fixed-point value from one place to another, and the
target object is of the wrong subytpe, you can get its
fixed-point scaling silently and disastrously screwed-up.
Personally I think this leaves VHDL's fixed-point package
holed below the waterline; I would never use it on a
serious project because of this risk of silent rescaling.
Reason 2: There are a few places in VHDL where you need a
boolean expression, but other kinds of expression would
make good sense. For example:
signal enable: std_logic;
...
if enable then ... -- currently illegal
It isn't a big stretch to imagine ":="[boolean,std_ulogic]
being automatically invoked in such a situation. So you
get user control over whether - and how - the test expression
is automatically cast to boolean.
When I submitted the suggestion to ISAC I was completely
amazed to find that there was nothing similar already
being discussed.
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan...@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
KJ
> On Jun 13, 10:35 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:
>> "rickman" <gnu...@gmail.com> wrote in message
>>
>> news:37c87ac4-768f-405f...@x35g2000hsb.googlegroups.com...
>>
>
>> this <= that
>> or
>> that <= this?
>>
>> whereas
>> set (this "<=" that);
>> would be more clear...at the expense of more typing....for a parameter
>> that
>> doesn't functionally contribute anything...I can hear the moans and
>> groans
>> already, but you can make your homegrowns your way, I'll make 'em mine.
>
> Personally, I think set (this, that) is just fine. It is a strange
> construct to begin with. But once someone learns about it, it is very
> easy to remember that the order is the same as in an assignment. No
> confusion there.
But you would also have to admit that the learning curve upon first seeing
set(this, "<=", that) is lower (hopefully non-existent) than it is for
set(this,that) since the "<=" parameter makes it plainly obvious which is
the target of the assignment (although one can certainly quibble about the
name, maybe 'copy' would be better than 'set').
So now you get into the tradeoff between productivity gained while banging
in the code (if you don't have to type in the "<=" every time you use it)
versus productivity lost (from having to go back to refresh your noggin on
which is the target if you don't use this on a daily basis) in later
supporting the code. While you're focusing right now on the code entry
hassles, remember that effort only gets done once, but you (or someone else)
will have to look at it more than once and not always while it's still fresh
in your mind, maybe years later...or perhaps by someone else who has to
support your design after you move on....then again, maybe the obscure
approach is better from a future support contracting perspective....after
all, that's partly why suppliers generate obtuse code for 'wizard' generated
widgets to make it at least a bit of a pain to go back and
rework/modify/extend it.
Anyway, I just tossed this procedure one out as an idea and admitted it is
klunky, but certainly less so than the 15D/15X prefix thing.
We're certainly off on a tangent from your original query. You can always
submit an enhancement request in to the VHDL gods. I don't have the link
handy but if you Google for Accelera and VHDL enhancements you can probably
find the link, Jim Lewis' posts sometimes have it since he is part of that
group. I submitted a couple that got accepted...although I'm not sure
when/if they ever will/did make it into the new standard.
Kevin Jennings
KJ
"MikeWhy" <boat042...@yahoo.com> wrote in message
news:FsK4k.13880$co7....@nlpi066.nbdc.sbc.com...
> "rickman" <gnu...@gmail.com> wrote in message
> news:bdf4e73d-f1d1-460d...@d45g2000hsc.googlegroups.com...
> define assignment of signed/unsigned integer values and literal constants.
> Size promotion rules will cover it without fighting that battle.
>
> What other use would you have for assignment overload?
>
I second Jonathon's post. The new fixed/floating point library is an
excellent example of why you would want this. While it's great that it can
be used with existing VHDL-93, having to put the size of the thing being
assigned to on the right hand side just so the function can know the size of
the thing being assigned to really clutters up and obscures things. The
declaration of a signal becomes quite interesting in how to format it to
even look intelligible to the reader.
Kevin Jennings
Jim Lewis
> A: CTPBitCnt <= 1;
> B: CTPBitCnt <= to_unsigned(1);
> C: CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
> D: set(CTPBitCnt, "<=", 1);
> E: CTPBitCnt <= 15D"1"
> F: CTPBitCnt <= CTPBitCnt'length D"1";??
A couple of comments.
Which of these solutions work for numbers larger than 31 bits?
Beyond strong typing, I think the array sizing rules are important.
Tensilica presented a paper at DVCon some years back where they
imposed lint rules on their Verilog coders to facilitate the translation
to VHDL. These lint rules enforced the array sizing rules in numeric_std.
The number I remember was that when the lint rule fired off, 75% of the
time it was an error. Anyone hear (or from Tensilica know) a different
number?
> 'E' is valid VHDL'2008 that has lost the designer's intent...15B??
> hmmm....
>
> 'F' might be valid VHDL'2008, not sure. But in order to write code
> that you don't have to keep re-writing when the width of 'CTPBitCnt'
> changes is how you would want to express it. Even if it were legal,
> it is just a butt ugly version of what is currently available with
> VHDL'93. It's not an improvement, it's worse. Not only do you have
> to specify the width (as you do today) but now the intent of the
> statement is only clear to those who understand that a 'D' or an 'X'
> preceding a constant is specifying the bit width of the
> constant....ummmm....OK, I think I'll stick with today's to_unsigned
> notation.
For details about signed, unsigned, meaning of D or X, see my presentations.
Since I have been posting links to the presentation, I am surprised you
waited to reflect such negative comments.
If you want to have an opinion in what is done, I suggest that you
PARTICIPATE in the standards.
Cheers,
Jim Lewis
SynthWorks
IEEE VHDL and Analysis Standards Group, http://www.eda.org/vasg
Jim Lewis
For fixed point math, to address the range issue, this seems
reasonable, but it also seems open other issues. For example,
if I use an intermediate object that is too small, overloading
":=" will automatically downsize it.
> Personally I think this leaves VHDL's fixed-point package
> holed below the waterline; I would never use it on a
> serious project because of this risk of silent rescaling.
I think no matter what you do there are issues to watch.
> Reason 2: There are a few places in VHDL where you need a
> boolean expression, but other kinds of expression would
> make good sense. For example:
>
> signal enable: std_logic;
> ...
> if enable then ... -- currently illegal
There is something for this already ("??"). Although := overloading
could be made to work the same way. There are lots of details.
Cheers,
Jim
Jim Lewis
>> BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
>> if your vendors were looking out for your interests, they would
>> have already should implemented these.
>>
>> Make sure to submit these as bug/enhancement requests. This is important
>> as this is what lets them know the VHDL community wants the new features.
>>
>
Don't hold your breath.
The only way to get what you can live with (not necessarily even
what you want) is to participate in the standards development.
Yacking out here is like screaming at a mountain.
Cheers,
Jim
P.S.
If you are an expert VHDL coder there is no reason you should
not be participating.
Jonathan Bromley
>> [overloaded := operator] would prevent errors that are
>> currently unavoidable: if you use := or <= to copy a
>> fixed-point value from one place to another, and the
>> target object is of the wrong subytpe, you can get its
>> fixed-point scaling silently and disastrously screwed-up.
>
>For fixed point math, to address the range issue, this seems
>reasonable, but it also seems open other issues. For example,
>if I use an intermediate object that is too small, overloading
>":=" will automatically downsize it.
This is true, although errors of precision seem to me
to be less disastrous than errors of scaling. In truth,
there is probably no one-size-fits-all solution to this
kind of problem. For example, fixed-point math surely
needs both saturating and truncating forms of overflow;
how can that be controlled, for individual assignments,
without needing very clunky syntax?
VHDL is a million miles ahead of Verilog, and of just about
any other language, in its ability to support this kind of
control. Assignment overloading allows the programmer to
take *sub*type compatibility into account for assignment,
whereas the base language only considers *type*
compatibility. In an ideal world one could imagine the
ability to add user attributes that behave more like
built-in attributes - i.e. they propagate from actual to
formal parameters of a subprogram - so that a variable
could be tagged as "when assigning to me, do saturating
overflow" or "when assigning to me, error out if my
(target) subtype doesn't match the expression's subtype".
>> Personally I think this leaves VHDL's fixed-point package
>> holed below the waterline; I would never use it on a
>> serious project because of this risk of silent rescaling.
>I think no matter what you do there are issues to watch.
Fair enough. I took care to qualify my statement with
"personally" - others will surely see things differently.
>> Reason 2: There are a few places in VHDL where you need a
>> boolean expression, but other kinds of expression would
>> make good sense. For example:
>>
>> signal enable: std_logic;
>> ...
>> if enable then ... -- currently illegal
>
>There is something for this already ("??"). Although := overloading
>could be made to work the same way. There are lots of details.
OK. Again there's some personal preference/prejudice at work
here: I'm probably over-sensitive in my distaste for special-
purpose syntax designed to deal with a single issue.
Thanks for the sanity-check!
KJ
"Jim Lewis" <j...@synthworks.com> wrote in message
news:O9GdnawnGcWjz8jV...@posted.easystreetonline...
> Jonathan,
>> More important still, it would prevent errors that are currently
>> unavoidable: if you use := or <= to copy a fixed-point value from one
>> place to another, and the target object is of the wrong subytpe, you can
>> get its
>> fixed-point scaling silently and disastrously screwed-up.
>
> For fixed point math, to address the range issue, this seems
> reasonable, but it also seems open other issues. For example,
> if I use an intermediate object that is too small, overloading
> ":=" will automatically downsize it.
>
Another solution might be to allow a function access to attributes of the
thing being copied to. Similar to C++ and 'this', maybe a function that
could get the range of the target with something like that'range. So you
could do
function blah(a, b:ufixed) return ufixed is
variable ReturnVal: ufixed(that'range);
begin
...
return(ReturnVal);
Or (perhaps simpler), 'that' would be the thing that can be assigned to and
returned. It would likely require the user of function blah to explicitly
define the range of the target so composing multiple function like
y <= blah(a, blah(b, c))
might not be possible....or maybe it could if the function would define the
range that *it* thought was correct, and just use that'range to error out if
the range wasn't appropriate. In any case, it would give the function some
knowledge of attributes of the target beyond just the signal/variable type.
Kevin Jennings
KJ
> KJ,
>>> BTW, these are also in Accellera standard VHDL-2006-rev3.0, so
>>> if your vendors were looking out for your interests, they would
>>> have already should implemented these.
>>>
>>> Make sure to submit these as bug/enhancement requests. This is
>>> important
>>> as this is what lets them know the VHDL community wants the new
>>> features.
>>>
>>
>> I'll wait for one I like to see first.
>
> Don't hold your breath.
>
I never do, I find work arounds instead...much more effective than breath
holding.
> The only way to get what you can live with (not necessarily even
> what you want) is to participate in the standards development.
>
I think you misinterpreted what I meant. By saying "I'll wait for one I
like to see first" I was simply stating that this particular member of the
VHDL community wasn't going to bug the vendors for *this* particular
enhancement to be implemented since I just don't see myself using it for the
reasons that have been pointed out. A new feature that I *am* interested in
using is something I would bug them for if it wasn't already implemented.
Presumably the indiviauals that thought the 'D' 'X' notation is what the
VHDL world needs are the ones that should be voicing their needs if their
tools don't support it.
> Yacking out here is like screaming at a mountain.
>
Not really, it's an open forum to discuss problems that others might know a
solution for. Kind of a pre-screening before submitting a bug/enhancement
request. Sometimes the gripe ends in a legitimate enhancement request,
sometimes it ends in the griper learning something they didn't know.
> P.S.
> If you are an expert VHDL coder there is no reason you should
> not be participating.
No idea whether I would qualify as an expert, but I can peruse Accelera and
see what the needs might be.
Kevin Jennings
Brian Drummond
<brian_d...@btconnect.com> wrote:
>>What I mean...
>> CTPBitCnt <= 1;
>>
>>What I have to write...
>> CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
>>
>>Doesn't that seem a bit wordy? I guess this example goes back to the
>>inability to overload the assignment operator which someone has
>>indicated may be changed in the next revision of the language.
>
>
>Ironically, thanks to overloaded operators,
>
>CTPBitCnt <= (others => '0') + 1;
>
>will work, and I would hope any synthesis tool would realise both inputs
>are constant.
>
>It's not pretty though...
Following on from this: (I apologise for not having tried it; I have no
access to a simulator at the moment)
Overload the unary "+" operator. This is commonly done in Ada for
various purposes; I don't see why it won't work in VHDL.
If so, then it ought to be possible to make
CTPBitCnt <= +1;
work.
subtype BitCntType is ...
signal CTPBitCnt : BitCntType;
function "+" (int:integer) return BitCntType is
variable BitCnt:BitCntType := to_unsigned(int, BitCntType'length);
begin
return BitCnt;
end function "+";
Offhand I don't see it working with unconstrained types like unsigned,
which makes it less attractive. Does anyone know better?
- Brian
Jonathan Bromley
>Overload the unary "+" operator. This is commonly done in Ada for
>various purposes; I don't see why it won't work in VHDL.
>
>If so, then it ought to be possible to make
>CTPBitCnt <= +1;
>work.
>
>subtype BitCntType is ...
>
>signal CTPBitCnt : BitCntType;
>
>function "+" (int:integer) return BitCntType is
>variable BitCnt:BitCntType := to_unsigned(int, BitCntType'length);
>begin
> return BitCnt;
>end function "+";
>
>Offhand I don't see it working with unconstrained types like unsigned,
>which makes it less attractive. Does anyone know better?
That's exactly the problem; the function signature for an operator
overload (or any other overloaded function) does NOT take subtype
into account, but only type. So your overloaded "+" could only
be made to target exactly one width of UNSIGNED. Bummer.
Going the other way:
function "+"(u: unsigned) return natural is
begin
return to_integer(u);
end;
works nicely, though...
Andy
> On Jun 10, 5:59 pm, Andy <jonesa...@comcast.net> wrote:
> > One more point: just try to design a fixed or floating point
> > arithmetic design with verilog!
>
> Is that a point? What was the point? Are you trying to say that
> users don't design arithmetic circuits in Verilog??? I am pretty sure
> that the limited work I have done in Verilog has included arithmetic.
> I must be missing your point.
My point is FIXED or FLOATING point arithmetic, not just arithmetic in
general. Verilog as a language does not pass index ranges along with
vectors into operators or functions, so verilog has no means of either
handling a user-definable data subtype that communicates the location
of binary point, or of defining operators and functions that can
operate on those subtypes automatically. Of course, verilog can do
arithmetic, but for FIXED/FLOATING, you have to manage the binary
point (and/or exponent) manually. Sometimes a little language
complexity makes the big picture a lot less complex and error prone.
Andy
KJ
> KJ,
>
> > A: CTPBitCnt <= 1;
> > B: CTPBitCnt <= to_unsigned(1);
> > C: CTPBitCnt <= to_unsigned(1, CTPBitCnt'length);
> > D: set(CTPBitCnt, "<=", 1);
> > E: CTPBitCnt <= 15D"1"
> > F: CTPBitCnt <= CTPBitCnt'length D"1";??
>
> A couple of comments.
> Which of these solutions work for numbers larger than 31 bits?
>
Trick question...VHDL does not guarantee support for 'numbers' beyond
+/- 2**31 (or thereabouts) so 'A-D' do not, they do work over the
entire range of input parameters, which is what you would expect of a
good function. Once the Accelera folks see fit to either extend
integers (or create a new type) that can even represent 'numbers' with
more than 32 bits of precision these functions would still work.
'E' and 'F' do not work with 'numbers' they work with a pair of
literal text strings.
> Beyond strong typing, I think the array sizing rules are important.
Definitely.
>
> For details about signed, unsigned, meaning of D or X, see my presentations.
> Since I have been posting links to the presentation, I am surprised you
> waited to reflect such negative comments.
>
Negative only in the sense that it is not a solution for converting an
integer into a (un)signed except in the most constrained case (i.e.
the constant will never have a need to change or be parameterized, and
the target length will never a need to change or be parameterized).
Once you get outside of that boundary that notation won't help. Over
the years, I've found that 'never' happens quite frequently.
The fact that it is useful in those constrained cases may make it
useful to some and I won't begrudge them the opportunity to make the
language easier for them if they think it helps even if I see no
benefit to me. For me, I rarely come across an unsigned that I won't
want to have a parameterized length.
> If you want to have an opinion in what is done, I suggest that you
> PARTICIPATE in the standards.
>
I've submitted a couple enhancements that I believe were accepted.
KJ
KJ
> "Jim Lewis" <j...@synthworks.com> wrote in message
A bit of a follwup on the previous post. After pondering a bit more
it seems that having an optional keyword on function declarations
might do the trick.
Ex:
function foo(a, b: ufixed) return constrained ufixed;
Such a function could then query attributes of the target type to get
the info that it needs (i.e. target'left, target'right, target'range,
target'length) to do it's job. A function without the 'constrained'
keyword would be today's ordinary function call which of course would
have to determine the range of the thing that it is going to return
based on the input parameters alone.
Ex:
function foo(a, b: ufixed) return ufixed;
These functions would be overloaded, the compiler would choose the
appropriate one based on whether or not the target has a defined range
or not. If it did, it would call the 'constrained' version, if not it
would call the 'classic' version.
Such a method would:
- Allow for functions to be aware of attributes of the target that are
important to the function, not just the base type of the target.
- Not require overloading "<=" or ":="
- Still allow for different functions (i.e. the 'classic' version) to
exist which determine the output range based on the input ranges of
the input parameters.
It would eliminate the possibility of getting something wrong in
things where you need to provide attribute information about the
target through a separate input parameter; the classic example being
x <= to_unsigned(Some_Constant, x'length);
Just a thought.
Kevin Jennings
Jim Lewis
>>> I'll wait for one I like to see first.
>> Don't hold your breath.
>>
>
> I never do, I find work arounds instead...much more effective than breath
> holding.
>
>> The only way to get what you can live with (not necessarily even
>> what you want) is to participate in the standards development.
>>
>
> I think you misinterpreted what I meant. By saying "I'll wait for one I
> like to see first" I was simply stating that this particular member of the
> VHDL community wasn't going to bug the vendors for *this* particular
> enhancement to be implemented since I just don't see myself using it for the
> reasons that have been pointed out. A new feature that I *am* interested in
> using is something I would bug them for if it wasn't already implemented.
>
> Presumably the indiviauals that thought the 'D' 'X' notation is what the
> VHDL world needs are the ones that should be voicing their needs if their
> tools don't support it.
Oops. I must have overreacted. This is exactly what I would ask all to
do - nag your vendor for the features you need and/or want.
>> P.S.
>> If you are an expert VHDL coder there is no reason you should
>> not be participating.
>
> No idea whether I would qualify as an expert, but I can peruse Accelera and
> see what the needs might be.
My opinion is that anyone out here who is actively answering questions
would bring value to the standards groups. Design expertise can help
weigh and understand language requests and feature implementations.
The group already has a number of members who are from eda vendors
and are LRM wizards (although there are room for more of these too).
Not sure if Accellera is willing to fund another round of revisions,
so it is likely the work will move back to IEEE and we will need to
put together a new funding model.
Cheers,
Jim
Brian Drummond
<jonathan...@MYCOMPANY.com> wrote:
>On Mon, 16 Jun 2008 11:43:24 +0100, Brian Drummond wrote:
>
>>Overload the unary "+" operator. This is commonly done in Ada for
>>various purposes; I don't see why it won't work in VHDL.
>>function "+" (int:integer) return BitCntType is
>>variable BitCnt:BitCntType := to_unsigned(int, BitCntType'length);
>>begin
>> return BitCnt;
>>end function "+";
>>
>>Offhand I don't see it working with unconstrained types like unsigned,
>>which makes it less attractive. Does anyone know better?
>
>That's exactly the problem; the function signature for an operator
>overload (or any other overloaded function) does NOT take subtype
>into account, but only type. So your overloaded "+" could only
>be made to target exactly one width of UNSIGNED. Bummer.
Aieee! of course! you can't even write different versions for different
subtypes of unsigned; they have to be different types which would bite
you, harder, in other places.
- Brian