Using numeric_std??
Sean
"standard" than std_logic_unsigned, which had overloading issues with
other libraries so I've been trying to use numeric_std instead, but
have found it makes things a bit more difficult
For instance say I have the following libraries, signal, and process
in my code:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.NUMERIC_STD.ALL;
SIGNAL sh_count : std_logic_vector(7 downto 0);
counting: PROCESS(clk, reset)
BEGIN
IF (reset = '1') THEN
sh_count <= "00000000";
ELSIF(clk'EVENT and clk = '1') THEN
IF (sh_count = "11111111") THEN
sh_count <= "00000000";
ELSE
sh_count <= sh_count + 1;
END IF;
END IF;
END PROCESS counting;
This would work using std_logic_unsigned, but doesn't work using
numeric_std. I haven't been able to find a successful way to cast the
sh_count in order to make this work, can anyone give me some pointers?
For instance, I tried writing the ELSE line of code like this:
sh_count <= std_logic_vector(to_unsigned(sh_count, 8) + 1);
but get the following error: to_unsigned can not have such operands
in this context.
I've also tried that line like this:
sh_count <= std_logic_vector(to_integer(sh_count) + 1);
but I get the same error (except it references to_integer instead of
to_unsigned obviously). Does anyone have any pointers?
I was taught and am used to declaring everything as a
std_logic_vector, but would it be better using numeric_std to declare
signals as unsigned(x downto y)??
Pieter Hulshoff
> numeric_std. I haven't been able to find a successful way to cast the
> sh_count in order to make this work, can anyone give me some pointers?
I believe you can simply cast the std_logic_vector by using unsigned(
<std_logic_vector_signal_name> ). I would suggest using unsigned when you're
actually working with unsigned vectors though.
> sh_count <= std_logic_vector(to_unsigned(sh_count, 8) + 1);
to_unsigned is for casting integers to unsigned. Just use unsigned(sh_count)+1
in stead.
> sh_count <= std_logic_vector(to_integer(sh_count) + 1);
to_integer needs either signed or unsigned. The following would work:
sh_count <= std_logic_vector(to_unsigned(to_integeger(unsigned(sh_count))+1));
> I was taught and am used to declaring everything as a
> std_logic_vector, but would it be better using numeric_std to declare
> signals as unsigned(x downto y)??
If you are using unsigned vectors, it is good practice to declare them as such.
If you choose not to however, I'd go with:
sh_count <= std_logic_vector(unsigned(sh_count)+1);
If I'm not mistaken, you should be able to add 1 to an unsigned without any
problems.
It is very good practice to use numeric_std i.s.o. std_logic_unsigned and
std_logic_signed. Try to switch to using it. :) Remember:
unsigned( std_logic_vector ) : converting std_logic_vector to unsigned
std_logic_vector( unsigned ) : converting unsigned to std_logic_vector
to_unsigned( integer, n ) : converting integer to n bits unsigned
to_integer( unsigned ) : converting unsigned to integer
Regards,
Pieter Hulshoff
Alan Raphael
sh_count <= sh_count + "00000001";
and keep sh_count as std_logic_vector?
Sean
Unfortunately, it seems Xilinx's webpack software (XST actually I
guess) is a bit quirky when it comes to numeric_std. For instance, in
the example from my first post it won't let me do as you suggested:
sh_count <= std_logic_vector(unsigned(sh_count) + 1);
results in an error that reads: "Expression in type conversion to
std_logic_vector has 2 possible definitions in this scope, for
example, unsigned and std_logic_vector."
It does, however, let me do this:
sh_count <= (unsigned(sh_count) + 1);
That seems weird since I'd think it wouldn't let you assign an
unsigned to a std_logic_vector (could be wrong though obviously). Of
course, since I use Modelsim to do functional simulation it's a pain
since Modelsim apparently doesn't even recognize the word "unsigned"
at all.
Pieter Hulshoff <phul...@xs4all.nl> wrote in message news:<3e6e55dc$0$49111$e4fe...@news.xs4all.nl>...
Jerry
> I've recently found out about how numeric_std is apparently far more
> "standard" than std_logic_unsigned, which had overloading issues with
> other libraries so I've been trying to use numeric_std instead, but
> have found it makes things a bit more difficult
>
1. Use SIGNED or UNSIGNED data types for all internal signals and variables
to minimize type conversions
2. If your interface uses STD_LOGIC_VECTOR, use type conversions (typecasting)
while translating between the interface signal and internal signal
or variable
3. Feel free to mix and match vector and number arguments of arithmetic and
relational operations, but remember about the result length issues
4. Mixing of vector and element types (i.e. SIGNED with STD_LOGIC) as
arguments is not allowed; consider the use of slices with both bounds
the same instead of indexed expressions (e.g. VEC(3 DOWNTO 3) instead of
VEC(3)) or concatenation of bit argument with an empty string
(e.g. (CIN & "") instead of CIN [parentheses are necessary because
concatenation has precedence level equal or lower than arithmetic
operations])
5. Since variable and signal assignments cannot be overloaded, remember
to use vector expressions on the right-hand side of assignments to vectors
6. Extend the size of arguments to the left if you want to generate
carry / borrow / overflow; use slicing and indexing of the result to
extract required part of the result
re 3.: Allowed combinations of argument types for numeric operators are:
SIGNED / SIGNED
SIGNED / INTEGER
INTEGER / SIGNED
UNSIGNED / UNSIGNED
UNSIGNED / NATURAL
NATURAL / UNSIGNED
Adding operators produce the result vector that retains the size of its
longer vector argument. If one of the arguments is numeric, its vector
counterpart decides what's the size of the result.
Multiplication of two vectors yields the vector that is as long as the sum
of the lengths of the arguments. Multiplication involving vector and number
has the length of the result equal double the length of the vector argument.
Result of division keeps the size of its left (or first) argument, unless
the first argument is the number. In that case the result keeps the size
of the second, vector argument.
Results of all arithmetic operations are normalized so that the vectors
have descending index range and the right bound of the range is equal zero.
And one quick example to conclude:
-------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.numeric_std.all;
entity countRLE is
generic ( max : positive := 3 );
port ( CLK : in STD_LOGIC;
RESET : in STD_LOGIC;
ENABLE : in STD_LOGIC;
LOAD : in STD_LOGIC;
DATA : in STD_LOGIC_VECTOR(max downto 0);
Q : out STD_LOGIC_VECTOR(max downto 0);
TC : out STD_LOGIC
);
end countRLE;
architecture numeric of countRLE is
-- numeric constant used in TC computation:
constant maxcount : positive := 2**(max+1)-1;
signal count : unsigned(max downto 0);
begin
cnt: process(CLK, RESET)
begin
if RESET='1' then
count <= (others=> '0'); -- number would be illegal
elsif rising_edge(CLK) then
if LOAD='1' then
count <= unsigned(DATA); -- typecasting required
elsif ENABLE='1' then
count <= count + 1; -- vector+number
end if;
end if;
end process;
qout: Q <= std_logic_vector(count); -- typecasting required
-- please note vector vs. number comparison in TC assignment:
tcout: TC <= '1' when count=maxcount else '0';
end numeric;
----------------------------------------------------
Good luck!
Jerry
Niv
Succintly put Jerry.
Niv.
"Jerry" <jaro...@hotmail.com> wrote in message
news:711e889f.03031...@posting.google.com...
Mike Treseler
> sh_count <= std_logic_vector(unsigned(sh_count) + 1);
>
> results in an error that reads: "Expression in type conversion to
> std_logic_vector has 2 possible definitions in this scope, for
> example, unsigned and std_logic_vector."
That is because you have two "+" functions in scope,
and modelsim doesn't know which one you mean:
I expect nuking the synopsis library by deleting the line:
use IEEE.STD_LOGIC_ARITH.ALL;
will solve this problem.
> It does, however, let me do this:
>
> sh_count <= (unsigned(sh_count) + 1);
>
> That seems weird since I'd think it wouldn't let you assign an
> unsigned to a std_logic_vector (could be wrong though obviously).
The only weird thing is the synopsis library.
The synopsis "+" function could
return a std_logic vector even though one parameter is unsigned!
Not a nice feature.
The solution is the same as above.
-- Mike Treseler
"Two numeric libraries are not better than one."
Ralf Hildebrandt
> 1. Use SIGNED or UNSIGNED data types for all internal signals and variables
> to minimize type conversions
I would recommend to use everytime std_Ulogic_vector, exept you to
describe some arithmetic operations (+ - > < and so on). Then it should
not be a problem to convert your signals temporarily. Often these
arithmetic operations are very rare in use.
Ports should be std_ulogic_vector in general, because most synthesis
tools are configured to convert all port-signals to this type.
-> So it would be a lot of work, if one has to convert all port-signals
to the sepcific data type, used internally.
Ralf
Brian Drummond
>I've recently found out about how numeric_std is apparently far more
>"standard" than std_logic_unsigned, which had overloading issues with
>other libraries so I've been trying to use numeric_std instead, but
>have found it makes things a bit more difficult
>
>For instance say I have the following libraries, signal, and process
>in my code:
>
>library IEEE;
>use IEEE.STD_LOGIC_1164.ALL;
>use IEEE.STD_LOGIC_ARITH.ALL;
-- Don't use this library AT ALL if you're using Numeric_Std.
>use IEEE.NUMERIC_STD.ALL;
>
>SIGNAL sh_count : std_logic_vector(7 downto 0);
[This ...]
> ELSE
> sh_count <= sh_count + 1;
> END IF;
[... and this]
reveals why you are having difficulty.
What does addition mean to a std_logic_vector? Intrinsically nothing at
all, possibly just about anything. Addition here means NOTHING until you
assign a specific meaning to that vector of bits - is it unsigned? two's
complement? sign+magnitude? one's complement? IBM floating point format?
IEEE 754? ... get the picture?
Specify what you mean by that std_logic_vector before you ask for an
addition.
If you want it to be unsigned or (2's complement) signed, there is a
standard way to do that to make life easy. Use the IEEE.NUMERIC_STD
library and declare your signal to be one of the two subtypes of
std_logic_vector defined therein...
SIGNAL sh_count : unsigned(7 downto 0);
and addition (sh_count+99) will now work perfectly.
Print out and keep handy (or whatever) the numeric_std package, as a
reference to the operations defined therein. That's where you will find
out what "to_unsigned" does, and many other things.
If you needed sign+magnitude, or floating point, I guess the clean way
would be to roll your own library, following the example of numeric_std
as closely as possible. (Though IEEE754 floating point would be a
significant effort!)
If you need to perform logical operations on an unsigned, or math on a
std_logic_vector, cast them as appropriate (casting among subtypes is
safe).
So,
sh_count <= sh_count + unsigned(my_stdlogicvector);
output_port <= std_logic_vector(sh_count);
safely convert from one form to the other.
I started out using unsigned even for I/O ports, going between FPGAs
where it seemed appropriate. This worked fine for simulation and even
synthesis, but the tools did not support it evenly - specifically, they
refused to preserve the "unsigned" type through into a gate-level
netlist. So now I keep std_logic_vector for the top-level I/O, so that I
can switch between RTL and gate-level representations of a chip.
Elsewhere I use unsigned (or signed) throughout my datapaths.
- Brian
Jerry
>
> results in an error that reads: "Expression in type conversion to
> std_logic_vector has 2 possible definitions in this scope, for
> example, unsigned and std_logic_vector."
attached to your design unit - it is an absolute "no-no" due to
numerous overlapping declarations in those packages. If you remove
std_logic_arith it should go through.
As far as ModelSim issue is concerned - check if you have only one
of the two packages atacched to your design, and if the problem
persists - verify if NUMERIC_STD is available in the system. If it is,
UNSIGNED must be recognized...
Good luck!
Jerry
Jerry
Yep, but our problem was dealing with numeric operations on vectors.
Rules I have mentioned apply if you HAVE TO do arithmetic on vectors
inside, and work nicely for both unresolved (...ULOGIC...) and resolved
(...LOGIC...) types in the interface.
I have spent a couple of hours one day writing code for a counter and
simple combinatorial ALU, using all imaginable combinations of internal
and interface data types, conversions, typecastings, packages, etc.
Methodology I have presented in my previous post was clear winner:
-- the shortest code
-- maximal readability
And one more comment: I know perfectly that you don't need anything
more complicated than STD_ULOGIC_VECTOR for register, counter, or
ALU output. But you would be surprised how many tool suites and/or
company coding styles insist on using only one type (e.g. STD_LOGIC_VECTOR)
in ALL cases. Well, it will never change as long as the developer of
the tool "knows better" or official coding style is developed by
"smart cousin of the IT Manager"...
Jerry
Sean
Yes, I had forgotten to remove std_logic_arith, and when I did
everything was fine.
Still having issues with Modelsim, but its different. It recognizes
unsigned now (no doubt my previous problem was again with the
std_logic_arith package). However, when I try to do a functional
simulation it gives me some messages about some truncation going on
when I do some conversion to unsigned, which shouldn't be happening
since I use constants to define lengths throughout the code and
whenever I do a to_unsigned conversion. It's just odd, but when I
synthesize and implement and do a post-translation simulation its fine
(obviously since everything is basically "hardware" blocks now and not
"code").
Alan Fitch
"Sean" <creo...@yahoo.com> wrote in message
news:b97bab2f.03031...@posting.google.com...
would try
and track down this warning. As you are using Modelsim, try
the following.
1. menu Simulation -> Simulation Options...
2. Click on "Assertions"
3. set Break on Assertion to "Warning"
run your simulation and when the warning pops up, the source
code
viewer will have a little arrow pointing to the line in
question.
You should then be able to examine the values of signals and
variables
to figure out what's going on,
regards
Alan
--
Alan Fitch
HDL Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification *
Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood,
Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:
alan....@doulos.com
Fax: +44 (0)1425 471573 Web:
http://www.doulos.com
The contents of this message may contain personal views
which are not the
views of Doulos Ltd., unless specifically stated.