Thanks to all your input, I implemented your suggestions, however the problem remains the same. The result in simulation works fine, but the hardware
outputs something different. Just to briefly recap, I have two ctrl signals that determine the behaviour of the entity:
GET (ctrl = "00000000") sets register tx to input of op1
SH1_L (ctrl = "00000001") res := (op1 << 1) | tx;
tx := tx >> 31;
Here is the VHDL code:
library ieee;
use ieee.std_logic_1164.all;
entity test is
port
(
op1 : in std_logic_vector(31 downto 0); -- Input operand
ctrl : in std_logic_vector(7 downto 0); -- Control signal
clk : in std_logic; -- clock
res : out std_logic_vector(31 downto 0) -- Result
);
end;
architecture rtl of test is
type res_sel_type is (GET, SH1_L);
constant Z : std_logic_vector(31 downto 0) := (others => '0');
signal res_sel : res_sel_type;
signal load : std_logic := '0';
signal shl : std_logic := '0';
signal tx : std_logic_vector(31 downto 0) := (others => '0');
signal inp1 : std_logic_vector(31 downto 0) := (others => '0');
begin
dec_op: process (ctrl, op1)
begin
res_sel <= GET;
load <= '0';
shl <= '0';
inp1 <= ( others => '0');
case ctrl is
-- store operand
when "00000000" =>
inp1 <= op1;
load <= '1';
res_sel <= GET;
-- 1-bit left-shift with carry
when "00000001" =>
inp1 <= op1;
shl <= '1';
res_sel <= SH1_L;
when others =>
-- Leave default values
end case;
end process;
sel_out: process (res_sel, inp1, tx)
begin
case res_sel is
when SH1_L =>
res <= ( inp1(30 downto 0) & '0' ) or tx;
when others =>
res <= (others => '0');
end case;
end process;
sync: process(clk)
begin
if clk'event and clk = '1' then
if load = '1' then
tx <= op1;
elsif shl = '1' then
tx <= Z(30 downto 0) & op1(31);
end if;
end if;
end process;
end rtl;
TESTPROGRAM
GET 0 (this sets tx <= 0 )
SH1_L 0xfedcba90 exp. output: 0xfdb97520 act. output = 0xfdb97521
SH1_L 0x7654321f exp. output: 0xeca8643f act. output = 0xeca8643f
SH1_L 0x71234567 exp. output: 0xe2468ace act. output = 0xe2468ace
As you can see, the last bit is wrong for the first SH1_L operation. The first SH1_L operation produces a carry for the NEXT SH1_L operation since
the MSB is set to one of the input, however, it seems that this carry is already considered in the current SH1_L operation, which is wrong (tx should be zero).
I checked the synthesis report and there are no latches, so I am a bit clueless and almost desperate what is going wrong here. I use Xilinx ISE 12.1 for
synthesis, could there be a problem because I do not have a reset signal in my architecture, that the wrong kind of latches are instantiated?
Many thanks for further helpful comments to solve this issue,
Patrick
Unlike RTL simulation, real-life timing of inputs and clocks is not ideal. For example, the clock tree might have a longer delay than input buffers or vice versa. Did you take this into account?
Related
I'm new to fpga and VHDL in general (I'm using a fpga aprox. 2 weeks now). I am trying to create a project that lights up LEDs in order. First of all I made a falling edge detector for the button. And then I created a std_logic_vector for LEDs. But I can't detect a signal change in fallen edge detection. Because of that I can't change LED state. There is my testbench for simulation. I don't have any idea what's going on. Thanks for your answers and sorry for my bad English.
Code:
library ieee;
use ieee.std_logic_1164.all;
entity sequential_led is
end sequential_led;
architecture seq_led of sequential_led is
signal clk : std_logic := '0';
--signal rst : std_logic := '1';
--signal rstb : std_logic := '1';
signal i : natural := 0;
signal dus_next : std_logic := '0';
signal dusen : std_logic := '0';
signal button : std_logic := '0';
signal led : std_logic_vector(7 downto 0);
begin
clk <= not clk after 1 ns;
button <= not button after 2 ns;
falling:
process begin
if rising_edge(clk) then
dus_next <= button;
end if;
wait for 100 ns;
end process falling;
dusen <= (not button) and dus_next;
led_changes:
process begin
if dusen = '1' then
i <= i + 1;
if i = 7 then
i <= 0;
end if;
end if;
led(7-i) <= '0';
led(i) <= '1';
wait for 100 ns;
end process led_changes;
end architecture;
UPDATE: First of all very big thanks to DomasAquinas and Martin Thompson! After 3 days of work, I finally finished my little LED project.
Change: I've made sure all of processes has a sensivity trigger.
For falling process I've included 'clk' signal for sensivity.
For led_change process I've included 'dusen' signal for sensivity.
Code:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity sequential_led is
port(
clk : in std_logic;
button : in std_logic;
led : out std_logic_vector(7 downto 0) := (others => '0')
);
signal dus_next : std_logic;
signal i : natural range 0 to 7;
signal dusen : std_logic := '0';
end sequential_led;
architecture seq_led of sequential_led is
begin
falling:
process(clk) begin
if rising_edge(clk) then
dus_next <= button;
end if;
end process falling;
dusen <= (not button) and dus_next;
led_changes:
process(dusen) begin
if dusen = '1' then
i <= i + 1;
if i = 7 then
i <= 0;
end if;
led(i) <= '1';
led(i+7) <= '0';
end if;
end process led_changes;
end architecture;
Well, I'm trying to make a module in VHDL language, so far I have the internal clock (100MHz) and a control signal called IN (std_logic), and I need an output signal OUT (std_logic) of arbitrary width, said wide I want to control counting the clock rising_edge, I don't have a good programming base, that's why I'm stuck with this, if anyone can help me I thank you
I enclose an illustrative image of how I wish to have the output, where delta / \ is an arbitrary interval that does not depend on the IN input, when IN goes low, the OUT signal must remain on until the counter finishes its purpose..
https://imgur.com/a/NoPZZjP
So you basically what to create an off delay?
Note: VHDL 2008 migth apply (my usual language)
entity off_delay is
generic(
n : natural : 2 -- off delay
);
port(
clk : in std_logic;
a : in std_logic;
b : out std_logic
);
end entity;
clk _/¯\__/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\
a _____/¯¯¯\________________________________
b _________/¯¯¯¯¯¯¯¯¯¯¯¯\___________________
architecture synkron of off_delay is
signal delay: std_logic_vector(n downto 0); -- 1+n cycles out signal
begin
b <= delay(0);
process(clk)
begin
if rising_edge(clk) then
delay <= (others => '1') when a else ('0' & delay(delay'left downto 1));
end if;
end process;
end architecture;
clk _/¯\__/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\_/¯\
a _____/¯¯¯\_____________________________
b _____/¯\¯\¯¯¯¯¯¯¯¯¯¯\___________________
architecture asynkron of off_delay is
signal delay: std_logic_vector(n-1 downto 0); -- n cycles off delay
begin
b <= delay(0) or a;
process(clk)
begin
if rising_edge(clk) then
delay <= (others => '1') when a else ('0' & delay(delay'left downto 1));
end if;
end process;
end architecture;
Note: The asynkron solution will be dependent on stable a as it will be susceptible to glitches.
Note: The asynkron solution will introduce a delta delay that might be hard to debug
Note: Those are the simplest soulutions. To get technical a SR latch could be implemented to set by a in an asynkron fassion and reset by the synkron delay line. OBS Latches are strongly adviced against in fpga design!
Here is another solution which use more ressources with a low width but less with a high width and with width as an input instead of generic :
entity top is
port
(
i_rst : in std_logic;
i_clk : in std_logic;
i_din : in std_logic;
i_width : in std_logic_vector(7 downto 0);
o_dout : out std_logic
);
end top;
architecture Behavioral of top is
signal counter : unsigned(7 downto 0);
signal oe : std_logic;
begin
process(i_clk)
begin
if i_rst = '1' then
counter <= (others => '0');
oe <= '0';
elsif rising_edge(i_clk) then
if oe = '1' then
counter <= counter + 1;
if counter = unsigned(i_width) - 1 then
counter <= (others => '0');
oe <= '0';
end if;
elsif i_din = '1' then
if unsigned(i_width) > x"01" then
counter <= counter + 1;
oe <= '1';
end if;
end if;
end if;
end process;
o_dout <= oe or i_din;
end Behavioral;
But as Halfow told you, use combinational just before the output makes your module very sensitive to glitches.
I'm currently working on a component that will perform addition or subtraction, depending on the user input. Right now, I am working on a process that handles the assignment of values to the internal signals which will be used by the internal components I am using. One problem that comes up is in the line when I'm assigning b_in with either the input b or the 2's complement of the input b. Two errors show up:
Error: COMP96_0015: addsub_16.vhd : (85, 17): ';' expected.
Error: COMP96_0046: addsub_16.vhd : (85, 41): Sequential statement expected.
The errors all reference to the line
b_in <= (b) when add_sub = '0' else (b_2scomp);
However when I placed this outside the process, no error occurred; only when it's inside the process. Can someone please help me why this is and what I can do to solve it?
In addition, I know that normally port mapping is done between the architecture declaration and the begin statement of the architecture. The reason I placed them after the process is because I needed to make sure that b_in has the right signal before the other components can use it. I don't know if this is the right way to do it, but I hope it is. This is just in case you guys are wondering why I'm dong it like this. Thanks
library IEEE;
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_UNSIGNED.all;
use IEEE.STD_LOGIC_ARITH.all;
entity addsub_16 is
port(
c_in : in STD_LOGIC;
enable : in std_logic;
reset : in std_logic;
clk : in std_logic;
add_sub : in STD_LOGIC;
a : in STD_LOGIC_VECTOR(15 downto 0);
b : in STD_LOGIC_VECTOR(15 downto 0);
c_out : out STD_LOGIC;
result : out STD_LOGIC_VECTOR(15 downto 0)
);
end addsub_16;
architecture addsub_16 of addsub_16 is
--Signal declarations to hold internal vectors a, b g, p, and carry
signal a_in : std_logic_vector(15 downto 0); --Holds input a
signal b_in : std_logic_vector(15 downto 0); --Holds input b if add_sub = 0. Otherwise, holds b_2scomp
signal b_2scomp : std_logic_vector(15 downto 0); --Holds the 2s complement of b
signal prop_in : std_logic_vector(15 downto 0); --Holds the propagate signals from CLAs
signal gen_in : std_logic_vector(15 downto 0); --Holds the generate signals from CLAs
signal carry_in : std_logic_vector(15 downto 0); --Holds the carry signal from carry_logic
signal temp_result : std_logic_vector(15 downto 0); --Holds the temporary result to be driven out
--Component declarations
component cla_4bit
port (
a, b : in std_logic_vector(3 downto 0);
gen, prop : out std_logic_vector(3 downto 0)
);
end component;
component carry_logic
port (
g, p : in std_logic_vector(15 downto 0);
c_in : in std_logic;
carry : out std_logic_vector(15 downto 0);
c_out : out std_logic
);
end component;
--Actual behavior of module
begin
--b_in <= (b) when add_sub = '0' else (b_2scomp);
process (clk, reset)
begin
if reset = '0' then --At reset, everything is 0
a_in <= (others => '0');
b_in <= (others => '0');
b_2scomp <= (others => '0');
temp_result <= (others => '0');
elsif (rising_edge(clk)) then --Read in data to components on rising edge
if enable = '1' then --Only if enable is on
a_in <= a;
b_2scomp <= ((not b) + '1');
b_in <= (b) when add_sub = '0' else (b_2scomp);
end if;
elsif (falling_edge(clk)) then --Drive out values on falling edge
for i in 0 to 15 loop
temp_result(i) <= a_in(i) xor b_in(i) xor carry_in(i);
end loop;
result <= temp_result;
end if;
end process;
--portmapping of the components here. I don't think it'd be necessary to include them, but let me know if they are needed.
The ternary operator .. when .. else .. is not allowed inside a process block prior to VHDL-2008.
Solution 1: Write an ordinary if .. then .. else .. end if statement
Solution 2: Enable VHDL-2008 support in your tool chain
Solution 3: Write a function, lets say ite (if-then-else), which performs the ternary operation.
I'm trying to make a 32 bit counter in VHDL. Below is my code:
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.numeric_std.ALL;
ENTITY counter32 IS
PORT (en, clk, clr: IN STD_LOGIC;
count: OUT STD_LOGIC_VECTOR(4 DOWNTO 0));
END counter32;
ARCHITECTURE rtl OF counter32 IS
SIGNAL count_result: STD_LOGIC_VECTOR(4 DOWNTO 0);
BEGIN
counter32: PROCESS(clk, clr)
BEGIN
count <= "00000"; --Initialize counter to all zeroes
IF (clr = '0') THEN
count_result <= "00000";
ELSIF (clk = '1' and clk'EVENT) THEN
IF (en = '1') THEN
count <= STD_LOGIC_VECTOR(unsigned(count_result) + 1);
count <= STD_LOGIC_VECTOR(count_result);
ELSIF (count_result = "11111") THEN
count_result <= "00000";
END IF;
END IF;
END PROCESS counter32;
END rtl;
My test bench code is here:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity counter32_tb is
end counter32_tb;
architecture io of counter32_tb is
component counter32 is
port(en,clk,clr:in std_logic; count:out std_logic_vector(4 downto 0));
end component;
for all: counter32 use entity work.counter32(rtl);
signal en,clk,clr:std_logic;
signal count:std_logic_vector(4 downto 0);
begin
count <= "00000";
g0: counter32 port map(en,clk,clr,count);
p0: process
begin
en <= '1';
clk <= '0';
clr <= '1';
wait for 10ns;
en <= '1';
clk <= '1';
clr <= '1';
wait for 10ns;
en <= '1';
clk <= '0';
clr <= '1';
wait for 10ns;
en <= '1';
clk <= '1';
clr <= '1';
wait for 10ns;
en <= '1';
clk <= '0';
clr <= '1';
wait for 10ns;
en <= '1';
clk <= '1';
clr <= '0';
end process;
end io;
Whenever I test, however, an addition of 1 gives a 'U' STD_LOGIC value and a red bar in testing, as you can see here:
Any idea what the matter is? I'm really confused!
Any idea what the matter is?
Your waveform doesn't match your test bench stimulus.
There are three assignments to the signal count which appears to show in your waveform (at the test bench level). An initial assignment to "00000", and two conditional assignments. The bouncing back and forth is caused by the process sensitity to clk, bouncing back to "00000" on the following edge of clock using the first assignment statement.
In a process statement the last assignment is the one that takes effect. You're writing it to "00000" and changing that to count_result conditionally based on the positive edge of clock. Note that you aren't actually loading count with count_result + 1 either, the next assignment provides the current value of count_result. While we're on the subject the type conversion to std_logic_vector isn't needed either, count_result is already a std_logic_vector.
The unknown (red) 'flash' at the clock edge is because you haven't actually cleared count_result. The only event on clr is from 'U' to '1' and causes no clear.
The vhdl design code is not functional as a counter.
This:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity counter32 is
port (
en, clk, clr: in std_logic;
count: out std_logic_vector(4 downto 0)
);
end counter32;
architecture rtl of counter32 is
signal count_result: std_logic_vector(4 downto 0);
begin
counter: process(clk, clr)
begin
if clr = '0' then
count_result <= (others => '0');
elsif clk = '1' and clk'event and en = '1' then
count_result <= std_logic_vector(unsigned(count_result) + 1);
end if;
end process;
count <= count_result;
end rtl;
library ieee;
use ieee.std_logic_1164.all;
entity counter32_tb is
end entity;
architecture foo of counter32_tb is
signal en: std_logic:= '0';
signal clr: std_logic:= '1';
signal clk: std_logic:= '0';
signal count: std_logic_vector (4 downto 0);
begin
DUT: entity work.counter32
port map (
en => en,
clk => clk,
clr => clr,
count => count
);
CLOCK:
process
begin
wait for 10 ns;
clk <= not clk;
if Now > 720 ns then
wait;
end if;
end process;
STIMULUS:
process
begin
clr <= '0';
en <= '1';
wait for 20 ns;
clr <= '1';
wait for 20 ns;
wait for 20 ns;
wait for 20 ns;
wait for 20 ns;
wait for 20 ns;
en <= '0';
wait for 20 ns;
en <= '1';
wait;
end process;
end architecture;
Gives this:
The reason no end cases are necessary in the count arithmetic are due to how the unsigned "+" operator works, calling unsigned_add in the package body for numeric_std. End counts are something you need to worry about in scalar increments.
The purpose behind having count (mode out) and count_result, is to allow the count value to be read internally for versions of VHDL predating IEEE Std 1076-2008. For a -2008 compliant simulation you should be only using count. Note the above simulation shown will run on earlier versions of VHDL.
You could likewise make count_result a variable.
And I trust you're aware based on signal array sizes this is a 5 bit counter and not a 32 bit counter. Converting to the latter is relatively easy.
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.