I'm having an issue with this code. Theoretically it should turn my 50MHz sign into 36KHz but as i run the simulation it turns out that the ir_38khz doesn't get any value it is unassigned.
Can you help me where i slip?
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
use IEEE.NUMERIC_STD.all;
entity orajelKonverter is
Port ( clk50 : in STD_LOGIC;
rst : in STD_LOGIC;
ir_38khz : out STD_LOGIC);
end orajelKonverter;
architecture Behavioral of orajelKonverter is
signal hz38_ctr : STD_LOGIC_VECTOR(9 downto 0);
signal s38 : std_logic;
begin
clk_generator : process (clk50, rst)
begin
if rst = '1' then
s38 <= '0';
hz38_ctr <= (others => '0');
elsif clk50='1' then
if hz38_ctr = "1010010010" then
hz38_ctr <= (others => '0');
s38 <= not s38;
else
hz38_ctr <= hz38_ctr + "1";
end if;
end if;
end process clk_generator;
ir_38khz <= s38;
end Behavioral;
Here is the picture from the simulation:
You need to initialize your signals to some value OR assert your reset to initialize them in simulation. I personally prefer #1, since signal initial conditions are synthesizable, despite the relatively common misconception that they are not. As a matter of fact, I avoid resets in my designs unless I absolutely need to use them. This is actually recommended by Xilinx. So for example you can do:
signal s38 : std_logic := '0';
This will guarantee that when your simulation starts it knows what to do with the line:
s38 <= not s38;
Previously the simulator was trying to do not U which is U.
Related
i had a question about detecting a change on a std_logic_vector(4 downto 0).
Here is my code :
LIBRARY IEEE;
library work;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.NUMERIC_STD.ALL;
Entity CHANGE_CUR_GRP is
port(
MCLK : in std_logic;
RST_N : in std_logic;
CUR_GRP : in std_logic_vector(4 downto 0);
LOAD : out std_logic
);
end entity;
Architecture RTL of CHANGE_CUR_GRP is
signal grp : std_logic_vector(4 downto 0);
signal compare : std_logic_vector(4 downto 0);
begin
process(RST_N, MCLK)
begin
if(RST_N = '0') then
LOAD <= '0';
elsif(rising_edge(MCLK)) then
grp <= CUR_GRP;
end if;
end process;
LOAD <= '1' when compare = "00000" else '1';
compare <= grp xor CUR_GRP;
end Architecture;
But when i run my simulation i got a 'X' whine means that the signal has multiple drivers and i don't know why.
Thank you
LOAD does have multiple drivers. It is driven by the process (in the reset branch, which drives it to '0') and also in the one liner outside the process, that always drives it to '1'. Hence it will always be 'X'. You cannot assign it in both places.
To fix the problem, either remove the one liner assignment (which as #thebusybee already pointed out, looks like an error anyway) or remove the line LOAD <= '0'; from the reset branch.
Below is a counter that is designed to represent an 8 bit binary number with 8 LEDs, it is being simulated using a test bench, however when running the simulation the output simply shows UU for the led.
Here is the main entity that I wish to test:
use IEEE.STD_LOGIC_1164.all;
use IEEE.STD_LOGIC_unsigned.all;
entity Lab_3_Source_File is
generic(N_BITS : integer := 8);
port(
btnd : in STD_LOGIC ;
clk : in STD_LOGIC;
led : out STD_LOGIC_VECTOR(7 downto 0)
);
end Lab_3_Source_File;
architecture counter of Lab_3_Source_File is
signal count: STD_LOGIC_VECTOR(7 downto 0);
begin
process(clk, btnd)
begin
if btnd = '1' then
count <= (others => '0');
elsif rising_edge(clk) then
count <= count + 1;
end if;
end process;
led <= count;
end counter;
Here is the test bench that I have tried to map to the main entity:
use IEEE.STD_LOGIC_1164.ALL;
entity Count_TestBench is
end Count_TestBench;
architecture Behavioral of Count_TestBench is
signal btnd, clk : STD_LOGIC;
signal led : STD_LOGIC_VECTOR(7 downto 0);
begin
UUT : entity work.Lab_3_Source_File port map (btnd => btnd,clk => clk,led => led);
process
begin
btnd<='1';
wait for 1 ns;
btnd<='0';
led<= (others => '0');
for i in 1 to 100 loop
clk<='1';
wait for 10 ns;
clk<='0';
wait for 10 ns;
led<=led;
end loop;
end process;
end Behavioral;
Please could somebody help me understand how to enable the simulation to display the led output incrementing?
EDIT:
Set btnd to 1 with a 1ns wait in the test bench to initialise the led, following the answer from mkrieger1, the led output is still at U following this change.
count is not initialized inside Lab_3_Source_File until btnd is set to '1', which it isn't in the testbench.
Since the led output is driven by count, it is also uninitialized. The uninitialized value of the led output of Lab_3_Source_File is then assigned to the led signal in the testbench.
So, to fix this, you need to set btnd to '1' once for a non-zero duration in the testbench, before setting it to '0' again (otherwise led is held at "00000000" constantly).
I want to detect a external signal connection to a CPLD (only connected or not connected). My system clock is 1MHz and external signal is 4KHz. I have developed a logic that will detect rising edge of external signal and start a counter. If the counter is counting then external signal is connected and if the counter is not counting then external signal is not connected. I write the code but its not working, what is the problem? I am beginner in VHDL. Please help, How to check a counter running in vhdl?
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity SYNC_detection1 is
Port ( SYNC : in STD_LOGIC;
CLK : in STD_LOGIC;
EDGE : out STD_LOGIC;
OUTPUT : out STD_LOGIC;
BITSOUT : out STD_LOGIC_VECTOR (3 downto 0)
);
end SYNC_detection1;
architecture workingarchi of SYNC_detection1 is
signal SYNC_reg : std_LOGIC := '0';
signal SYNC_edge : std_LOGIC := '0';
signal TEMP : std_LOGIC := '0';
signal counter : STD_LOGIC_VECTOR (3 downto 0);
begin
SYNC_edge_p : process(CLK)
begin
if (rising_edge(CLK)) then
SYNC_reg <= SYNC;
end if;
end process;
SYNC_edge <= not SYNC_reg and SYNC;
counter_p: process(CLK)
begin
if (rising_edge(CLK)) then
if SYNC_edge = '1' then
counter <= counter + 1;
if (counter = "0000") then
TEMP <= '1';
end if;
end if;
end if;
end process;
OUTPUT <= TEMP;
BITSOUT <= counter;
EDGE <= SYNC_edge;
end workingarchi;
If you just want to check that the counter is running and you don't want to write a testbench, which you should do by the way, you can put an if condition that if the counter equals to 1, then turn a led on in your board. something like this:
if counter = "0001" then
led <= '1';
end if;
if the led is ON then you counter is running.
first of all, you are managing an external clock and want to process it with your 1MHz internal clock, for this application you must use a synchronization block.
I will proceed as follow.
Manage the external SYNC signal as a clock, and use it to count the rising_edge,
another tips is to avoid std_logic_vector to count (using integer to count get the code more readable)
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
entity SYNC_detection1 is
Port ( SYNC : in STD_LOGIC;
EDGE : out STD_LOGIC;
OUTPUT : out STD_LOGIC;
BITSOUT : out STD_LOGIC_VECTOR (3 downto 0)
);
end SYNC_detection1;
architecture workingarchi of SYNC_detection1 is
signal SYNC_edge : std_LOGIC := '0';
signal TEMP : std_LOGIC := '0';
signal counter : integer := 0;
begin
SYNC_edge_p : process(SYNC)
begin
SYNC_edge <= '0';
if (rising_edge(SYNC)) then
counter <= counter + 1;
SYNC_edge <= '1';
if (counter = 0) then
TEMP <= '1';
end if;
end if;
end process;
OUTPUT <= TEMP;
BITSOUT <= std_logic_vector(to_unsigned(counter, BITSOUT'length));
EDGE <= SYNC_edge;
end workingarchi;
With this implementation you now have your output signals in the 4KHz clock domain,
you just need to add a synchronization block for each output line with source clock 4KHz and destination clock 1MHz.
For the synchronization block just as reference I write the following block that is able to synchronize an edge:
library ieee;
use ieee.std_logic_1164.all;
entity edge_sync is
port(
data : in std_logic;
clk_src : in std_logic;
clk_dst : in std_logic;
line_out: out std_logic
);
end edge_sync;
architecture beha of edge_sync is
component ff_D is
port(
lineD : in std_logic;
clk : in std_logic;
lineQ : out std_logic
);
end component ff_D;
signal input_s : std_logic := '0';
signal meta : std_logic:= '0';
signal Q2_D3 : std_logic:= '0';
signal Q3 : std_logic:= '0';
begin
FFsrc : ff_D port map (
lineD => input_s,
clk => clk_src,
lineQ => meta
);
FFdst1 : ff_D port map(
lineD => meta,
clk => clk_dst ,
lineQ => Q2_D3
);
FFdst2 : ff_D port map(
lineD => Q2_D3,
clk => clk_dst ,
lineQ => Q3
);
input_s <= data;
line_out <= (not Q3) and Q2_D3;
end beha;
But on line you can find other implementations.
From your code:
SYNC_edge <= not SYNC_reg and SYNC;
This line could work only if SYNC changes between CLK rising edges.
Are you sure you are not generating the 2 clock synchronously? If the 2 clocks
are generated with 0 phase since they are multiple you'll never get an edge between the CLK rising edges, as consequences you don't see SYNC_edge change.
PS
You are facing with two main fpga subjects, clock domain crossing and metastability management, I suggest you to study theory material about these arguments.
It can help you to focus on hardware aspects as well as VHDL coding.
Regards
I have the VHDL implementation that works on board, it detects the sequence 01110 and will raise a flag for 2 clock counts. It detects overlapping sequences as well where 011101110 would raise the flag twice.
I've checked my implementation with a logic analyzer on the board and am fairly confident that it works. I am feeding in a repetition sequence of 0111 at 10 kHz, on the board, it has a clock at 100 MHz where I scale it to 10 kHz with a prescaler.
My problem is, when trying to recreate a similar scenario using a simulation, I do not get any outputs as expected
Image from logic analyzer from board
Image from Test Bench
Test Bench Code
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity test_FSM_prac4 is
-- Port ( );
end test_FSM_prac4;
architecture Behavioral of test_FSM_prac4 is
component FSM_prac4 is
port (
inputSignal : in STD_LOGIC;
pushButton : in STD_LOGIC;
clk100mhz : in STD_LOGIC;
logic_analyzer : out STD_LOGIC_VECTOR (7 downto 0);
LEDs: out STD_LOGIC
); end component;
signal inputSignal : std_logic := '0';
signal pushButton: std_logic := '0';
signal clk100mhz: std_logic := '0';
signal logic_analyzer: std_logic_vector(7 downto 0);
signal LEDs : std_logic;
begin
uut : FSM_prac4 port map(
inputSignal => inputSignal,
pushButton => pushButton,
clk100mhz => clk100mhz,
logic_analyzer => logic_analyzer,
LEDs => LEDs
);
--generate clock 100mhz
clock_tic: process begin
loop
clk100mhz <= '0';
wait for 5ns;
clk100mhz <= '1';
wait for 5ns;
end loop;
end process;
input_changes: process begin
loop
inputSignal <= '0';
wait for 100us;
inputSignal <= '1';
wait for 100us;
inputSignal <= '1';
wait for 100us;
inputSignal <= '1';
wait for 100us;
end loop;
end process;
end Behavioral;
To show the mapping for logic Analyzer
logic_analyzer(0) <= masterReset;
logic_analyzer(1) <= newClock -- 10Khz Clock;
logic_analyzer(2) <= outputZ;
--FSM States
logic_analyzer(3) <= '1' when y = A ELSE '0';
logic_analyzer(4) <= '1' when y = B ELSE '0';
logic_analyzer(5) <= '1' when y = C ELSE '0';
logic_analyzer(6) <= '1' when y = D ELSE '0';
logic_analyzer(7) <= '1' when y = E ELSE '0';
If anyone could direct to what I am doing wrong on the test bench and how to replicate to get similar results as the first image as it shows that in simulation, it always stays at state A and the new clock is not toggling meaning that clk100mhz is somehow not connected but I can't figure out why.
Any help is greatly appreciated, thanks guys
edit:
I wrote a simple program to test my scalar clock
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity scaler_clk is
Port (
pushButton : in std_logic;
indicator : out std_logic;
clk100mhz : in STD_LOGIC;
clk10khz: out STD_LOGIC
);
end scaler_clk;
architecture Behavioral of scaler_clk is
signal clockScalers : std_logic_vector (12 downto 0):= (others => '0') ;
signal prescaler: std_logic_vector(12 downto 0) := "1001110001000";
signal newClock: std_logic := '0';
signal masterReset : std_logic;
begin
clk10khz <= newClock;
masterReset <= pushButton;
process (clk100mhz,masterReset) begin
if(masterReset <= '1') then <--- error occurs here
clockScalers <= "0000000000000";
newClock <= '0';
indicator <= '1';
elsif (clk100mhz'event and clk100mhz = '1')then
indicator <= '0';
clockScalers <= clockScalers + 1;
if(clockScalers > prescaler) then
newClock <= not newClock;
clockScalers <= (others => '0');
end if;
end if;
end process;
end Behavioral;
test bench code
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity test_scaler_clk is
-- Port ( );
end test_scaler_clk;
architecture Behavioral of test_scaler_clk is
component scaler_clk Port (
pushButton : in std_logic;
indicator : out std_logic;
--input clock
clk100mhz : in STD_LOGIC;
clk10khz: out STD_LOGIC
);end component;
signal clk100mhz: std_logic := '0';
signal clk10khz : std_logic;
signal pushButton: std_logic;
signal indicator : std_logic;
begin
uut: scaler_clk port map(
pushButton => pushButton,
indicator => indicator,
clk100mhz => clk100mhz,
clk10khz => clk10khz
);
pushButton <= '0';
clock_tic: process begin
loop
clk100mhz <= '0';
wait for 5ns;
clk100mhz <= '1';
wait for 5ns;
end loop;
end process;
end Behavioral;
Even though I set pushButton to '0', it is still triggering masterReset, anyone knows why, that's why the 10 kHz clock isn't working
There are several things that you could (should) improve in your code. As Brian already explained, in your Behavioral architecture of scaler_clk, you should have:
if(masterReset = '1') then
instead of:
if(masterReset <= '1') then
Now, let's start with the most likely cause of your initial problem: unbound components. Your test benches instantiate the design to validate as components. VHDL components are kind of prototypes of actual entities. Prototypes are enough to compile because the compiler can perform all necessary syntax and type checking. But they are not enough to simulate because the simulator also needs the implementation behind the prototype. Some tools have a default binding strategy for unbound components: if they find an entity with the same name and if it has only one architecture, they use that. Your simulator apparently does not use such strategy (at least not by default, there is maybe an option for that but it is disabled). Note that most simulators I know issue warnings when they find unbound components. You probably missed these warnings.
Anyway, your component instances are unbound (they have no associated entity/architecture) and the simulator considers them as black boxes. Their outputs are not driven, except by the initial values you declared (1).
How to fix this? Two options:
Use a configuration to specify which entity/architecture pair shall be used for each component instance:
for all: scaler_clk use entity work.scaler_clk(Behavioral);
Use entity instantiations instead of components:
uut: entity work.scaler_clk(Behavioral) port map...
Now, let's go through some other aspects of your code that could be improved:
You are using non-standard packages, that are frequently not even compatible: IEEE.STD_LOGIC_ARITH and IEEE.STD_LOGIC_UNSIGNED. As they are not standard they should not even be in the standard IEEE library. You should use IEEE.NUMERIC_STD instead, and only that one. It declares the SIGNED and UNSIGNED types (with the same declaration as STD_LOGIC_VECTOR) and overloads the arithmetic operators on them.
Your test benches generate the 100MHz clock with:
clock_tic: process begin
loop
clk100mhz <= '0';
wait for 5ns;
clk100mhz <= '1';
wait for 5ns;
end loop;
end process;
The infinite loop is useless: a process is already an infinite loop:
clock_tic: process
begin
clk100mhz <= '0';
wait for 5ns;
clk100mhz <= '1';
wait for 5ns;
end process clock_tic;
would do the same. Same remark for your input_changes process.
Your input_changes process uses wait for <duration> statements. This is not a good idea because you do not know when the inputSignal signal toggles, compared to the clock. Is it just before, just after or exactly at the same time as the rising edge of clk100mhz? And if it is exactly at the same time, what will happen? Of course, you can carefully chose the <durations> to avoid such ambiguities but it is error prone. You should use the wait for <duration> only in the clock generating process. Everywhere else, it is better to synchronize with the clock:
input_changes: process
begin
inputSignal <= '0';
for i in 1 to 10000 loop
wait until rising_edge(clk100mhz);
end loop;
inputSignal <= '1';
for i in 1 to 10000 loop
wait until rising_edge(clk100mhz);
end loop;
inputSignal <= '1';
for i in 1 to 10000 loop
wait until rising_edge(clk100mhz);
end loop;
inputSignal <= '1';
for i in 1 to 10000 loop
wait until rising_edge(clk100mhz);
end loop;
end process input_changes;
This guarantees that inputSignal changes just after the rising edge of the clock. And you could rewrite it in a bit more elegant way (and probably a bit easier to maintain):
input_changes: process
constant values: std_logic_vector(0 to 3) := "0111";
begin
for i in values'range loop
inputSignal <= values(i);
for i in 1 to 10000 loop
wait until rising_edge(clk100mhz);
end loop;
end loop;
end process input_changes;
You are using resolved types (STD_LOGIC and STD_LOGIC_VECTOR). These types allow multiple drive, that is, having a hardware wire (VHDL signal) that is driven by several devices (VHDL processes). Usually you do not want this. Usually you even want to avoid this like the plague because it can cause short-circuits. In most cases it is wiser to use non-resolved types (STD_ULOGIC and STD_ULOGIC_VECTOR) because the compiler and/or the simulator will raise errors if you accidentally create a short circuit in your design.
One last thing: if, as its name suggests, you intend to use the clk10khz signal as a real clock, you should reconsider this decision. It is a signal that you generate with your custom logic. Clocks have very specific electrical and timing constraints that cannot really be fulfilled by regular signals. Before using clk10khz as a clock you must deal with clock skew, clock buffering... Not impossible but tricky. If you did use it as a clock your synthesizer probably issued critical warnings that you also missed (have a look maybe at the timing report). Moreover, this is probably useless in your case: an enable signal generated from clk100mhz could probably be used instead, avoiding all these problems. Instead of:
process (clk100mhz,masterReset) begin
if(masterReset = '1') then
clockScalers <= "0000000000000";
newClock <= '0';
indicator <= '1';
elsif (clk100mhz'event and clk100mhz = '1')then
indicator <= '0';
clockScalers <= clockScalers + 1;
if(clockScalers > prescaler) then
newClock <= not newClock;
clockScalers <= (others => '0');
end if;
end if;
end process;
use:
signal tick10khz: std_ulogic;
...
process(clk100mhz, masterReset) begin
if masterReset = '1') then
clockScalers <= "0000000000000";
tick10khz <= '0';
elsif rising_edge(clk100mhz) then
clockScalers <= clockScalers + 1;
tick10khz <= '0'
if(clockScalers > prescaler) then
tick10khz <= '1';
clockScalers <= (others => '0');
end if;
end if;
end process;
And then, instead of:
process(clk10khz)
begin
if rising_edge(clk10khz) then
register <= register_input;
end if;
end process;
use:
process(clk100mhz)
begin
if rising_edge(clk100mhz) then
if tick10khz = '1' then
register <= register_input;
end if;
end if;
end process;
The result will be the same but with only one single 100MHz clock, which avoids clock skew, clock buffering and clock domain crossing problems.
(1) This illustrates why declaring variables and signals with initial values is usually not a good idea: it hides potential problems. Without this your signals would have been stuck at 'U' (uninitialized) and it would maybe have helped understanding where the problem comes from.
I am new to VHDL and trying to make a delay/gate application for programmable FPGA, with adjustable lenght of delay and gate output. As soon as the input signal is recieved, the thing should ignore any other inputs, until generating of gate signal is finished.
I want to use this component for 8 different inputs and 8 different outputs later, and set desired delay/gate prameters separately for each one by means of writing registers.
When trying to compile in Quartus II v 11.0 i am getting this error:
Error (10821): HDL error at clkgen.vhd(46): can't infer register for "control_clkgen" because its behavior does not match any supported register model
And as well
Error (10822): HDL error at clkgen.vhd(37): couldn't implement registers for assignments on this clock edge
No idea whats wrong, here is the code of the component:
library ieee;
use IEEE.Std_Logic_1164.all;
use IEEE.Std_Logic_arith.all;
use IEEE.Std_Logic_unsigned.all;
ENTITY clkgen is
port(
lclk : in std_logic;
start_clkgen : in std_logic;
gate_clkgen : in std_logic_vector(31 downto 0);
delay_clkgen : in std_logic_vector(31 downto 0);
output_clkgen : out std_logic
);
END clkgen ;
ARCHITECTURE RTL of clkgen is
signal gate_cycles_clkgen : std_logic_vector(32 downto 0);
signal delay_cycles_clkgen : std_logic_vector(32 downto 0);
signal total_cycles_clkgen : std_logic_vector(32 downto 0);
signal counter_clkgen : std_logic_vector(32 downto 0);
signal control_clkgen : std_logic;
begin
gate_cycles_clkgen <= '0' & gate_clkgen;
delay_cycles_clkgen <= '0' & delay_clkgen;
total_cycles_clkgen <= gate_cycles_clkgen + delay_cycles_clkgen;
start_proc: process(lclk, start_clkgen)
begin
if (start_clkgen'event and start_clkgen = '1') then
if control_clkgen = '0' then
control_clkgen <= '1';
end if;
end if;
if (lclk'event and lclk = '1') then
if control_clkgen = '1' then
counter_clkgen <= counter_clkgen + 1;
if (counter_clkgen > delay_cycles_clkgen - 1 AND counter_clkgen < total_cycles_clkgen + 1) then
output_clkgen <= '1';
elsif (counter_clkgen = total_cycles_clkgen) then
counter_clkgen <= (others => '0');
output_clkgen <= '0';
control_clkgen <= '0';
end if;
end if;
end if;
end process start_proc;
END RTL;
Big thanks in advance for help.
The problem is that in the way you has described the element control_clkgen - it is edge sensitive to two different signals (lclk, and start_clkgen). What the tools are telling you is that "hey, as I am trying to make your valid VHDL design fit into a real piece of hardware, I have found that there are not any pieces of hardware that can implement what you want. Basically, there are no flip flops that can be edge sensitive to two signals (only one, typically the clock.
Possible solution: Do you really need control_clkgen to be sensitive to the edge of start_clkgen? Would it be good enough, or could you find another solution where start_proc is sensitive only to lclk and you simply check if start_clkgen is high?
start_proc: process(lclk)
begin
if (rising_edge(lclk)) then
start_clkgen_d <= start_clkgen;
if (start_clkgen='1' and start_clkgen_d='0') then
if control_clkgen = '0' then
control_clkgen <= '1';
end if;
end if;
end if;
...
You are describing a register control_clkgen which has two clocks start_clkgen and lclk. I guess that's not supported by your synthesis tool.
You have to describe this behavior in another way. Maybe use start_clkgen as asynchronous or synchronous preset signal or combine those two signals into one single clock signal or use more than one flipflop for that functionality.