Syntax questions
Tim Hitz
1. Is there a shorthand notation, like the (others=>’0’) clause that will
work
in the if statement rather than having to type out 31 0’s?
2. How do I eliminate the error with conv_integer function, which is looking
for a std_logic_vector, but I only have 1 bit to pass?
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity TIMER is
port (
CLOCK: in STD_LOGIC;
DUMP: out STD_LOGIC;
);
end TIMER;
architecture TIMER_arch of TIMER is
signal vector_name: std_logic_vector(30 downto 0);
begin
process(vector_name)
variable variable_name: integer range 1000 downto 0;
begin
if(vector_name = (others=>'0')) then
-- if(vector_name = "0000000000000000000000000000000") then
variable_name := conv_integer(vector_name(0));
end if;
end process;
end TIMER_arch;
me...@mench.com
wrote in article <3A6C...@MailAndNews.com>:
> 1. Is there a shorthand notation, like the (others=>'0') clause that
> will work in the if statement rather than having to type out 31 0's?
This is in the FAQ (http://vhdl.org/comp.lang.vhdl) (or should be if
it isn't--Edwin?)
Try "if (vector_name = (vector_name'range => '0') then".
> 2. How do I eliminate the error with conv_integer function, which is
> looking for a std_logic_vector, but I only have 1 bit to pass?
Try "conv_integer(vector_name(0 downto 0)"; but, on second thought,
don't use std_logic_unsigned, use numeric_std.
Hope this helps,
Paul
--
Paul Menchini | "There must have been a time, probably somewhere near
Menchini & Associates | the beginning, when we could have said 'no.'"
www.mench.com | -- from "Rosencrantz and Guildenstern are Dead"
Tim Hitz
the 'range operator worked great!
I looked in the numeric_std.vhd file and found a function which received
"unsigned" as an argument, but not std_logic_vector.
function CONV_INTEGER(ARG: UNSIGNED) return INTEGER is
function CONV_INTEGER(ARG: SIGNED) return INTEGER is
I tried to switch to using numeric_std.all and received a syntax error of
"CONV_INTEGER is not declared" from my Xilinx tools. Possibly a Xilinx bug?
Thanks for the url site reference! It should be a tremendous help to a VHDL
new user, like me!
Tim
>===== Original Message From me...@mench.com =====
------------------------------------------------------------
Get your FREE web-based e-mail and newsgroup access at:
http://MailAndNews.com
Create a new mailbox, or access your existing IMAP4 or
POP3 mailbox from anywhere with just a web browser.
------------------------------------------------------------
Colin Marquardt
> I tried to switch to using numeric_std.all and received a syntax error of
> "CONV_INTEGER is not declared" from my Xilinx tools. Possibly a Xilinx bug?
You don't use CONV_INTEGER with numeric_std. See
http://www.vhdl.org/comp.lang.vhdl/FAQ1.html#integer_bit_vector
and the following section.
Cheers,
Colin
Ray Andraka
Numeric_std purposely forces you to unambiguously state the meanings of the
bits, so the to_integer only
makes sense if the vector is type signed or unsigned. To do the conversion from
std_logic_vector to integer
using numeric_std do:
integer_signal<= to_integer(unsigned(std_logic_vector_signal));
and to go the other way:
std_logic_vector_signal<= to_unsigned(integer_signal,number_of_bits);
you can replace "unsigned" with "signed" in either of the above if it suits you.
Doing a direct conversion of std_logic_vector makes no sense, since the bit
definitions are not known to the
compiler. A std_logic vector bit assignment could just as well be decoded
states (sleep, wake-up, eat, blow-away-your-enemy, etc), or switch inputs
or.... well, you get the picture. Using unsigned or signed types removes any
ambiguity.
--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email r...@andraka.com
http://www.andraka.com or http://www.fpga-guru.com
Chris Dunlap
Chris Dunlap
(FPGA Express), you should probably just use std_logic_arith.
With any other tool you should use the IEEE standard numeric_std.
std_logic_arith was produced by Synopsys and seems to best for their tools. I
honestly do not play with FPGA express too much these days so I can't speak too
intelligently on its ability to handle numeric_std. I know FPGA Express does
incorporate numeric_std so it should work with some degree of functionality.
I will attempt to play with the code you have in FPGA Express tomorrow to see if I
can make any light of Express's problems with numeric_std if any.
Chris Dunlap
Renaud Pacalet
>
> I'm not aware of CONV_INTEGER in numeric_std;
>
> Numeric_std purposely forces you to unambiguously state the meanings of the
> bits, so the to_integer only
> makes sense if the vector is type signed or unsigned. To do the conversion from
> std_logic_vector to integer
> using numeric_std do:
>
> integer_signal<= to_integer(unsigned(std_logic_vector_signal));
>
> and to go the other way:
>
> std_logic_vector_signal<= to_unsigned(integer_signal,number_of_bits);
Shouldn't it be:
std_logic_vector_signal <=
std_logic_vector(to_unsigned(integer_signal,number_of_bits));
?
Regards,
--
Renaud Pacalet, ENST / COMELEC, 46 rue Barrault 75634 Paris Cedex 13
Tel. : 01 45 81 78 08 | Fax : 01 45 80 40 36 | Mel : pac...@enst.fr
Edwin Naroska
me...@mench.com wrote:
> On Wed, 17 Jan 2001 12:45:58 -0500, Tim Hitz <th...@MailAndNews.com>
> wrote in article <3A6C...@MailAndNews.com>:
>
> > 1. Is there a shorthand notation, like the (others=>'0') clause that
> > will work in the if statement rather than having to type out 31 0's?
>
> This is in the FAQ (http://vhdl.org/comp.lang.vhdl) (or should be if
> it isn't--Edwin?)
It is (part 1, section 4.2.5 "Operations With Array Aggregates").
--
Edwin
pratyush kamal
for i in 0 to 30 loop
if vector_name(i) = '0' then
..
..
end if;
end loop;
and for conv_integer (if that one bit is giving problem)
concatenate it !
variable_name := conv_integer('0' & vector_name(0));
> process(vector_name)
> variable variable_name: integer range 1000 downto 0;
> begin
> if(vector_name = (others=>'0')) then
> -- if(vector_name = "0000000000000000000000000000000") then
> variable_name := conv_integer(vector_name(0));
> end if;
>
> end process;
> end TIMER_arch;
--
-------------------------------------------------------------------------
Pratyush Kamal Phone: +31 40 2744376
Philips Research Laboratories Fax: +31 40 2744090
Prof. Holstlaan 4, WAG 11
5656 AA Eindhoven
The Netherlands
mailto: pratyus...@philips.com
me...@mench.com
<ed...@ds.e-technik.uni-dortmund.de> wrote in article
<3A66CD85...@ds.e-technik.uni-dortmund.de>:
Edwin,
> It is (part 1, section 4.2.5 "Operations With Array Aggregates").
I thought so, but I couldn't *quite* remember!
(It's hell getting old, but it still beats the alternative!)
me...@mench.com
wrote in article <3A71...@MailAndNews.com>:
> Thanks, Paul, the 'range operator worked great!
You're welcome!
> I looked in the numeric_std.vhd file and found a function which received
> "unsigned" as an argument, but not std_logic_vector.
> function CONV_INTEGER(ARG: UNSIGNED) return INTEGER is
> function CONV_INTEGER(ARG: SIGNED) return INTEGER is
> I tried to switch to using numeric_std.all and received a syntax
> error of "CONV_INTEGER is not declared" from my Xilinx
> tools. Possibly a Xilinx bug?
That, or (more probably), you tried to pass a std_(u)logic_vector to
one of these functions. The main difference between the
(pseudo-standard) package std_logic_arith and the (real standard)
package numeric_std is that the latter makes no assumptions about how
numbers are encoded as strings of bits. If you want unsigned
magnitude, then you use UNSIGNED types; if you want 2's-complement,
then you use SIGNED types (and if you want something else, then you
don't use numeric_std!).
Now the Great Karnak predicts that your next question will be "How do
I convert between std_(u)logic_vector and UNSIGNED and SIGNED?" Don't
worry, the FAQ tells all.
> Thanks for the url site reference! It should be a tremendous help to
> a VHDL new user, like me!
Believe it or not, it's also a tremendous help to those of us who hang
out on this newsgroup! <g>
Tim Hitz
I think I understand your technique. I call the Xilinx FAE and he suggested
only using the libraries:
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
for all vhdl code and not using numeric_std.
The proposed merits are that you can use expression, such as:
cnt_vector <= cnt_vector+1;
rather than:
cnt_vector <= std_logic_vector(unsigned(cnt_vector)+1);
Being new to VHDL, is this a "style" type of question, or are there strong
merits in doing it a specific way. The first expression is obviously
simpler,
but are there hidden dangers in writing code this way?
What did you mean by (pseudo-standard) for std_logic_arith and
(real standard) numeric_std?
Tim
>===== Original Message From me...@mench.com =====
------------------------------------------------------------
Andy Peters n o a o [.] e d u>
>
> Paul,
> I think I understand your technique. I call the Xilinx FAE and he suggested
> only using the libraries:
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> for all vhdl code and not using numeric_std.
I wish the FAEs would keep up-to-date on their tools. FPGA Express has
supported numeric_std for quite a while now.
> The proposed merits are that you can use expression, such as:
> cnt_vector <= cnt_vector+1;
> rather than:
> cnt_vector <= std_logic_vector(unsigned(cnt_vector)+1);
You can certainly use the former expression with numeric_std. What I
usually do for counters is declare the counter register as a bounded
integer, e.g.,
signal cnt_vector : integer range 0 to 63;
and operations are simple
cnt_vector <= cnt_vector + 1;
and if you need that counter turned into a std_logic_vector, or
something, you'd simply do:
cnt_slv <= std_logic_vector(to_unsigned(cnt_vector, cnt_slv'length));
Of course, you could have declared cnt_vector to be an unsigned:
signal cnt_vector : unsigned(6 downto 0);
but I prefer integer simply because the bound is more obvious.
> Being new to VHDL, is this a "style" type of question, or are there strong
> merits in doing it a specific way. The first expression is obviously
> simpler,
> but are there hidden dangers in writing code this way?
No.
> What did you mean by (pseudo-standard) for std_logic_arith and
> (real standard) numeric_std?
std_logic_arith, std_logic_unsigned and std_logic_signed were created by
synopsys to handle arithmetic operations, but instead of creating a
synopsys library, they stuff the packages into the standard ieee
library. AFAIK, the synopsys libraries were never submitted to the IEEE
for standardization.
numeric_std, of course, is an IEEE standard library, and if your
compiler/synthesizer doesn't support it, upgrade.
-- a
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u
"It is better to be silent and thought a fool,
than to send an e-mail to the entire company
and remove all doubt."
me...@mench.com
wrote in article <3A6E...@MailAndNews.com>:
> I think I understand your technique. I call the Xilinx FAE and he suggested
> only using the libraries:
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> for all vhdl code and not using numeric_std.
Unless his tools don't support numeric_std, IMHO you should use
numeric_std, not the latter two. (And, if they don't, you might
consider switching....)
> The proposed merits are that you can use expression, such as:
> cnt_vector <= cnt_vector+1;
> rather than:
> cnt_vector <= std_logic_vector(unsigned(cnt_vector)+1);
IMHO, that is not a merit, but a demerit. Incrementing a vector can
yield either nonsense (if it doesn't represent a number) or different
results (depending on how the number is encoded into the vector).
Numeric_std enforces this discipline, while std_logic_arith, et. al.,
doesn't. But, I suppose it's somewhat a matter of taste.
Note that there's another alternative to
cnt_vector <= std_logic_vector(unsigned(cnt_vector)+1);
Just declare cnt_vector to be unsigned, and use
cnt_vector <= cnt_vector + 1;
with the full assurance that you're really incrementing an
unsigned-magnitude number. If you MUST have std_logic_vector
interfaces (why, if they're really numbers?), then just convert it on
the way in/out.
> Being new to VHDL, is this a "style" type of question, or are there
> strong merits in doing it a specific way. The first expression is
> obviously simpler, but are there hidden dangers in writing code this
> way?
Well, now we (re-)start Religious War 16#443da49cf#....
But seriously: I've given some reasons for my suggestion elsewhere in
this response. But, people differ on whether these reasons are
positive or negative reasons for using a given package.
Generally speaking, the more complex the model you're writing, and the
more costly the ramifications of errors in your model, the more
structured a style you want to use.
> What did you mean by (pseudo-standard) for std_logic_arith and (real
> standard) numeric_std?
Different vendors supply different versions of std_logic_arith *with*
*different* *semantics*. Numeric_std works the same everywhere--or
should, in the absence of bugs.
Colin Marquardt
> You can certainly use the former expression with numeric_std. What I
> usually do for counters is declare the counter register as a bounded
> integer, e.g.,
>
> signal cnt_vector : integer range 0 to 63;
[...]
> Of course, you could have declared cnt_vector to be an unsigned:
>
> signal cnt_vector : unsigned(6 downto 0);
>
> but I prefer integer simply because the bound is more obvious.
Use natural and the bound is even more obvious. :-)
[and you probably mean (*5* downto 0)]
Generally speaking (of course I am not talking to you Andy), restrict
it to the smallest set that is possible. If the count can not exceed,
say, 50 (i.e., a number not equal to 2^n-1), then by all means use
the "integer/natural/positive range" construct. True, synthesis will
still require 6 bits for the counter register, but simulation will
catch it if you ever exceed your range-imposed limit. Quite helpful.
Colin
Ray Andraka
Renaud Pacalet wrote:
> > and to go the other way:
> >
> > std_logic_vector_signal<= to_unsigned(integer_signal,number_of_bits);
>
> Shouldn't it be:
>
> std_logic_vector_signal <=
> std_logic_vector(to_unsigned(integer_signal,number_of_bits));
>
> ?
>
Yes, my fingers must have gotten too slow compared to the thought once again.
Ray Andraka
Well, there is a hidden danger if you have need stuff from both the signed and
unsigned in the
same architecture. If you have both the std_logic_unsigned and signed there are
conflicts for the definitions.
Renaud Pacalet
>
> Renaud Pacalet wrote:
>
> > > and to go the other way:
> > >
> > > std_logic_vector_signal<= to_unsigned(integer_signal,number_of_bits);
> >
> > Shouldn't it be:
> >
> > std_logic_vector_signal <=
> > std_logic_vector(to_unsigned(integer_signal,number_of_bits));
> >
> > ?
> >
>
> Yes, my fingers must have gotten too slow compared to the thought once again.
>
Maybe could you try the famous
FINGERS'MIN_DELAY := 10 ns;
attribute ;-)
Renaud Pacalet
I have a stupid question that you certainly can answer:
why UNSIGNED and SIGNED types from IEEE.NUMERIC_STD are they based
on STD_LOGIC and not STD_ULOGIC ?
It looks strange to me as it prevents the tools from checking
possible unwanted multiple drives on those types. Do you have a clue
on this choice ? Thanks.
me...@mench.com
wrote in article <3A67F718...@enst.fr>:
> I have a stupid question that you certainly can answer:
Not stupid at all. IMHO, an excellent one.
> why UNSIGNED and SIGNED types from IEEE.NUMERIC_STD are they based
> on STD_LOGIC and not STD_ULOGIC ?
> It looks strange to me as it prevents the tools from checking
> possible unwanted multiple drives on those types. Do you have a clue
> on this choice ? Thanks.
I think it all boils down to "People with weak stomachs should never
watch laws, sausages and standards being made."
I believe the reason was to keep the number of types to a minimum.
And "everybody" uses std_logic, so that was the element type to
use....
For simulation purposes, it would be easy enough to create your own
version of numeric_std using std_ulogic as the element type. You'd
catch the conflicts at that point. When satisified, just change the
use clauses to the real numeric_std, and let your synthesizer have at
it....
J. Bhasker
This was one of the tough decisions we (the 1076.3 WG)
had to make. One of the
critical factors that affected our decision was
Sec A.10 of the Std1164 (package STD_LOGIC_1164) standard,
which recommends that STD_LOGIC_VECTOR is the preferred vector type.
- bhasker
VhdlCohen
I liked your response to the isue of std_arith/std_logic_unsigned verses
numeric_std. However, for designers of controller logic where unsigned
arithmetic is used, it really is a hassle to HAVE to do type conversion (see
example below). In fact, the strong type checking of VHDL is one of the things
that Verilog users hate about the language. No, I am not in favor of Verilog,
and I do understand the advantages of strong type checking. However, by using
the std_logic_unsigned package, a user can do arithmetic on objects of type
std_logic_vector and integers without type conversions. in summary, I
understand the merit of what you are saying about the numeric_std, but I can
also see why there is some reluctance to use exclusively. After all, the
Synopsys packages were used for many years...
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity StdTest is
port (
Data : in std_logic_vector(7 downto 0);
Load : in std_logic;
CLk : in std_logic;
Threshold : in std_logic_vector(7 downto 0);
Reached_Threshold : out std_logic);
end entity StdTest;
architecture RTL of StdTest is
signal Counter : std_logic_vector(7 downto 0);
begin -- architecture RTL
Counter_Proc: process is
begin -- process Counter
wait until Clk = '1';
if Load = '1' then
Counter <= Data;
else
Counter <= Counter + 1;
end if;
end process Counter_Proc;
Reached_Threshold <= '1' when Counter = Threshold else
'0';
end architecture RTL;
-------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity NumericTest is
port (
Data : in std_logic_vector(7 downto 0);
Load : in std_logic;
CLk : in std_logic;
Threshold : in std_logic_vector(7 downto 0);
Reached_Threshold : out std_logic);
end entity NumericTest;
architecture RTL of NumericTest is
signal Counter : Unsigned(7 downto 0);
signal Data_u : Unsigned(7 downto 0);
signal Threshold_u : Unsigned(7 downto 0);
begin -- architecture RTL
-- Type converted signals
Counter_Proc: process is
begin -- process Counter
wait until Clk = '1';
if Load = '1' then
Counter <= Data_u;
else
Counter <= Counter + 1;
end if;
end process Counter_Proc;
Reached_Threshold <= '1' when Counter = Threshold_u else
'0';
end architecture RTL;
Subject: Re: Syntax questions
From: me...@mench.com
Date: 1/18/01 12:18 PM Pacific Standard Time
Message-id: <947j2l$48n$1...@mench.mench.com>
On Thu, 18 Jan 2001 13:01:01 -0500, Tim Hitz <th...@MailAndNews.com>
wrote in article <3A6E...@MailAndNews.com>:
> I think I understand your technique. I call the Xilinx FAE and he suggested
> only using the libraries:
> use IEEE.STD_LOGIC_1164.ALL;
> use IEEE.STD_LOGIC_ARITH.ALL;
> use IEEE.STD_LOGIC_UNSIGNED.ALL;
> for all vhdl code and not using numeric_std.
Unless his tools don't support numeric_std, IMHO you should use
numeric_std, not the latter two. (And, if they don't, you might
consider switching....)
> The proposed merits are that you can use expression, such as:
> cnt_vector <= cnt_vector+1;
> rather than:
> cnt_vector <= std_logic_vector(unsigned(cnt_vector)+1);
IMHO, that is not a merit, but a demerit. Incrementing a vector can
yield either nonsense (if it doesn't represent a number) or different
results (depending on how the number is encoded into the vector).
Numeric_std enforces this discipline, while std_logic_arith, et. al.,
doesn't. But, I suppose it's somewhat a matter of taste.
Note that there's another alternative to
cnt_vector <= std_logic_vector(unsigned(cnt_vector)+1);
Just declare cnt_vector to be unsigned, and use
cnt_vector <= cnt_vector + 1;
with the full assurance that you're really incrementing an
unsigned-magnitude number. If you MUST have std_logic_vector
interfaces (why, if they're really numbers?), then just convert it on
the way in/out.
> Being new to VHDL, is this a "style" type of question, or are there
> strong merits in doing it a specific way. The first expression is
> obviously simpler, but are there hidden dangers in writing code this
> way?
Well, now we (re-)start Religious War 16#443da49cf#....
But seriously: I've given some reasons for my suggestion elsewhere in
this response. But, people differ on whether these reasons are
positive or negative reasons for using a given package.
Generally speaking, the more complex the model you're writing, and the
more costly the ramifications of errors in your model, the more
structured a style you want to use.
> What did you mean by (pseudo-standard) for std_logic_arith and (real
> standard) numeric_std?
Different vendors supply different versions of std_logic_arith *with*
*different* *semantics*. Numeric_std works the same everywhere--or
should, in the absence of bugs.
Paul
--
Paul Menchini | "There must have been a time, probably somewhere near
Menchini & Associates | the beginning, when we could have said 'no.'"
www.mench.com | -- from "Rosencrantz and Guildenstern are Dead"
--------------------------------------------------------------------------
------------------------------------------
Ben Cohen Publisher, Trainer, Consultant (310) 721-4830
http://www.vhdlcohen.com/ vhdl...@aol.com
Author of following textbooks:
* Component Design by Example ... a Step-by-Step Process Using
VHDL with UART as Vehicle", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
--------------------------------------------------------------------------
------------------------------------------
Renaud Pacalet
>
> On Fri, 19 Jan 2001 09:13:12 +0100, Renaud Pacalet <pac...@enst.fr>
> wrote in article <3A67F718...@enst.fr>:
>
> > I have a stupid question that you certainly can answer:
>
> Not stupid at all. IMHO, an excellent one.
>
> > why UNSIGNED and SIGNED types from IEEE.NUMERIC_STD are they based
> > on STD_LOGIC and not STD_ULOGIC ?
>
> > It looks strange to me as it prevents the tools from checking
> > possible unwanted multiple drives on those types. Do you have a clue
> > on this choice ? Thanks.
>
> I think it all boils down to "People with weak stomachs should never
> watch laws, sausages and standards being made."
>
Aaaaaargh, I'm dead.
> I believe the reason was to keep the number of types to a minimum.
> And "everybody" uses std_logic, so that was the element type to
> use....
Too bad because "everybody" is usually wrong using std_logic.
>
> For simulation purposes, it would be easy enough to create your own
> version of numeric_std using std_ulogic as the element type. You'd
> catch the conflicts at that point. When satisified, just change the
> use clauses to the real numeric_std, and let your synthesizer have at
> it....
Good idea. In fact I'm already doing something similar. I wrote a
package that converts integers to std_ulogic_vectors and
std_ulogic_vectors to integers. It uses numeric_std and hides
unsigned and signed types. All arithmetics are done with integer
types.
I don't like it but I really don't like using resolved types when
not needed...
Thanks for your answer. Regards,
Renaud Pacalet
>
> Renaud:
>
> This was one of the tough decisions we (the 1076.3 WG)
> had to make. One of the
> critical factors that affected our decision was
> Sec A.10 of the Std1164 (package STD_LOGIC_1164) standard,
> which recommends that STD_LOGIC_VECTOR is the preferred vector type.
>
Thanks for this explanation. I don't like it but now I know where it
comes from. Do you have an idea why STD_LOGIC_VECTOR is the
preferred vector type? Regards,