I am having this issues in the Cadence tool chain simulation when I try to connect the multidimensional user defined type in VHDL to SystemVerilog in a UVM environment. This is the VHDL output type definition:
TYPE loop_reg_ty IS RECORD
loop_index_value : std_logic_vector(REG_BITWIDTH-1 DOWNTO 0);
loop_counter : std_logic_vector(REG_BITWIDTH-1 DOWNTO 0);
loop_end_flag : std_logic;
END RECORD;
TYPE loop_array_ty is array (MAX_NO_OF_LOOPS-1 downto 0) of loop_reg_ty;
One of the VHDL output ports in my DUT is of type loop_array_ty;
I am trying to define the SystemVerilog equivalent as:
typedef struct packed {
bit [REG_BITWIDTH-1:0] loop_index_value;
bit [REG_BITWIDTH-1:0] loop_counter;
bit loop_end_flag;
} raccu_loop_reg_ty;
typedef raccu_loop_reg_ty [MAX_NO_OF_RACCU_LOOPS-1:0] loop_array_ty;
When I use irun, I get the error:
VHDL port type is not compatible with Verilog.
Please suggest the possible work around solution.
First, your problem is that you're not defining the loop_array_ty correctly. It should be typedef raccu_loop_reg_ty loop_array_ty[MAX_NO_OF_RACCU_LOOPS-1:0].
I would suggest 2 things here:
First, try removing the packed qualifier from the struct definition. Connecting SV structs to VHDL records is something that is only available in newer Incisive versions. Make sure that the version you're using supports this.
If you're using an older version of Incisive (like I was a year back), your only choice is to map the individual record members using $nc_mirror (not tested code, but enough to get you started):
// struct definition...
// ...
module top;
// intermediate signal we'll mirror onto
loop_array_ty loop_s;
// no output connected
my_dut dut_inst();
// make the connection between SV and VHDL using nc_mirror
initial begin
for (int i = 0; i < MAX_NO_OF_RACCU_LOOPS; i++) begin
$nc_mirror($sformatf("loop_s[%0d].loop_index_value", i),
$sformatf("dut_inst.loop_o[%0d].loop_index_value", i);
// $nc_mirror for loop_counter
// $nc_mirror for loop_end_flag
end
end
endmodule
Also make sure that you're setting the REG_BITWIDTH constant appropriately in both languages, otherwise you'll also get a type mismatch.
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.
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.
In this piece of code I get this error for the line with +
function func (bv1 : in bit_vector; bv2 : in integer) return bit_vector is
variable temp : natural := 2**bv2;
variable result : bit_vector(1 to 32);
begin
report "asd" & natural'image(temp);
result <= bv1 + temp; // this line causes the error
return result;
end func;
The error is :
No function declarations for operator +
How can I solve this? I also get a similar error for "=" as well.
Don't use bit_vectors (or std_logic_vectors, really) for anything you want to do arithmetic on.
Use the ieee.numeric_std library and then declare your signals (or whatever) to be of type signed ot unsigned depending on what type of vector you want. (Or of course, you can just use integers and the subtypes of that)
It's because you try to add a natural to a bit_vector which does not work because they are of different types. So you'll have to use a converter, e.g. as shown here within one of the functions. The other method is to stick to all the same types, but that isn't always possible.
Some initial problems with the code are that VHDL comments markup is --, not
//, and assign to result variable must use :=, since <= is for assign
to signal.
Then, the reason for the error:
No function declarations for operator +
is that VHDL is a strong typed language, so it is not possible just to add a
natural type and a bit_vector type, as attempted in result <= bv1 + temp.
Instead you need to use the package numeric_bit_unsigned, and for example
convert temp to bit_vector using function to_bitvector before adding.
Resulting code can then be:
library ieee;
use ieee.numeric_bit_unsigned.all;
...
function func (bv1 : in bit_vector; bv2 : in integer) return bit_vector is
variable temp : natural := 2**bv2;
variable result : bit_vector(1 to 32);
begin
report "asd" & natural'image(temp);
result := bv1 + to_bitvector(temp, result'length); -- this line causes the error
return result;
end func;
You should check that the length is enough to handle the required values.
However, instead of using bit_vector type, you may consider the
std_logic_vector (depending on the design), since the std_logic_vector has
additional values that may reveal design problem in simulation.
I have not been able to understand how to dereference a pointer in VHDL.
What I have in mind is a C code like :
int a;
int* ptr_a;
a = 42;
ptr_a=&a;
*ptr_a=451;// how can I do this ?
I tried to mimick this code in VHDL :
ptr_test : process
type ptr_integer is access integer;
variable a : integer;
variable ptr_a : ptr_integer;
begin
a := 42;
ptr_a := new integer'(a);
report "ptr now points to a : ptr=" & str(ptr_a.all);
ptr_a.all := 451;
report "ptr modified : ptr=" & str(ptr_a.all);
report "a is NOT modified : a =" & str(a);
wait;
end process;
So how can I correctly modify a value through a pointer ?
You can't directly. Access types are not "just like pointers" - they are to at least some extent distinct types of data storage.
This line does not create a pointer to a:
ptr_a := new integer'(a);
It creates a data object with the same value as a and sets up ptr_a to reference it.
If you were to create another access type variable :
variable ptr_b : ptr_integer;
and set it to to point to ptr_a:
ptr_b := ptr_a;
then changes to ptr_b.all will reflect in ptr_a.all.
"new" is the equivalent of the (C++ rather than C) "new" operation; invoking a constructor allocating an integer on the heap and initialising it to "a". (Naturally, you can "deallocate" it when done)
What you are looking for is ptr_a := a'access; which is the Ada way of accessing a global or local (stack) variable via a pointer : this is only legal if said variable has been declared "aliased" alerting the compiler to the fact there may be more than one view of it (and thus, preventing some nice optimisations). In C, everything is "aliased" whether you want it or not.
This is one of the aspects of Ada that didn't make it through the simplification process into VHDL : and it's difficult to see a good use for it. So there isn't an exact equivalent in VHDL.
Martin's answer just popped up : as he says, you CAN have 2 or more pointers to the same heap object.
Alternatively, explain what you are trying to achieve this way; there may be a VHDL alternative way of doing it.
I am trying to convert some Verilog code that produces a slower clock from a faster clock for a UART module. The original verilog code is based on the module over at fpga4fun.com, and this is my attempt to translate it for my VHDL-based design.
entity baud_generator is
generic(
f_clk : integer := 50000000; -- default: 50 MHz
baud : integer := 115200; -- default: 115,200 baud
accum_width : integer := 16;
accum_inc : integer := (baud sll accum_width) / f_clk
);
port(
clock : in std_logic;
reset_n : in std_logic;
enable : in std_logic;
baud_clock : out std_logic
);
end entity baud_generator;
However, my compiler, Aldec-HDL, doesn't like the following line:
accum_inc : natural := (baud sll accum_width) / f_clk
Here is the exact error message:
# Error: COMP96_0300: baud_generator.vhd : (20, 52): Cannot reference "f_clk" until the interface list is complete.
# Error: COMP96_0300: baud_generator.vhd : (20, 28): Cannot reference "baud" until the interface list is complete.
# Error: COMP96_0071: baud_generator.vhd : (20, 28): Operator "sll" is not defined for such operands.
# Error: COMP96_0104: baud_generator.vhd : (20, 27): Undefined type of expression.
# Error: COMP96_0077: baud_generator.vhd : (20, 27): Assignment target incompatible with right side. Expected type 'INTEGER'.
In verilog, I have something like this:
module baud_generator(
input clock,
input reset_n,
input enable,
output baud_clock
);
parameter f_clock = 50000000;
parameter baud = 115200;
parameter accum_width = 16;
parameter accum_inc = (baud << accum_width) / f_clock;
//...
endmodule
What is it that I need to modify in that line to make the compiler happy? Is it possible to use generics chained together like that?
This basically says you cannot do computations with the generic values to caluclate (default values for) other generics.
Just use accum_inc as a constant, not as a generic.
Also, the SLL (shift logic left) operator is meant for bit patterns (unsigned and signed datatypes in the ieee.numeric_std and ieee.numeric_bit packages), not for integers. You can do the same by multiplying by a power of two.
It looks to me like accum_inc is a constant, not a parameter (as it's calculated from the generics, so there's no reason to override it)
So it doesn't want to be in the generic part - simply move it to the architecture and make it a constant (and as Philippe noted, do your shifting with multiplies):
constant accum_inc : integer := (baud * (2**accum_width)) / f_clk;
You may find that you overflow what integers can manage, depending on the values of the generics, so you might find you want to use unsigned vectors in the generics and/or calculation.