VHDL: formal generic 'n' has no actual or default value? - vhdl

I'm trying to simulate my VHDL component in Vivado and i'm receiving a compilation error: "formal generic 'n' has no actual or default value". I would appreciate any advice or solution to this error.
I have seen the issue VHDL: formal port 'portName' has no actual or default value and my error, although similar, does not seem related.
entity bit_tester is
generic (N : integer);
port(in1 : in bit_vector (N-1 downto 0);
out1 : out bit;
out2 :out bit;
out3 :out bit);
end bit_tester;
architecture behavioral of bit_tester is

It's not clear from the question how you are trying to simulate this entity.
But you are not providing a value for your generic "N"
You have to either assign it a default value:
entity bit_tester is
generic (N : integer := 5);
port(in1 : in bit_vector (N-1 downto 0);
out1 : out bit;
out2 :out bit;
out3 :out bit);
end bit_tester;
Or give it a value when you instantiate the entity:
inst_bit_tester:bit_tester
generic map(N => 5)
port map(in1 => in1,
out1 => out1,
out2 => out2,
out3 => out3);

Related

How can i use generic array type with modelsim?

It's my first question here, I really hope you can help me
Edit 03 December 2019 :
We resolved our problem with the declaration type, but now, we have other problem
So, when I tried to run my testbench for the simulation on modelsim, we got these errors.
# Conv_rev3_run_msim_rtl_vhdl.do
# invalid command name "Conv_rev3_run_msim_rtl_vhdl.do"
Here our package for the declaration of type
-- synthesis VHDL_INPUT_VERSION VHDL_2008
library ieee;
use ieee.std_logic_1164.all;
package conv_p is
type slv_array_t is array (natural range <>) of std_logic_vector;
end package;
The entity of the main files
entity Conv_rev3 is
generic(
LEN : natural := 8; -- Bits in each input
NUM : natural := 4); -- Number of inputs
port(
clk : in std_logic;
D : in conv_p.slv_array_t(0 to NUM - 1)( LEN - 1 downto 0);
W : in conv_p.slv_array_t(0 to NUM - 1)( LEN - 1 downto 0);
z_o : out std_logic_vector(LEN*2 - 1 downto 0));
end entity;
Here a sample of our testbench :
LIBRARY IEEE;
USE ieee.std_logic_1164.all;
USE work.conv_p;
ENTITY Conv_rev3_vhd_tst IS
END Conv_rev3_vhd_tst;
ARCHITECTURE Conv_rev3_arch OF Conv_rev3_vhd_tst IS
-- constants
-- signals
SIGNAL clk : STD_LOGIC;
SIGNAL D : conv_p.slv_array_t(0 to 3)(7 downto 0);
SIGNAL W : conv_p.slv_array_t(0 to 3)(7 downto 0);
SIGNAL z_o : STD_LOGIC_VECTOR(15 DOWNTO 0);
COMPONENT Conv_rev3
PORT (
clk : IN STD_LOGIC;
D : IN conv_p.slv_array_t(0 to 3)(7 downto 0);
W : IN conv_p.slv_array_t(0 to 3)(7 downto 0);
z_o : OUT STD_LOGIC_VECTOR(15 DOWNTO 0)
);
END COMPONENT;
Best Regards
In your first problem, it is highly probable that the entity name that you have specified in your code is wrong and that is why it is unable to find that entity and shows that error. And thus it goes without saying that if it hasn't even found the entity, then it won't be able to compile it.
Now I don't think that there is need to answer the second question because there must be some error in it.

Can I use 'port map' in a 'process'?

library ieee;
use ieee.std_logic_1164.all;
-- create a entity
entity ex1_3 is
port(
a,b,c,d: in std_logic_vector (3 downto 0);
ctrl: in std_logic;
sum: out std_logic );
end ex1_3;
architecture impl of ex1_3 is
-- declare a component of four bit ripple carry adder
component four_bit_ripple_carry_adder is
port(
a,b: in std_logic_vector (3 downto 0);
cin: in std_logic;
s: out std_logic_vector (3 downto 0);
cout:out std_logic
);
end component;
signal s: std_logic_vector (3 downto 0);
begin
process(a,b,c,d,ctrl)
begin
-- error:Illegal sequential statement.
if ctrl = '0' then
u0: four_bit_ripple_carry_adder port map(a,b,ctrl,s,sum);
elsif ctrl = '1' then
u1: four_bit_ripple_carry_adder port map(c,d,ctrl,s,sum);
end if;
end architecture;
** Error: /home/atomman/drs_exercises/exercise_04/ex1_3.vhd(30): Illegal sequential statement.
** Error: /home/atomman/drs_exercises/exercise_04/ex1_3.vhd(32): Illegal sequential statement.
** Error: /home/atomman/drs_exercises/exercise_04/ex1_3.vhd(35): near "architecture": (vcom-1576) expecting PROCESS.
Never forget that the "H" in HDL stands for "Hardware".
What you are saying is "if ctrl=0 then use a piece of hardware, name it u0 which is connect as ... else replace that piece of hardware, now name it u1 and connect it as ...".
There is no simple hardware equivalent that dynamically, based on a signal (in this case 'ctrl') swaps in and out two components.
The only difference is in the first two ports, which makes the solution simple: You make one component and use a multiplexer1 for the first two input ports:
signal a_or_c_mux: std_logic_vector (3 downto 0);
signal b_or_d_mux: std_logic_vector (3 downto 0);
a_or_c_mux <= a when ctrl='0' else c;
b_or_d_mux <= b when ctrl='0' else d;
Now you can instance your module (once! and outside a process) and use the signals a_or_c_mux and b_or_d_mux as input to the first two ports of the module.
1On purpose I am using 'hardware' nomenclature.

VHDL Selection machine error in port map

I get this error:
# Error: COMP96_0100: data_reg.vhd : (156, 35): Actual parameter type in port map does not match the port formal type "Allin".
# Error: COMP96_0100: data_reg.vhd : (158, 1): Actual parameter type in port map does not match the port formal type "Fout".
# Error: COMP96_0100: data_reg.vhd : (162, 1): Actual parameter type in port map does not match the port formal type "D".
# Error: COMP96_0100: data_reg.vhd : (163, 1): Actual parameter type in port map does not match the port formal type "Q".
I need some help, please.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
entity ticket1 is
port (
A, B : in std_logic_vector(7 downto 0);
Clock: in std_logic;
O: out std_logic_vector(7 downto 0));
end entity;
architecture Ticketmachine of ticket1 is
component ticket_selection
port(
Allin:in bit_vector(3 downto 0);
Clk: in std_logic;
Fout: out bit_vector(7 downto 0));
end component ticket_selection;
component reg is
port(
C: in std_logic;
D: in bit_vector(7 downto 0);
Q : out bit_vector(7 downto 0));
end component reg;
component Money is
port (
Ai,Bi : in std_logic_vector(7 downto 0);
Fo: out std_logic_vector(7 downto 0));
end component money;
signal s1,s2: std_logic_vector(7 downto 0);
begin
Option: ticket_selection
port map(
Allin=>A,
Clk=>Clock,
Fout=>s1);
Cash: reg
port map(
C=>Clock,
D=>B,
Q=>s2);
Pros: Money
port map(
Ai=>s1,
Bi=>s2,
Fo=>O);
end architecture;
You should read carefully some VHDL guide for beginners. I can't recommend any (maybe someone could?), so I'll go straight to your mistakes here:
Never use std_logic_unsigned, std_logic_unsigned, and std_logic_arith. This libraries are not part of standard, and can be replaced with numeric_std.
Don't use bit or bit_vector type. Use std_logic, and std_logic_vector instead.
When you associate one vector to other, they must have equal type and length, as user1155120 and Brian Drummond wrote in comment. In particular, you can't assign std_logic_vector(7 downto 0) to bit_vector(3 downto 0).
There are probably more things done wrong here, but your question is not complete - you didn't provide any explanation what it should do, no full code, and no testbench.

"template" VHDL entities

This has me bugging for quite some time, but is it possible to describe entities in VHDL similar to how templates work in C++ (or to lesser extend generics?). Simply leaving the actual port types to be only decided during synthesize/compilation?
An example would be a multiplexer, say I have a 4 input multiplexer, now I have several bus sizes I use this multiplexer for, -4,6,7,8-. Currently I wrote a different multiplexer for each different bus size; however the output is simply one of the chosen inputs forwarded, and is thus of the same type as the bus.
This seems overly redundant and error prone (choose correct multiplexer at correct times, keep them all in line, update them as I change the bus size). Is there no way to parameterize this?
non generic version below to show the idea.
entity mux_6bit_4input is
port ( input_0 : in std_logic_vector (5 downto 0);
input_1 : in std_logic_vector (5 downto 0);
input_2 : in std_logic_vector (5 downto 0);
input_3 : in std_logic_vector (5 downto 0);
sel : in std_logic_vector (1 downto 0);
output : out std_logic_vector (5 downto 0)
);
end entity mux_6bit_4input;
Maybe I misunderstood the question, but doesn't the common solution using generics solve your problem?
library ieee;
use ieee.std_logic_1164.all;
entity mux_4x1 is
generic (
DATA_WIDTH: integer := 8
);
port (
input_0: in std_logic_vector(DATA_WIDTH-1 downto 0);
input_1: in std_logic_vector(DATA_WIDTH-1 downto 0);
input_2: in std_logic_vector(DATA_WIDTH-1 downto 0);
input_3: in std_logic_vector(DATA_WIDTH-1 downto 0);
sel: in std_logic_vector (1 downto 0);
output: out std_logic_vector(DATA_WIDTH-1 downto 0)
);
end;
architecture behavior of mux_4x1 is
begin
output <=
input_0 when sel = "00" else
input_1 when sel = "01" else
input_2 when sel = "10" else
input_3;
end;
Another solution, if you want to keep things really generic, is to use the cool generic types in VHDL-2008. My simulator doesn't yet support this feature, so here's an example from the excellent book VHDL 2008: Just the New Stuff:
entity generic_mux2 is
generic (type data_type);
port (
sel: in bit;
a, b: in data_type;
z: out data_type
);
end;
architecture rtl of mux2 is
begin
z <= a when sel = '0' else b;
end;
Another option is to use unconstrained arrays:
entity mux_4input is
port (
input_0 : in std_logic_vector ;
input_1 : in std_logic_vector ;
input_2 : in std_logic_vector ;
input_3 : in std_logic_vector ;
sel : in std_logic_vector (1 downto 0);
output : out std_logic_vector
);
end entity mux_4input;
They will inherit their width (and direction) from the signals they are conencted to in the instantiating entity.
It's probably not the right thing to do in this particular case of a mux, rick's answer is what I'd go for, but unconstrained arrays don't get mentioned much, so I thought I'd offer them! In this case, you'd probably also want some asserts to ensure that everything you've wired up is the same width.

VHDL output is undifined in simulation but compilation is passed fine

I am a fresh student and the assignment is to build 3 components with testbench and then to arrange them into one structure. All 3 components I have built work great but when I put them together one of the the outputs stays undefined. I tried to trace the signal called dat and it is fine, but probably I am not using correct syntax to assign the dat signal to data_out . The id_led_ind is the second output and it works fine but the data_out is undefined.
Here is the code (i think the problem is in lane 21 - "data_out <= dat")
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
entity peak_detect is
port(
input : in std_logic_vector (7 downto 0);
data_out : out std_logic_vector (7 downto 0);
reset : in std_logic;
clock : in std_logic;
enable : in std_logic;
id_led_ind : out std_logic);
end peak_detect;
architecture dataflow of peak_detect is
signal a_big_b : std_logic;
signal en : std_logic;
signal dat : std_logic_vector (7 downto 0);
begin
en <= (enable or a_big_b);
data_out <= dat;
end dataflow;
architecture structure of peak_detect is
signal a_big_b : std_logic;
signal en : std_logic;
signal dat : std_logic_vector (7 downto 0);
component comp_8bit is
port(
A : in std_logic_vector (7 downto 0);
B : in std_logic_vector (7 downto 0);
res : out std_logic);
end component;
component dff is
port (
data : in std_logic_vector (7 downto 0);
q : out std_logic_vector (7 downto 0);
clk : in std_logic;
reset : in std_logic;
en : in std_logic);
end component;
component id_sens is
port(
data_in : in std_logic_vector (7 downto 0);
led : out std_logic);
end component;
begin
reg : dff port map (data => input, q => dat, clk => clock, reset => reset, en => enable);
comp : comp_8bit port map (A => input, B => dat, res => a_big_b);
sens : id_sens port map (data_in => dat, led => id_led_ind);
end structure;
There appears to be confusion over having two architectures (dataflow and structure) for the entity peak_detect. The two architectures are mutually exclusive, and the last one analyzed is the default in absence of other configuration specifying one of the architectures directly.
For purposes of evaluating how the components are interconnected and their port mapped connections relate to the port declarations of peak_detect, the first architecture could be commented out (dataflow).
When you disregard the architecture dataflow we find there is no driver for data_out in architecture structure.
You're missing an assignment to data_out using dat as a source in architecture structure, as found in architecture dataflow. Copy or replicate the concurrent signal assignment statement data_out <= dat; into architecture structure.
You can't simply connect data_out to q in the port map of dff because the output of dff is also used as an input to id_sense.
dat is driven by q of dff. That is not how you connect components. port map should be used to connect ports of different components/entities, not signals of any entity to the port of another entity.

Resources