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.
Related
Is there some way to define an alias, function or subtype in a package to define syntactic sugar around constrained vector declaration?
I often declare port and signals in VHDL as std_logic_vector(N - 1 downto 0). I would like some syntactic sugar around this. something similar to this:
context work.common;
entity X is
generic(
byteSize : integer := 8
);
port(
DataIn : in logic_bus(byteSize);
DataOut : out logic_bus(byteSize)
);
end entity;
architecture X_arch of X is
signal DataSignal : logic_bus(byteSize);
begin
DataOut <= DataSignal;
DataSignal <= DataIn;
end architecture;
I would like to have this syntactic sugar defined all over my project, i.e., avoid defining a subtype in the architecture if possible. I'm very confused with the usage of open, natural range <>, the difference between type and subtype, and what kind of things functions can return.
regarding constraints inference
I would like to stress that I'm looking for a way to abstract away the definition of similar vector constraints.
The proposal to leave my vector completely unconstrained, while a clever workaround, has strings attached to it that I would like to avoid :
It is not compatible with type casting see here.
It doesn't communicate the relationship between ports (for instance it doesn't communicate that DataIn and DataOut are supposed to be the same size)
It risks to allow badly sized bus designs to pass synthesis by mistake (accidental meaning)
For this reasons, my workplace coding style has banned unconstrained types in ports in favor of generics. Thank you for your understanding.
I assume that you want logic_bus(x) to be some kind function/alias/subtype to abstract away std_logic_vector(N-1 downto 0), working around constrained vector declaration.
VHDL have a quite small user base in terms of numbers. So much of what of the language you can use is highly tool dependent. Make sure you have read up on the supported features of vhdl-2008 for your development environment. As a main user of Xilinx UG901 is my go to for Vivado. Even though a feature is supported you might sometime be required to add an keep attribute to make it not be optimized away in synthesis.
Since a few years back Vivado have a quite full support for vhdl-2008
Unbounded arrays have been supported for even longer.
Generic package have just seen the light of day and seems to be a bit different in Mentor and Xilinx interpretation, but you can make it implement.
Generic types is a part of the language, but I have never got it to work the way I needed it to. (I always try to keep to sl and slv in entity)
As I'm not sure about your environment I can only answer for mine.
Full VHDL-2008 support is assumed
Unconstrained slv
Working around constrained vector definition by avoiding it.
entity X is
port(
DataIn : in std_logic_vector;
DataOut : out std_logic_vector
);
end entity;
architecture X_arch of X is
-- guiding DataSignal with to have a relationship with some signal is usally needed
signal DataSignal : std_logic_vector(DataIn'range);
begin
assert DataIn'length = DataOut'length
report "length missmatch of input and output data"
severity ERROR;
DataOut <= DataSignal;
DataSignal <= DataIn;
end architecture;
Asserts will need to be enabled for synthesis, ether for the run or appended to the synthesis strategy. (see ug901, for Xilinx or check vendor docs)
Unconstrained vectors need to be constrained at the top level. Some times a bit flakey in multi layered component designs. Signals are usually a bit iffy about how they get inferred.
Higher dimensional data can also be unconstrained
type slv_2d is array(natural range <>) of std_logic_vector;
-- Constrain multiple dimensions at once
-- (this might still be broken in GHDL, open issue last time i checked)
-- synthesis/implementation in Vivado works
-- simulates in Modelsim/Questa works
signal test_signal : slv_2d(0 to 5)(7 downto 0);
-- constants can de inferred from assignment
constant test_signal : slv_2d := ("001", "010", "011", "100" );
subtype I usually think about as limiting a type further.
-- integer may be any value within -2147483648 to +2147483647.
-- I might have an issue or a design restriction to highlight
-- I usually don't use subtypes
subtype my_range is integer range 0 to 255;
-- Will throw error if outside of range 0 to 255.
variable cnt : my_range := 0;
I really recommend reading ug901 "Supported VHDL-2008 Features" section of the latest release, even if you don't work with Xilinx. Dolus have a few really good writeups on vhdl-2008 that might strike your fancy and will talk about related features to what you are looking for.
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.
I would like to know if there is a way to access an entities default generic values or an entities architectures constants during synthesis.
This is out of curiosity (and I want to implement something like that).
Possible Usecases
1) generating Testbench for the default entity:
entity testme is
generic(outputs:integer:=4);
ports(output:out bit_vector(0 to outputs);
end entity;
in the testbench i need to generate a signal whcih can be connected to output, without knowing the generics value there is no way of doing so.
2) I would like to know the actual size I use when instantiating Blockram. On FPGAs there is Blockram, fixed chunks of ram one can use, if one needs more ram than is available in one block multiple blocks are combined. Varying with the technology the size of the available blockrams can change. Thus I write an entity with two generic parameters memory and technology that implements my memory with the least Blockrams possible. This might lead to the Memory being larger than requested. If I now have another entity that needs the size of the memory to fully utilitize it (i.e. circular buffer controller), I have to supply it the actual size of the memory allocated.
You have to push these things downwards from the top (ie from the testbench). It is not possible to inspect a lower-level block (although I guess you could bring a signal out and back up to the top!)
you can use unconstraint types, e.g.:
entity example
port(
i: std_logic_vector;
o: std_logic_vector
);
in the testbench you add defined vectors e.g.:
....
signal i,o: std_logic_vector(10 downto 0);
begin
uut: example
port map(
i => i,
o => o
);
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)