Is there any way to use pre-defined types from STD_LOGIC_1164 or STD_NUMERIC to represent an integer ranging from 0 to 2^32-1 ? (considering the default integer type ranges from -2^31-1 to 2^31-1)
I need to implement 32-bit counter and was looking for some way to save code using integer type instead of std_logic_vector.. Any design pattern for this ?
Or, better asked: Whats the best way to declare a 32-bit (unsigned) integer supporting the operations >/<, =, +-/ ?
Tahnks in advance
Edit1: One option I found was to declare a signal as std_logic_vector(31 downto 0), and to perform conversions when doing comparisons or +- operations.. ex: counter <= counter + std_logic_vector(unsigned(value) + 1).. Still haven't found a way to do division though (in case,for example, 1/4 of the value of counter is needed)
Using the Integer types, you cannot (at least, not portably; there may be some VHDL tools that go beyond the minimum and offer a 64-bit integer)
Using IEEE.numeric_std, you can declare an Unsigned with a full 32-bit range (or 53-bit if you wish) and it should do everything you want.need, unless I misunderstand what you are asking.
use ieee.numeric_std.all;
and then use the unsigned data type - this operates as a bit vector with mathematical operations defined for it. You can choose how many bits you'd like. For example:
signal mynum : unsigned(234 downto 0)
Related
I am trying to write a systemVerilog testbench for my VHDL designs. The problem is the data types. For instance, in VHDL I have:
punti_retta : out integer range 255 downto 0;
fdata_in : in integer range 127 downto -128;
For the first one, I tried "integer [7:0] punti_retta" in the systemVerilog testbench; however, the tool ignored the range definition and according to the waveform it is wrong.
What and how should I define for these signals in my systemVerilog testbench? Is there any suggestion?
Verilog does not have an integer range in the same way as VHDL.
You can make an equivalent type if your integer range is a power of two like in your example:
punti_retta : out integer range 255 downto 0;
fdata_in : in integer range 127 downto -128;
The first one is an unsigned integer of 8 bits so you can use logic [7:0] punti_regga;.
Instead of logic you can also use wire or reg
The second one is signed integer of 8 bits so you can use logic signed [7:0] fdata_in;.
But VHDL also allows you to use:
my_counter : integer range 0 to 395;
There is no exact equivalent in Verilog. However when that variable is going to be synthesized, the tool must have enough bits so in hardware you get a 9 bit unsigned type. Thus the real hardware can count beyond 395!
The Verilog equivalent is logic [8:0] my_counter ;
SystemVerilog does not have the concept of integer ranges, only bit-widths. You can approximate ranges using $clog2().
bit [$clog2(255)-1:0] punti_retta;
bit signed [7:0] fdata_in;
Since there is no standard for crossing standard boundaries, you're going to have to look at the restrictions your tool puts on mapping port types. You might have to put the types in a common package.
BTW, the bit range in integer [7:0] is ignored or made an error because of a quirk in the first Verilog-XL simulator. Originally, the integer type was unsized and determined by the OS your simulation was executing on. They had planned to use that syntax to specify the integer size, but never got around to implementing it.
In VHDL what is means of "if (('0' & next_a)=15) then"
next_a is vecotr length 4 (next_a : std_logic_vector(3 downto 0))
Thanks you!
It means the author didn't understand what he was doing.
The author apparently realises (or found out in a debugging session) that 15 cannot be represented as a signed 4-bit value, though he is perhaps unaware that it can be represented as an unsigned 4-bit value.
And he is probably using one of those non-standard Synopsys libraries that defaults to a signed interpretation on non-numeric data like std_logic_vector.
So instead of making it clear to the compiler that he wants an unsigned comparison, he sign-extends next_a by prepending '0'to generate a 5-bit signed representation.
If he had taken a clearer view of the design in the first place, he would have used the numeric_std libraries and declared next_a as unsigned(3 downto 0) or even natural range 0 to 15. And written
if next_a = 15 then
If he was forced to use std_logic_vector for some reason, then
if unsigned(next_a) = 15 then
would make the operation equally clear.
If you read this in a book, burn the book (responsibly : avoid forest fires!). And banish constructs like this, and where you reasonably can, those non-standard libraries, from your own code.
I use the following package only in my VHDL file:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
In the code, I compare a std_logic_vector signal : A with a constant value, e.g
...if A<="00001011" then
yet the code was checked correctly by Xilinx ISE. My understanding is that STD_LOGIC_1164 package does not include an implementation of inequalities having as an operand std_logic_vector so why the above code statement was accepted and will the above comparison treat A as signed or unsigned number?
-- Copying my comp.lang.vhdl reply to this post. Sorry some duplicates, but some does not.
All enumerated types and arrays of enumerated types implicitly define the regular ordering relational operators (>, >=, <, <=). Unfortunately it is not numerically ordered, so the results may not be as expected. Instead it is dictionary ordered.
First you have to look at the element type, which is std_logic whose base type is std_ulogic. For an enumerated type, such as std_ulogic, left values are less than right values, hence, for std_ulogic (and std_logic):
'U' < 'X' < '0' < '1' < 'Z' < 'W' < 'L' < 'H' < '-'
For equal length arrays whose element base type is std_ulogic (such as std_logic_vector or std_ulogic_vector) whose values are only 0 or 1, things work out fine:
"1010" > "0101"
Note that dictionary comparisons always compare the left element first. Hence, for string, something that starts with 'S' is always less than something that starts with 'T' independent of length. This is great for sorting strings into a dictionary and is the only practical default - if we are going to provide such as thing.
OTOH, this is not so great if you are thinking things are numeric. For example, if the arrays are not equal length, then the following is true because the leading '1'on the left parameter is > the leading '0' of the right parameter.
"100" > "0111"
Hence, with only "use ieee.std_logic_1164.all", you have potential exposure to bad coding practices that mistakenly think of std_logic_vector as numeric (such as unsigned).
Many will argue, never use std_logic_vector for math and ">" is math. I generally agree.
So what do I do? How do I protect my design and design team from this. First you have to decide a policy and how to implement it.
1) Forbid use of regular ordering relational operators (>, >=, <, <=) with std_logic_vector and enforce it with a lint tool. However this means you have to buy and require the use of a lint tool.
2) Forbid use of regular ordering relational operators (>, >=, <, <=) with std_logic_vector and enforce it by using the both of the following package references. Note that this generates errors by referencing two definitions for each of the operators, and hence, when used the expression becomes ambiguous. Note this may be problematic since numeric_std_unsigned was introduced in 1076-2008 and it may not yet be supported by your synthesis tools.
library ieee ;
use ieee.numeric_std_unsigned.all ;
use ieee.std_logic_unsigned.all ;
3) Relax the rules some. Our biggest concern is design correctness. Allow std_logic_vector to be interpreted as an unsigned value and either reference numeric_std_unsigned (preferred, but it is VHDL-2008 and may not be implemented by your synthesis tool yet - but if it is not be sure to submit a bug report) or std_logic_unsigned (not preferred - this is an old shareware package that is not an IEEE standard and perhaps does not belong in the IEEE library - OTOH, it is well supported and it plays nice with other packages - such as numeric_std).
The nice result of this is that it also allows comparisons that include integers:
if A <= 11 then
Note, some suggest that the overloading of ">" and friends in numeric_std_unsigned/std_logic_unsigned is illegal. This was a very conservative interpretation of 1076 prior to VHDL-2008. It was fixed for all revisions of VHDL with an ISAC resolution prior to VHDL-2008 that determined that explicitly defined operators always overload implicitly defined operators without creating any ambiguity. I note that even the VHDL FAQ is out of date on this issue.
4) Be formal, but practical. Never use std_logic_vector. Only use numeric types, such as unsigned and signed from package ieee.numeric_std. Types signed and unsigned also support comparisons with integers.
There are probably a few strategies I left out.
Note that VHDL-2008 introduces matching operators which also address this issue by not defining them for types that do not have a numeric interpretation. These operators are: ?=, ?/=, ?>, ?>=, ?<, ?<=
"<=" is called a relational operator in VHDL.
It's predefined. See IEEE Std 1076-2008, 9.2.3 Relational operators the table. It's a predefined operator for any scalar or single dimensional discrete array type.
std_logic_vector qualifies as a single dimensional discrete array type, it's element types discrete, in this case being enumerated types (std_logic/std_ulogic). See 5.2 Scalar types, 5.2.1 General, wherein the first paragraph demonstrates an enumerated type is discrete.
And for a simpler answer it's part of the language.
Short answer: you need to use an extra package: ieee.numeric_std
I must assume that you have defined A as a std_logic_vector(7 downto 0).
This data type represents an array of bits. There is no numeric value associated with it. Hence, the comparison between A and your bit string literal does not make sense.
If you want to compare the numeric values represented by A, you need to use unsigned(7 downto 0) or signed(7 downto 0), preferably from the package ieee.numeric_std. This is the accepted good practice to attribute numeric values to arrays of bits.
Technically, you could work around this and define your own "<=" function, but you would just be duplicating code from the VHDL standard IEEE library.
To expand on David's answer slightly: it's predefined for discrete arrays such that, basically, array elements are compared left to right (according to IEEE 1076-2008, 9.2.3), and each scalar array element is compared using its inherent order which, in the case of an enumeration like std_logic, is defined by its position (according to 5.2.2.1). '1' is "greater than" '0' only because its position in the std_ulogic declaration is higher (and 'Z' is "greater than" '1' for the same reason).
It should be clear from this that it's not treating the vectors as signed or unsigned. It happens to look like it's treating the vectors as unsigned if they're equal length and only contain '0' and '1', but you still shouldn't do it.
Questions:
Is there a more appropiate "supertype" to signed and unsigned than std_logic_vector (regarding my case)?
Is it ok to define an Input as (subtype of) Integer or is it better to define it as bitvector? (Are there any Issues with the Integer approach)
When should I use resolved or unresolved logic for the Inputs/Outputs off an Entity?
Resolved for Bus drivers (because of the "high Z drivers") otherwise unresolved?
Always resolved so a bus can be driven/used as input (this seems wrong, because when would I use unresolved then?)
Actual Case:
I am declaring an entity and am wondering for the right types for the inputs and outputs.
Lets assume I am constructing a dynamic width equal. It compares the first n Bits of two Inputs for equality.
The entity definition would be:
entity comparisonDynWidth is
generic(
width : positive;
min_width : positive;
-- when the tools suport vhdl2008 enough
-- reason for both signed/unsigned => std_logic inputs
--function compareFunc (x: in std_logic_vector; y: in std_logic_vector) return std_logic
);
port (
left, right : in std_logic_vector(width-1 downto 0);
widthControl: in natural range 0 to width-min_width;
result : out std_logic / std_ulogic ??
);
I chose std_logic_vector as Input since I want it to look the ports like a generic less than comparator as well, for which signedness matters and which can have signed and unsigned inputs.
since it is easier for me to define the width as an integer I did so.
Is there a more appropiate "supertype" to signed and unsigned than
std_logic_vector (regarding my case)?
Not sure what you mean, but you have no choice - signed and unsigned are defined in the standard.
Is it ok to define an Input as (subtype of) Integer or is it better to
define it as bitvector? (Are there any Issues with the Integer
approach)
Integers will flag errors if you go outside their range. vectors (signed and unsigned) will wrap around. Which is "correct" depends on what you want and how you feel about coding explicit wrap-around if you want it with integers.
When should I use resolved or unresolved logic for the Inputs/Outputs
off an Entity?
If you stick to:
only using resolved types for the top level IO ports (i.e. the actual pins of the device)
using unresolved types internally
you will be able catch errors involving multiple drivers on a signal with a detailed error-message at elaboration-time. This can be preferable to chasing down Xs in your waveforms at simulation-time.
There are no internal tri-state buses internally to most technologies these days, so you can't have multiple drivers, so there's no need for resolved signals inside the device. IO pins (almost?) always have tri-stateble drivers, so the use of a resolved type is appropriate, and the driving of a 'Z' can be used to infer that behaviour.
std_logic_vector is a good choice in your case (and in most cases in an entity, as it represents hardware situation best... e.g. with use of 'U' and 'Z' and so on)
the use of integer in an entity is ok as long as it is not the top-level entity. in top level entities, the exclusive use of std_logic(_vector) is recommended.
most tools report multi-driver situations anyway... the use of resolved types is therefore ok.
I am working in 8 bit pixel values..for ease of coding i want to use conv_integer to convert this 8 bit std_logic_vector.is it cause any synthesise problem?is it reduce the speed of hardware...
No, integers synthesise just fine. Don't use conv_integer though - that's from an old non-standard library.
You want to use ieee.numeric_std; and then to_integer(unsigned(some_vector));
If you still want to access the bits, and treat the vector as a number, then use the signed or unsigned type - they define vectors of bits (which can still have -, Z etc.) which behave as numbers, so you can write unsigned_vector <= unsigned_vector + 1.
You will lose a lot of the functionality that comes with the standard logic vector such as having the value 'Z' or 'X'. If you need access to the bits leave it as std_logic_vector, or cast it to numeric_std. If you don't and you need to do some fancy arithmetic maybe it's better to have as an int. At the end of the day its all bits. Its normally best to keep to a vector type (std_logic_vector, unsigned, signed etc) at the top level so you can map each bit to a specific pin, but otherwise, you can use whatever types you want. Don't forget you are designing hardware now, not software, and there is a difference.