I am getting above error while running modelsim on a VHDL Testcase and I am unable to understand why is it an error.
The Testcase:
LIBRARY IEEE;
Use ieee.std_logic_1164.all;
entity a is
port (in11 : in std_logic
);
end a;
Architecture a of a is:
component b_1
port ( in1 : in bit);
end component;
begin
inst : b_1 port map ( in1=> **to_Bit**(in11));
end a;
That's a modelsim error, actually it should report that you are not allowed to use this function as actual in a port map, this works:
LIBRARY IEEE; Use ieee.std_logic_1164.all;
entity a is port (in11 : in std_logic ); end a;
architecture a of a is
signal inBit : Bit;
component b_1 port ( in1 : in bit); end component;
begin
inBit <= to_bit(in11);
inst : b_1 port map ( in1=> inBit); end a;
There are restrictions that apply to actuals in port maps, c.f. vhdlref:
The actual, if a port or signal, must be denoted by a static name
(see 6.1). The actual, if an expression, must be a globally static
expression (see 7.4).
The thing is, both cases should be globally static...
VHDL-93 allows type conversions and conversion functions in association lists.
A conversion function is a special case of a function with only one argument.
Let's look at the declaration of to_bit:
function to_bit(s : std_ulogic; xmap : bit := '0') return bit;
Although to_bit(s) looks like a valid conversion function, it's not, because the declaration contains two arguments.
The second argument xmap is used as the result when is_x(s) is true.
This is not a ModelSim bug, but maybe the error message is a bit cryptic. ModelSim figures that to_bit is meant to be a conversion function, but refuses to use it, because it has a second argument, and is thus not a valid conversion function.
A simple wrapper function can solve the problem:
function to_bit(s : std_ulogic) return bit is
begin
return to_bit(s, '0');
end;
Note that the function can also have the name to_bit, because VHDL supports function overloading. It would be nice to have this in the package std_logic_1164.
Related
While trying to figure out the specifics of the shift_right function from the numeric_std package I noticed that the count argument is of the subtype NATURAL:
function shift_right(ARG: UNSIGNED; COUNT: NATURAL) return UNSIGNED is
begin
if (ARG'length<1) then return NAU; end if;
return UNSIGNED(XSRL(STD_LOGIC_VECTOR(ARG),COUNT));
end;
However when calling the function I can also provide an INTEGER which in contrast to NATURAL can hold a negative number.
Example of calling code that succesfully compiles:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity ExampleCode is
port
(
clk : in std_logic;
input : in signed(15 downto 0);
shift : in signed(3 downto 0);
output : out signed(15 downto 0)
);
end entity;
architecture rtl of ExampleCode is
begin
ProcessExample : process(clk)
begin
if (rising_edge(clk)) then
output <= shift_right(input, to_integer(shift));
end if;
end process;
end rtl;
The numeric_std package shows that if you use to_integer with a signed argument that it returns an integer:
function TO_INTEGER ( ARG: SIGNED) return INTEGER;
My questions are;
Does VHDL always allow parents of subtypes to be provided as arguments to functions?
When it does allow a parent type, how does it resolve the imposed constraints of the subtype?
The other answer is very detailed, but I think goes down a bit of a rabbit hole, when your specific questions can be answered more succinctly. I have answered from a perspecitve of what will practically happen in a real tool that you might use, as opposed to trying to re-interpret the language standard.
An important feature of a subtype is that there is automatic 'conversion'+ to and from the parent type. The example below clearly shows this with an enumerated type. The same automatic conversion would be invoked when passing a parent-type parameter to a function that expects the sub-type.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity e is
end;
architecture a of e is
type r is (A, B, C, D);
subtype rs is r range A to C;
signal x1 : r := B;
signal x2 : r := D;
signal xs : rs;
begin
process
begin
xs <= x1; -- Fine.
wait for 1 ns;
xs <= x2; -- Run-time error, "Value 3 is out of range 0 to 2".
wait;
end process;
end;
Does VHDL always allow parents of subtypes to be provided as arguments to functions?
From the above, yes, it does, but in many tools, you will get an error if the automatic type conversion cannot succeed, as it obviously cannot in the second assignment in the example. Note that if x2 was a constant, a tool could work out that the conversion is not going to be possible, and thrown up a compile-time error then instead.
The same applies with natural and integer; since natural is defined as subtype natural is integer range 0 to integer'high, natural in a sense is an integer, so automatic 'conversion' is simple and reasonable as long as the integer is not outside the natural's range.
When it does allow a parent type, how does it resolve the imposed constraints of the subtype?
Whether standardised or not, a particular tool might implement this in a variety of ways, so you might see different behavior for out-of-range parent-typed values with different tools.
For example, when I tried with ModelSim, it appears that its conversion from integer to natural simply copies the value, meaning that shift_right will surprisingly work with a negative value in that tool, if the shift amount integer is not a constant (at least for version 10.7e).
Obviously it is not sensible to rely on a particular behavior, but regardless of behavior, using a sub type can offer you more protection than just using base types throughout a design.
+ It's not really conversion in VHDL, but if you've used pretty much any other language, this is how you will tend to refer to it.
I have the following code:
library IEEE;
use IEEE.std_logic_1164.all;
entity static_test is
end entity;
architecture sim of static_test is
type rec_t is record
sl : std_logic;
slv : std_logic_vector(6 downto 0);
end record;
type rec_ptr_t is access rec_t;
begin
process
variable ptr : rec_ptr_t;
begin
ptr := new rec_t;
(ptr.sl, ptr.slv) := std_logic_vector'(x"00");
wait;
end process;
end architecture sim;
And I get the following errors from ActiveHDL:
Error: COMP96_0309: static_test.vhd : (28, 6): Expression in element association of the aggregate must be a locally static name that denotes a variable.
Error: COMP96_0309: static_test.vhd : (28, 14): Expression in element association of the aggregate must be a locally static name that denotes a variable.
I cannot find the LRM section that specifies an aggregate assignment needs to be locally static, and I also dont understand why ptr.sl or ptr.slv is not considered locally static. The lengths are known in the type. Is it just that an access type cannot ever be considered locally static (it kind of makes sense to me).
Vivado Simulation cannot support unconstrained types which have a signed component to them.
i.e.
type A is array (natural range <>) of signed;
I have been using this in a design where type A is used in port declarations as I wish to have a parallel design which I control through a generic as well as the current stage word length e.g.
port (
inputdata : A(0 to number_of_parallel_generic-1)(stage_wordlength_generic-1 downto 0)
);
As I use the type A with many variations of the generics controling them e.g. 4 wide arrays with 16 wordlengths and other variations (often controled by a for generate loop)
for i in 0 to length_of_generate_statement-1 generate
signal example_signal : A(0 to 3)(stage_wordlength_generic + i - 1 downto 0);
begin
<functional code>
end generate;
This sort of code would allow me to gain bit growth from sequential sections of my archetecture - e.g. from an addition.
Now... getting to the question at hand.
One way I could get round this rather than initiating a signal with a forever changing generate statement could actually be in the creation of an "array of types".
Lend me your eyes this is written in a not quite vhdl way but hopefully you can see what Im trying to do.
type my_arr_of_types is array(0 to length_of_array-1) of type;
for i in 0 to length_of_array-1 generate
my_arr_of_types(i) <= <type declaration with some dependance on i>;
end generate;
Hopefully you can see what I am trying to do.
This would allow you to then call an element of the my_arr_of_types which itself is a type to then assign to a signal/variable.
i.e.
signal my_sig : my_arr_of_types(n);
*Where n is any valid index of the array.
Obviously this is not allowed in VHDL or any simulation tool. But can anyone see a potential solution to my problem?
Remember I use most of these types on port statements so any solution has to fit within the limitations of the port declarations.
Using two dimensional arrays as a solution:
Package
library ieee;
use ieee.numeric_std.all;
package utilities is
type T_SLM is array(natural range <>, natural range <>) of std_logic;
end package;
Entity
Now you can use this type in a port declaration together with two generic parameters. As sizes are now known in the architecture, you can create your used defined type of signed values and you can use either generate statements or a function to convert from the T_SLM to myArray type.
library ieee;
use ieee.numeric_std.all;
library myLib;
use myLib.utilities.all;
entity foo is
generic (
number_of_parallel : natural;
stage_wordlength : natural
);
port (
Input : T_SLM(0 to number_of_parallel - 1, stage_wordlength - 1 downto 0)
);
end entity;
architecture a of foo is
type myArray is array (natural range <>) of signed(Input'range(2));
function convert(matrix : T_SLM) return myArray is
variable result : myArray(matrix'range(1));
begin
for i in matrix'range(1) loop
for k in matrix'range(2) loop
result(i)(j) := matrix(i, j);
end loop;
end loop;
return result;
end function;
signal InputData1 : myArray(Input'range(1));
signal InputData2 : myArray(Input'range(1));
begin
genInput: for i in Input'range(1) generate
genInput: for j in Input'range(2) generate
InputData1(i)(j) <= Input(i, j);
end generate;
end generate;
InputData2 <= convert(Input);
end architecture;
Many helper functions like this have been implemented in the PoC Library in package PoC.vectors.
I want to create a custom type in my generic section of my entity using VHDL-2008. However I get an error immediately in Modelsim with this code. The error is:
** Error: C:/Projects/source/My_Mux.vhd(35): near "is": expecting ';' or ')'
Note that Line 35 is the type t_Array below:
entity My_Mux is
generic (
g_MUX_INPUTS : integer := 2;
type t_Array is array (0 to g_MUX_INPUTS-1) of std_logic_vector(7 downto 0)
);
port (
i_Select : in std_logic_vector(1 downto 0);
i_Mux_Data : in t_Array;
o_Data : out std_logic_vector(7 downto 0)
);
end entity My_Mux;
architecture RTL of My_Mux is
begin
o_Data <= i_Mux_Data(0) when i_Select = "00" else i_Mux_Data(1);
end architecture RTL;
I looked into creating a special function that I define in my generic portion of my code. But that requires that I overload the function in the instantiating module, which I really did not want to have to do, it seems needlessly complicated. If I could create a custom type in the generic it would solve my problem. Possible using VHDL-2008?
How would you expect to have type compatibility between the formal and actual if they declaration of a type were actually made in a generic declaration?
Each declaration in VHDL is unique, not by name but by declaration occurrence. What declaration the name references depends on scope and visibility. Both (all) places a name is used have to be able to reach the same declaration.
How a generic type is declared is found in IEEE Std 1076-2008 6.5.3 Interface type declarations:
An interface type declaration declares an interface type that appears as a generic of a design entity, a component, a block, a package, or a subprogram.
interface_type_declaration ::=
interface_incomplete_type_declaration
interface_incomplete_type_declaration ::= type identifier
An interface type provides a means for the environment to determine a type to be used for objects in a particular portion of a description. The set of values and applicable operations for an interface type may be determined by an associated subtype in the environment. The manner in which such associations are made is described in 6.5.7.
And the important thing to note is that is an incomplete type declaration, where the actual specifies a preexisting type with a subtype constraint (6.5.6.2):
The subtype denoted by a generic type is specified by the corresponding actual in a generic association list. It is an error if no such actual is specified for a given formal generic type (either because the formal generic is unassociated or because the actual is open).
Because that association is with a previously declared type there is little difference with doing the same thing the -1993 way:
library ieee;
use ieee.std_logic_1164.all;
package my_package is
type my_array is array (natural range <>) of std_logic_vector(7 downto 0);
end package;
library ieee;
use ieee.std_logic_1164.all;
use work.my_package.all;
entity My_Mux is
generic (
g_MUX_INPUTS: integer := 2
--type t_Array is array (0 to g_MUX_INPUTS-1) of
-- std_logic_vector(7 downto 0)
);
port (
i_Select: in std_logic_vector(1 downto 0);
-- i_Mux_Data: in t_Array;
i_Mux_Data: in my_array (0 to g_MUX_INPUTS - 1);
o_Data : out std_logic_vector(7 downto 0)
);
end entity My_Mux;
architecture RTL of My_Mux is
begin
o_Data <= i_Mux_Data(0) when i_Select = "00" else i_Mux_Data(1);
end architecture RTL;
There's an added package that has a type declaration my_array which is an unbound (partially constrained) multidimensional array type.
This allows the use of the package my_package to specify the type of the actual:
library ieee;
use ieee.std_logic_1164.all;
use work.my_package.all;
entity my_mux_tb is
end entity;
architecture foo of my_mux_tb is
constant MUX_INPUTS: natural := 2;
signal i_Select: std_logic_vector (1 downto 0);
signal i_Mux_Data: my_array (0 to MUX_INPUTS -1);
signal o_Data: std_logic_vector(7 downto 0);
begin
DUT:
entity work.My_mux
generic map (
g_MUX_INPUTS => MUX_INPUTS
)
port map (
i_Select => i_Select,
i_Mux_Data => i_Mux_Data,
o_Data => o_Data
);
end architecture;
The two examples above analyzed in order, elaborate and the testbench simulates (while doing nothing particular interesting besides telling us the subtype constraint is passed on the port actual).
The custom type would be required to be accessible to both the component or entity instantiation and the place the port actual is declared.
Using a generic type would allow you to remove the my_package use clause from the my_mux context clause, relying on the actual association instead.
You can also bind the type at elaboration time without switching the package (or relying on package instantiation in -2008 with it's own generics).
I have following simple testcase :
library ieee;
use ieee.std_logic_1164.all;
entity top is
end top;
architecture top of top is
component foo
port (A : std_logic_vector(1 downto 0));
end component;
begin
inst : foo port map (A(1) => '0', A(0) => '0');
end top;
------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
entity foo is
port (A : std_logic_vector(1 downto 0));
end foo;
architecture foo of foo is
begin
end foo;
When running modelsim on this, it runs fine. But, when I run modelsim with option '-87', it gives me error that Error: top.vhd(13): (vcom-1451) Actual (enumeration literal '0') for formal "A" is not signal name. I am not getting this. Is this some illegal RTL in VHDL'87?
If this is not supported in VHDL'87, then what would be right way to connect a constant to instance pin.
Looking in Modelsim's Verror messages:
vcom Message # 1451: The actual designator is not a static signal
name, it is an expression. In a VHDL 1987 port map, the actual
designator in an association element must be either a static signal
name or a conversion function call whose only argument is a static
signal name. In a subprogram association list in any VHDL language
version, the actual associated with a class SIGNAL subprogram
parameter must be a static signal name.
Later versions of VHDL allow
flexibility in the actual in a port map.
Try using the -93, -2002, or -2008 switch to vcom.
[DOC: IEEE Std 1076-1987 VHDL LRM - 2.1.1.2 Signal parameters,
4.3.3.2 Association Lists]
[DOC: IEEE Std 1076-1993 VHDL LRM - 2.1.1.2 Signal parameters]
So, yes there's a difference in what is valid for an an actual in a port association. The -1993 'liberalization' would also be applicable on later versions (-2002, -2008).
The actual needs to be named and not simply an expression. Inputs with default values can be left open.