Signed, Unsigned syntax issues. Please help, I'm stumped

I'm still a little new to Xilinx so I'm working through some syntax
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]

nitrogenocide@gmail.com wrote:

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

 

[Mike Treseler]

Mike Treseler wrote:

constant cnt25_c :: cnt25_t := "1101001101010101100100000";
constant cnt25_c : cnt25_t := "1101001101010101100100000";

 

[Jonathan Bromley]

On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:

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

 

[Andy Peters]

On May 31, 4:53 pm, "KJ" <kkjenni...@sbcglobal.net> wrote:

"Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message

news:q0a344h9akcforb27c31h38tre70d2oaml@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

 

[Mike Treseler]

rickman wrote:

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

 

[rickman]

On May 31, 3:43 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:
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.

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

 

[Andy]

On Jun 9, 1:06 pm, rickman <gnu...@gmail.com> wrote:

On May 31, 3:43 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com
wrote:



On Sat, 31 May 2008 11:58:04 -0700 (PDT), nitrogenocide wrote:
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.

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

"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

 

[Jim Lewis]

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?
See:

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]

rickman wrote:

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

 

[rickman]

On Jun 9, 2:28 pm, Mike Treseler <mike_trese...@comcast.net> wrote:

rickman wrote:
---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

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

 

[Andy]

On Jun 9, 6:55 pm, rickman <gnu...@gmail.com> wrote:

On Jun 9, 2:28 pm, Mike Treseler <mike_trese...@comcast.net> wrote:



rickman wrote:
---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

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

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]

On Jun 10, 5:59 pm, Andy <jonesa...@comcast.net> wrote:

On Jun 9, 6:55 pm, rickman <gnu...@gmail.com> wrote:



On Jun 9, 2:28 pm, Mike Treseler <mike_trese...@comcast.net> wrote:

rickman wrote:
---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

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

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?

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

 

[Mike Treseler]

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.

CTPBitCnt <= x"0001";

-- Mike Treseler

 

[KJ]

On Jun 11, 11:52 am, rickman <gnu...@gmail.com> wrote:

On Jun 10, 5:59 pm, Andy <jonesa...@comcast.net> wrote:
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.

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

 

[KJ]

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";

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:41 pm, KJ <kkjenni...@sbcglobal.net> wrote:

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

 

[Brian Drummond]

On Wed, 11 Jun 2008 08:52:56 -0700 (PDT), rickman <gnuarm@gmail.com>
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

 

[KJ]

On Jun 11, 12:17 pm, KJ <kkjenni...@sbcglobal.net> wrote:

On Jun 11, 11:52 am, rickman <gnu...@gmail.com> wrote:


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

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

 

[Mike Treseler]

rickman wrote:

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