I have a vhdl code written for a shifter made with d-flip flops and multiplexers which runs and checks with successful syntax. However, now that i'm working on the testbench i'm running into some errors.
The VHDL Code is:
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
ENTITY MUX41 IS
PORT (i3, i2, i1, i0 : IN BIT;
s: IN BIT_VECTOR(1 DOWNTO 0);
o: OUT BIT);
END MUX41;
ARCHITECTURE arch_mux41 OF MUX41 IS
BEGIN
PROCESS(i3, i2, i1, i0, s)
BEGIN
CASE s IS
WHEN "00" => o <= i0;
WHEN "01" => o <= i1;
WHEN "10" => o <= i2;
WHEN "11" => o <= i3;
WHEN OTHERS => NULL;
END CASE;
END PROCESS;
END arch_mux41;
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
ENTITY DFF IS
PORT(d, clk : IN BIT;
q, qb : OUT BIT);
END DFF;
ARCHITECTURE arch_dff OF DFF IS
BEGIN
PROCESS(clk)
VARIABLE q_temp : BIT;
BEGIN
IF(clk'EVENT AND clk='1')THEN
q_temp := d;
END IF;
q <= q_temp;
qb <= NOT q_temp;
END PROCESS;
END arch_dff;
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
ENTITY UShift IS
PORT(clk, il, ir : IN BIT;
s: IN BIT_VECTOR(1 DOWNTO 0);
i : IN BIT_VECTOR(3 DOWNTO 0);
q : OUT BIT_VECTOR(3 DOWNTO 0));
END UShift;
ARCHITECTURE struct OF UShift IS
COMPONENT MUX41
PORT (i3, i2, i1, i0 : IN BIT;
s: IN BIT_VECTOR(1 DOWNTO 0);
o: OUT BIT);
END COMPONENT;
COMPONENT DFF
PORT(d, clk : IN BIT;
q, qb : OUT BIT);
END COMPONENT;
FOR U1, U2, U3, U4: MUX41 USE ENTITY WORK.MUX41(arch_mux41);
FOR U5, U6, U7, U8: DFF USE ENTITY WORK.DFF(arch_dff);
SIGNAL o: BIT_VECTOR(3 DOWNTO 0);
SIGNAL qb: BIT_VECTOR(3 DOWNTO 0);
SIGNAL qt:BIT_VECTOR(3 DOWNTO 0);
BEGIN
U1:MUX41 PORT MAP(il,qt(2), i(3), qt(3), s, o(3));
U2:MUX41 PORT MAP(qt(3), qt(1), i(2), qt(2), s, o(2));
U3:MUX41 PORT MAP(qt(2), qt(0), i(1), qt(1), s, o(1));
U4:MUX41 PORT MAP(qt(1), ir, i(0), qt(0), s, o(0));
U5:DFF PORT MAP(o(3), clk, qt(3), qb(3));
U6:DFF PORT MAP(o(2), clk, qt(2), qb(2));
U7:DFF PORT MAP(o(1), clk, qt(1), qb(1));
U8:DFF PORT MAP(o(0), clk, qt(0), qb(0));
q <= qt;
END struct;
The error messages that come up only appear when checking for the syntax in the testbench. They state that the entity does not match component port for "clk", "il", "ir", "i", "s", and "q". Does anyone have any ideas on what I may have wrong? I have read some suggestions online for similar issue but none have applied actually applied to this particular code.
The testbench is:
LIBRARY ieee;
USE IEEE.STD_LOGIC_1164.ALL;
USE ieee.numeric_std.ALL;
ENTITY UShift_test IS
END UShift_test;
ARCHITECTURE behavior OF UShift_test IS
-- Component Declaration for the Unit Under Test (UUT)
COMPONENT UShift
PORT(clk : IN std_logic; il : IN std_logic; ir : IN std_logic; i : IN std_logic_vector(3 downto 0); s:IN std_logic_vector(1 downto 0);
q : OUT std_logic_vector(3 downto 0));
END COMPONENT;
--Inputs
signal clk : std_logic := '0';
signal il : std_logic := '0';
signal ir : std_logic := '0';
signal s : std_logic_vector(1 downto 0) := (others => '0');
signal i : std_logic_vector(3 downto 0) := (others => '0');
--Outputs
signal q : std_logic_vector(3 downto 0);
-- Clock period definitions
constant clk_period : time := 20 ns;
BEGIN
-- Instantiate the Unit Under Test (UUT)
uut: UShift PORT MAP (
clk => clk,
il => il,
ir => ir,
s => s,
i => i,
q => q);
-- Clock process definitions
clk_process :process
begin
clk <= '0';
wait for clk_period/2;
clk <= '1';
wait for clk_period/2;
end process;
-- Stimulus process
stim_proc: process
begin
---- test clr
ir<= '0';
wait for 40ns;
---- test parallel loading
ir<= '1';
s<= "11";
i<= "0010";
wait for 40ns;
---- test shift right
s<= "01";
il<='1';
wait;
end process;
END;
Yes. Here is the entity for UShift:
ENTITY UShift IS
PORT(clk, il, ir : IN BIT;
s: IN BIT_VECTOR(1 DOWNTO 0);
i : IN BIT_VECTOR(3 DOWNTO 0);
q : OUT BIT_VECTOR(3 DOWNTO 0));
END UShift;
Here is the corresponding component in UShift_test:
COMPONENT UShift
PORT(clk : IN std_logic; il : IN std_logic; ir : IN std_logic; i : IN std_logic_vector(3 downto 0); s:IN std_logic_vector(1 downto 0);
q : OUT std_logic_vector(3 downto 0));
END COMPONENT;`:
As you can see, they are different. Unless you use a configuration with a port map which includes type conversion functions, the component and entity should be identical. I highly recommend you don't try to fix this using a configuration, instead I recommend you change the types to match. You have used type BIT in your designs, which is unusual. Unless there is a good reason for that, I'd change type BIT to type STD_LOGIC (and the corresponding vectors, obviously).
And, why are you using component instantiation? Direct instantiation is easier and is less typing and the extra flexibility offered by component instantiation is usually not required. Here is an example that compares the two methods: https://www.edaplayground.com/x/2QrS.
entity fourbitmult is
Port ( a,b : in STD_LOGIC_VECTOR (3 downto 0);
p : out STD_LOGIC_VECTOR (7 downto 0));
end fourbitmult;
architecture Behavioral of fourbitmult is
component twobitmult
port(a,b:in std_logic_vector(1 downto 0);
p:out std_logic_vector (3 downto 0));
end component;
component rca
port(a,b:in std_logic_vector(3 downto 0);
s:out std_logic_vector(3 downto 0);
carry:out std_logic;
cin:in std_logic='0'
);
end component;
component halfadder
port(a,b:in std_logic;
s,c:out std_logic);
end component;
signal c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11,c12,c13,c14,c15,c16,c17,c18,c19,c20,c21,c22: std_logic;
begin
m1:twobitmult port map(a(0),a(1),b(0),b(1),p(0),p(1),c1,c2);
m2:twobitmult port map(a(2),a(3),b(0),b(1),c15,c16,c17,c18);
m3:twobitmult port map(a(0),a(1),b(2),b(3),c19,c20,c21,c22);
m4:twobitmult port map(a(2),a(3),b(2),b(3),c7,c8,c9,c10);
r1:rca port map(c15,c16,c17,c18,c19,c20,c21,c22,c3,c4,c5,c6,c12);
r2:rca port map(c1,c2,c7,c8,c3,c4,c5,c6,p(2),p(3),p(4),p(5),c11);
c13<=c11 or c12;
h1:halfadder port map(c13,c9,p(6),c14);
h2:halfadder port map(c14,c10,p(7));
end Behavioral;
I wrote a VHDL code for the 4 bit vedic multiplier.
I am getting an error as:
Line 45. parse error, unexpected EQ, expecting SEMICOLON or CLOSEPAR"..
The syntax is perfectly right, I don't understand why it's an error. What could be wrong?
The syntax is perfectly right
Not quite.
cin:in std_logic='0'
Should be
cin: in std_logic := '0'
------------------^
You're also missing the context clause at the beginning:
library ieee;
use ieee.std_logic_1164.all;
You've deleted that and some header comments apparently, without indicating which line was line 45 (and it's the line excerpted above). Your example isn't quite a Minimal, Complete, and Verifiable example.
Syntax errors tend to show up easily when you use white space and indentation consistently and well.
Willing to make a claim about the semantics?
Addendum for " More actuals found than formals in port map"
As you've discovered you also have semantic errors as well as the above syntax error. While you didn't update your question, those errors can be explained here too.
The " More actuals found than formals in port map" for original lines 54 - 59 are because you don't have the same number of ports in the port map associations as are declared in the component declarations for twobitmult and rca instances.
You can cure these by using named association which allows you to use a formal's array port elements associated with an array base element type actual. (Allowing more association list entries than the number of ports).
Note that you appear to have an error with the rca component declaration, there are more port map associations shown than are possible by expanding array types.
It appears carry is intended to be an array type (and the following has been annotated to reflect that).
Also note that your array types in your components are declared with port element indexes in a descending order and you associate them with ascending order elements of entity fourbitmult array type ports.
Should you be able to use slices of the actuals with the same range direction as they are declared the association list entry could be simplified as a => a(1 downto 0), for example. The same holds true for other places you can connect slice actuals.
So making the number of ports match by using formal elements:
library ieee;
use ieee.std_logic_1164.all;
entity fourbitmult is
port (
a,b: in std_logic_vector (3 downto 0);
p: out std_logic_vector (7 downto 0));
end fourbitmult;
architecture behavioral of fourbitmult is
component twobitmult
port (
a,b: in std_logic_vector (1 downto 0);
p: out std_logic_vector (3 downto 0)
);
end component;
component rca
port (
a,b: in std_logic_vector (3 downto 0);
s: out std_logic_vector (3 downto 0);
carry: out std_logic_vector (3 downto 0); -- std_logic;
cin: in std_logic := '0' -- formerly line 45
);
end component;
component halfadder
port (
a,b: in std_logic;
s,c: out std_logic
);
end component;
signal c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11,c12,
c13,c14,c15,c16,c17,c18,c19,c20,c21,c22: std_logic;
begin
m1:
twobitmult
port map (
-- a(0),a(1),b(0),b(1),p(0),p(1),c1,c2
a(1) => a(0),
a(0) => a(1),
b(1) => b(0),
b(0) => b(1),
p(3) => p(0),
p(2) => p(1),
p(1) => c1,
p(0) => c2
);
m2:
twobitmult
port map (
-- a(2),a(3),b(0),b(1),c15,c16,c17,c18
a(1) => a(2),
a(0) => a(3),
b(1) => b(0),
b(0) => b(1),
p(3) => c15,
p(2) => c16,
p(1) => c17,
p(0) => c18
);
m3:
twobitmult
port map (
-- a(0),a(1),b(2),b(3),c19,c20,c21,c22
a(1) => a(0),
a(0) => a(1),
b(1) => b(2),
b(0) => b(3),
p(3) => c19,
p(2) => c20,
p(1) => c21,
p(0) => c22
);
m4:
twobitmult
port map (
-- a(2),a(3),b(2),b(3),c7,c8,c9,c10
a(1) => a(2),
a(0) => a(3),
b(1) => b(2),
b(0) => b(3),
p(3) => c7,
p(2) => c8,
p(1) => c9,
p(0) => c10
);
r1:
rca
port map (
--c15,c16,c17,c18,c19,c20,c21,c22,c3,c4,c5,c6,c12
a(3) => c15,
a(2) => c16,
a(1) => c17,
a(0) => c18,
b(3) => c19,
b(2) => c20,
b(1) => c21,
b(0) => c22,
carry(3) => c3,
carry(2) => c4,
carry(1) => c5,
carry(0) => c6,
cin => c12
);
r2:
rca
port map (
-- c1,c2,c7,c8,c3,c4,c5,c6,p(2),p(3),p(4),p(5),c11
a(3) => c1,
a(2) => c2,
a(1) => c7,
a(0) => c8,
b(3) => c3,
b(2) => c4,
b(1) => c5,
b(0) => c6,
carry(3) => p(2),
carry(2) => p(3),
carry(1) => p(4),
carry(0) => p(5),
cin => c11
);
c13 <= c11 or c12;
h1:
halfadder
port map (
c13,c9,p(6),c14
);
h2:
halfadder
port map (
c14,c10,p(7)
);
end behavioral;
This analyzes, but without the entity/architecture pairs for the declared components can't be elaborated, nor the functionality verified.
I am creating a stack based on the artix-7 fabric on the zynq soc. To create the stack I want to use the BRAM, I'm having a problem that the BRAM read output doesn't change, I've used BRAMS many times before (not 7-series so I may be missing something subtle) and am totally perplexed as to why it is doing this.
I filled the stack with values: 1, 2 ,3
When I then call pop successively the only value it reads out is 3 for each pop and read address (even after waiting for the one clock read delay). I have also tried with dual port rams and had the same issue, i'm sticking to single port as it simpler to try and workout what is going wrong!
I have verified the logic behavior using an array based ram which has the correct behavior. For verification I also checked the logic from this source: http://vhdlguru.blogspot.co.uk/2011/01/implementation-of-stack-in-vhdl.html.
So the issue appears to be with the BRAM, either it is not reading properly or for some reason it is writing the value 3 to all previous memory address which makes no sense as each data item is synced with a write signal and correct address.
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.std_logic_unsigned.all;
use IEEE.numeric_std.ALL;
-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
--use IEEE.NUMERIC_STD.ALL;
-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
library UNISIM;
use UNISIM.VComponents.all;
-- Stack implementation for 32 bit data items using BRAM componenets
entity stack_32_BRAM is
generic( ADDR : integer :=32);
Port ( clk : in STD_LOGIC;
rst : in STD_LOGIC;
en : in STD_LOGIC;
push_pop : in STD_LOGIC;
data_in : in STD_LOGIC_VECTOR (31 downto 0);
data_out : out STD_LOGIC_VECTOR (31 downto 0));
end stack_32_BRAM;
architecture Behavioral of stack_32_BRAM is
COMPONENT BRAM_32_1K
PORT (
clka : IN STD_LOGIC;
rsta : IN STD_LOGIC;
wea : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
addra : IN STD_LOGIC_VECTOR(31 DOWNTO 0);
dina : IN STD_LOGIC_VECTOR(31 DOWNTO 0);
douta : OUT STD_LOGIC_VECTOR(31 DOWNTO 0);
clkb : IN STD_LOGIC;
rstb : IN STD_LOGIC;
web : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
addrb : IN STD_LOGIC_VECTOR(31 DOWNTO 0);
dinb : IN STD_LOGIC_VECTOR(31 DOWNTO 0);
doutb : OUT STD_LOGIC_VECTOR(31 DOWNTO 0)
);
END COMPONENT;
COMPONENT BRAM_32_1K_SP
PORT (
clka : IN STD_LOGIC;
rsta : IN STD_LOGIC;
wea : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
addra : IN STD_LOGIC_VECTOR(31 DOWNTO 0);
dina : IN STD_LOGIC_VECTOR(31 DOWNTO 0);
douta : OUT STD_LOGIC_VECTOR(31 DOWNTO 0)
);
END COMPONENT;
--The read ptr is a function of the write ptr
signal stack_ptr_read, stack_ptr_write : std_logic_vector(ADDR-1 downto 0) := (others =>'0');
signal full, empty : std_logic := '0';
signal WEA : std_logic_vector(3 downto 0) :=(others=>'0'); -- 4-bit input: A port write enable
signal addra, addrb, dinb, doutb, dina, douta : std_logic_vector(31 downto 0) := (others => '0');
signal rsta, rstb :std_logic := '0' ;
type ram is array (4 downto -2) of std_logic_vector(31 downto 0) ;
signal mem : ram :=(others=>(others=>'0'));
begin
---STACK LOGIC ---
PUSH : process (clk, push_pop, en, full, empty)
begin
if(clk'event and clk='1') then
WEA <= "0000";
if(en='1' and push_pop = '1' and full = '0') then
mem(to_integer(unsigned(stack_ptr_write))) <= data_in;
WEA <= "1111";
dina <= data_in ;
ADDRA <= stack_ptr_write;
stack_ptr_write <= stack_ptr_write + 1;
elsif(en='1' and push_pop = '0' and empty = '0') then
data_out <= douta ;--
doutb <= mem(to_integer(unsigned(stack_ptr_write - 1)));
ADDRA <= stack_ptr_write - 1;
stack_ptr_write <= stack_ptr_write - 1;
end if;
end if;
end process;
BRAM_SP : BRAM_32_1K_SP
PORT MAP (
clka => clk,
rsta => rsta,
wea => wea,
addra => addra,
dina => dina,
douta => douta
);
end Behavioral;
Many thanks
Sam
The solution entails several things:
1) You have to explicitly reset the signals with the rst port in every process. Initializing them in their declaration just doesn't cut it.
The process' code with a proper reset and sensitivity list should then look like this:
PUSH : process (rst, clk)
begin
if (rst = '1') then --supposing active-high async. reset
WEA <= (others => '0');
ADDRA <= (others => '0');
dina <= (others => '0');
data_out <= (others => '0');
full <= '0';
empty <= '0';
stack_ptr_write <= (others => '0');
elsif(clk'event and clk='1') then
--your code
2) I understand you have several layers/tries of code here in the same place. This is messy to read. I see you are using a "mem" to hold your example (so that WEA, ADDRA, dina, etc are ignorable), but when you get back to BRAM_32_1K_SP remember to check it has 32 bits addresses which, coupled with 32 bits data, mean that you have a 32 * 2**32 bits ram... that is around 128 Gbits, typo I guess.
However, to make a clearer question you should leave only the code pertaining to the memory solution you're having a problem with.
3) your code does include some typos that you should fix, like assigning "doutb" in the process, whereas I guess you wanted to assign data_out instead:
data_out <= mem(to_integer(unsigned(stack_ptr_write - 1)));
And this is the reason why you don't see what you want at the output.