I want to write in VHDL a general clock divider like this:
entity Generic_Clk_Divider is
Generic(
INPUT_FREQ: integer := 100;
OUTPUT_FREQ: integer := 25;
);
Port (
Clk: in std_logic;
Rst: in std_logic;
Generated_Clk: out std_logic
);
end entity;
architecture Behavioral of Generic_Clk_Divider is
signal Cnt: integer := 0;
signal Gen_Clk : std_logic := '0';
constant MaxCnt: integer := (integer (INPUT_FREQ/OUTPUT_FREQ)) - 1;
begin
process(clk, Rst)
begin
if (Rst = '1') then
Cnt <= 0;
elsif rising_edge(Clk) then
Cnt <= Cnt + 1 ;
if (Cnt = MaxCnt) then
Gen_Clk <= not Gen_Clk;
Cnt <= 0;
end if;
end if;
Generated_Clk <= Gen_Clk;
end process;
end architecture;
It works if I test it with a test bench but it is not working if I use the generated Clk singal with another component (VGA controller in this case) if I but it on a board. My question is about that division between 2 integers, th board seems not to recognize it.
Integer/ Integer, returns an integer, with the remainder discarded. So for situations where INPUT/OUTPUT are integer multiples of each other, this is fine. But otherwise, it won't work.
eg.
200/75 = 2
150/40 = 3
etc.
The only way this is really going to work is with real types so you can find the fractional relationships, and then use a much larger counter value to get exact relationships.
But, this isnt really going to help at all, as clock dividers like this are highly discouraged. Logic generated clocks make timing analysis difficult and cause timing problems. It is much safer to use a real clock and generate clock enables instead.
Related
I am a novice coder and don't know if what I did was correct so I would appreciate if someone could double check it for me.
So im trying to make an 8-bit up counter with an active-low count enable control signal. The counter should advance to the next count if cten = 0 and stops at the current count if cten = 1. The counter resets into a state that outputs binary 0 and progresses upward on each clock edge when counting is enabled until it reaches 255. It locks in the state producing output 255. I also tried to change the clock to 1Hz clock from a 50MHz clock the is on a FPGA board that will be used to run some instructions (with there being no more than 255 instructions, hence wanting to lock at that number) based off the count value of int_q.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;
entity counter is
port(
clk, rst, cten: in std_logic;
q: out std_logic_vector(7 downto 0)
);
end entity counter;
architecture moore of counter is
signal d,int_q: std_logic_vector(7 downto 0);
signal cnt: integer range 0 to 25000;
signal clk1Hz: std_logic;
begin
-- drive internal Q signal to output signal
q <= int_q;
-- next-state logic: add 1 unless 255, lock at 255
d <= int_q+1 when int_q < 255;
d <= int_q when int_q = 255;
process(clk)
begin
if rising_edge(clk) then
cnt <= cnt+1;
if cnt = 25000 then
clk1Hz <= not clk1Hz;
cnt <= 0;
end if;
end if;
end process;
-- register process
process(all)
begin
if rising_edge(clk1Hz) then
if rst ='1' then int_q <= "00000000";
elsif cten = '0' then int_q <= int_q+1;
else int_q <= int_q;
end if;
end if;
end process;
end architecture moore;
Several issues:
If rst is unasserted on the rising edge of clk1Hz, then int_q will remain in an unknown state.
clk1Hz is never initialized, so the not operation does nothing.
cnt is never initialized, so incrementing it does nothing.
int_q is being driven in 2 places: both inside and outside a process.
signal d is unused, did you want to connect it to q?
You're only counting to 25_000, but if your source clock is 50 MHz, you need to count to 25_000_000.
If you want a synchronous reset, (which given the name "Moore", I bet this is homework), it's good practice to create a new process specifically to internally synchronize that async reset signal to the system clock, maybe through a 2FF synchronizer for one idea.
If I understood the question correctly, this should get you in the ballpark:
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;
entity counter is
port(
clk, rst, cten: in std_logic;
q: out std_logic_vector(7 downto 0)
);
end entity counter;
architecture moore of counter is
signal int_q: std_logic_vector(7 downto 0);
signal cnt: integer range 0 to 25_000_000;
signal clk1Hz: std_logic;
begin
-- indicate when at 255
q <= '1' when int_q = 255 else '0';
process(rst, clk)
begin
if rst = '1' then
-- need to assign initial values
clk1Hz <= '0';
cnt <= 0;
elsif rising_edge(clk) then
if cnt = 25_000_000 then
clk1Hz <= not clk1Hz;
cnt <= 0;
else
cnt <= cnt+1;
end if;
end if;
end process;
-- register process
process(rst, clk1Hz)
begin
if rst = '1' then
int_q <= (others => '0');
elsif rising_edge(clk1Hz) then
if cten = '0' then
int_q <= int_q+1; -- rolls over
end if;
end if;
end process;
end architecture moore;
If you want to map this in an FPGA you cannot generate a clock like you do. Clocks are very special signals with strict electrical requirements. If you need a 1Hz frequency clock and the frequency of your master clock is 50MHz there are basically two options:
Use a clock manager/generator hard macro of your FPGA if it has some, and configure it to generate a 1Hz clock from your master clock. Explicitly pass the output through a clock buffer if your tools don't do it automatically.
Do not generate a 1Hz clock, use an enable signal that you assert high once every 50M clock periods. Or use a rescaler and increment your counter only when the rescaler reaches a predefined value.
As the first option depends on your FPGA, your tools, etc. let's investigate the second:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity counter is
generic(freqHz: positive := 50000000);
port(clk, rst, cten: in std_ulogic;
q: out std_ulogic_vector(7 downto 0));
end entity counter;
architecture moore of counter is
signal rescaler: integer range 0 to freqHz - 1;
signal cnt: integer range 0 to 255;
begin
q <= std_ulogic_vector(to_unsigned(cnt, 8));
process(clk)
begin
if rising_edge(clk) then
if rst = '1' then
rescaler <= freqHz - 1;
cnt <= 0;
elsif cnt /= 255 then
if rescaler /= 0 then
rescaler <= rescaler - 1;
else
rescaler <= freqHz - 1;
cnt <= cnt + 1;
end if;
end if;
end if;
end process;
end architecture moore;
Remarks:
Use ieee.std_logic_unsigned or ieee.numeric_std but not both. And as noted by #JHBonarius, do not use ieee.std_logic_unsigned at all. It is not standard and deprecated. Use ieee.numeric_std_unsigned, instead.
I added a generic parameter (freqHz) with a default value such that you can easily adapt to different clock frequencies.
The 50Mhz to 1Hz rescaler is decremented instead of incremented because a hardware zero detector is frequently slightly smaller and faster than an arbitrary value detector.
If you do not know the difference between std_logic and std_ulogic, always use std_ulogic, never std_logic (and use std_ulogic_vector instead of std_logic_vector, u_unsigned instead of unsigned...) One day or another you will really need std_logic and this day you will understand the difference, and why you should (almost) never use it. And do not listen to people who tell you that std_logic is more standard or better supported by the tools or whatever. They are wrong. The only exception is your teacher or your boss: even if they are wrong, it might be better to obey.
I had written a small VHD file for simulating the behavior of a quadrature decoder, enclosed below. Simulating the design with a generic testbench works as expected. But after generating a synthesizable design with Quartus, I run into one of two problems (while playing with using unsigned, for example)
1. The position and direction signal are always at a constant 0 value throughout the post-synthesis simulation.
2. The position value seems to jump 10 values every 3-4 clock cycles, which I attribute to some jitter in data.
Does anyone have any recommendations to solve this issue? Is this mainly a timing problem or is there a major flaw in my design?
LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
USE ieee.NUMERIC_STD.ALL;
entity quad_decoder is
port(rst : in std_logic;
clk : in std_logic;
a : in std_logic;
b : in std_logic;
direction : out std_logic;
position : out std_logic_vector(8 DOWNTO 0));
end quad_decoder;
architecture behavioral of quad_decoder is
begin
process(clk)
variable counter : integer range 0 to 360 := 0;
variable chanA,chanB : std_logic;
variable int_direction : std_logic;
begin
if (rst = '0') then
int_direction := '0';
counter := 0;
elsif (rising_edge(clk)) then
chanA := a;
chanB := b;
if (chanA = '1') and (chanB = '0') then
if (counter = 360) then
counter := 0;
else
counter:= counter + 1;
end if;
int_direction := '1';
elsif (chanA = '0') and (chanB = '1') then
if (counter = 0) then
counter := 360;
else
counter := counter-1;
end if;
int_direction := '0';
else
counter := counter;
int_direction := int_direction;
end if;
position <= std_logic_vector(to_unsigned(counter,9));
direction <= int_direction;
end if;
end process;
end behavioral;
The expected pre-synthesis snap is here.
I've linked an example snap of the post-synthesis simulation here. As seen, no change to position nor direction in multiple clock cycles.
If anyone is inquisitive, doing assignments right at the clock edge as well as turning the reset signal high proved to introduce all kinds of timing issues, which passed the multi-corner timing analysis test, but failed other tests in Quartus that I had failed to notice.
I can go into more details if my answer is vague.
I recently have been designing a clock divider for my system - which I redesigned, and now has an asynchronous reset, which generates a synchronous reset for the rest of the system. To do this, I followed the answers & advice to my own question and used a clock enable to toggle an output, thus generating clock with a 50% duty cycle (which is desired).
However, this has thrown up the error when generating the bitstream of
PhysDesignRules:372 - Gated clock. Clock net ... is sourced by a combinatorial pin. This is not good design practice. Use the CE pin to control the loading of data into the flip-flop.
Reading into this question about using the clock enable, it appears when creating a clock enable is correct, however, because I need a square wave (and not just a 1/200MHz pulse), and thus using the enable to toggle another signal, it appears in this question that this is an intentional gated clock.
So my questions are; is this gated clock warning significant? Both in simulation, and on an oscilloscope it appears to function correctly (so I'm inclined to ignore it), but am I storing problems for later? Is there a way of getting a very slow 50% duty cycle pulse without a gated clock?
I've put my code below!
Thanks very much (especially to the handful of people who have collectively given a lot of time to my recent non-stop questions)
David
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
library UNISIM;
use UNISIM.VComponents.all;
ENTITY CLK_DIVIDER IS
GENERIC(INPUT_FREQ : INTEGER;
OUT1_FREQ : INTEGER;
OUT2_FREQ : INTEGER
);
PORT(SYSCLK : IN STD_LOGIC;
RESET_N : IN STD_LOGIC;
RESET_N_OUT : OUT STD_LOGIC;
OUT1 : OUT STD_LOGIC;
OUT2 : OUT STD_LOGIC);
END CLK_DIVIDER;
architecture Behavioral of Clk_Divider is
constant divider1 : integer := INPUT_FREQ / OUT1_FREQ / 2;
constant divider2 : integer := INPUT_FREQ / OUT2_FREQ / 2;
signal counter1 : integer := 0;
signal counter2 : integer := 0;
signal output1 : std_logic := '0';
signal output2 : std_logic := '0';
signal reset : boolean;
begin
reset_proc : process(RESET_N, SYSCLK)
variable cycles : integer := 0;
variable reset_counter : integer := 0;
begin
if rising_edge(SYSCLK) then
if cycles < 2 then
if reset_counter >= divider1 then
cycles := cycles + 1;
reset_counter := 0;
else
reset_counter := reset_counter + 1;
end if;
reset <= true;
else
reset <= false;
end if;
end if;
if RESET_N = '0' then
cycles := 0;
reset_counter := 0;
reset <= true;
end if;
end process;
output1_proc : process(SYSCLK)
begin
if rising_edge(SYSCLK) then
if counter1 >= divider1 - 1 then
output1 <= not output1;
counter1 <= 0;
else
counter1 <= counter1 + 1;
end if;
if RESET_N = '0' then
counter1 <= 0;
output1 <= '1';
end if;
end if;
end process;
output2_proc : process(SYSCLK)
begin
if rising_edge(SYSCLK) then
if counter2 >= divider2 - 1 then
output2 <= not output2;
counter2 <= 0;
else
counter2 <= counter2 + 1;
end if;
if RESET_N = '0' then
counter2 <= 0;
output2 <= '1';
end if;
end if;
end process;
OUT1 <= output1;
OUT2 <= output2;
RESET_N_OUT <= '0' when reset else '1';
end Behavioral;
The comments suggest, that the clock-divider is instantiated in a larger design.
If you want to use the generated clock there, you must add a BUFG between signal output2 and the output out2 like this:
out2_bufg : BUFG port map(I => output2, O => out2);
The component BUFG is defined in the library unisim.vcomponents. Same applies to output out1.
The BUFG ensures, that the generated clock is distributed using a clock-tree, so that the clock signal arrives at all destination flip-flops at the same time. This minimizes hold-time violations and gives more room for the setup of data signals.
If you still get the warning/error, then you combined the generated clock signal with another signal elsewhere in the larger design.
The reset_proc process is written with a elsif cycles > 1 then outside the clocked part, and with the condition derived from cycles which is also assigned as part of reset. It is unclear what hardware is actually described here, but it makes the synthesis tool unhappy.
If you want to use RESET_N as asynchronous reset, then just make a simple if RESET_N = '0' then ... end if;, and assign whatever signals or variables required to be reset. Other assignments should be moved to the clocked part.
NOTE: Code was changed after the above update... which may have removed the reason for the question.
Btw. RESET_N is used as asynchronous reset in the reset_proc, but as synchronous reset in the other processes, and this inconsistent use looks like there may be a potential problem with the reset scheme.
I need to share a value (a real) between two process, but when I try to run my code, quartus gives me an error.
library IEEE;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_arith.all;
USE ieee.std_logic_unsigned.all;
use IEEE.MATH_REAL.ALL;
entity de0nano is
port (
CLOCK_50 : in std_logic;
KEY : in std_logic_vector(1 downto 0);
SW : in std_logic_vector(3 downto 0);
LED : out std_logic_vector(7 downto 0);
GPIO : inout std_logic_vector(35 downto 0)
);
end de0nano;
architecture struct of de0nano is
--declarations
signal PN : real :=0.0 ;
signal PR : real :=0.0 ;
signal RC : integer :=1;
signal NC : integer :=1;
signal BET : integer :=1;
begin
count : process (CLOCK_50, GPIO)
begin
--A <= KEY(0);
GPIO(24) <= '1';
--functional coding
LED <= "00011000";
if (pn > pr) then
GPIO(26) <= '1';
LED <= "00000001";
else
GPIO(26) <= '0';
end if;
if (pn = pr) then
GPIO(26) <= '1';
LED <= "00000010";
else
GPIO(26) <= '0';
end if;
if (pn < pr) then
GPIO(26) <= '1';
LED <= "00000011";
else
GPIO(26) <= '0';
end if;
end process;
probabilityController : process (CLOCK_50, KEY)
begin
--stato iniziale
if((RC + NC + BET)=1) then
pr <= 0.5;
pn <= 0.5;
end if;
--sequenza rossi consecutivi
if(RC>0) then
pr <= (5)**RC;
pn <= 1- (5)**RC;
end if;
--sequenza neri consecutivi
if(NC>0) then
pr <= (5)**NC;
pn <= 1- (5)**NC;
end if;
end process;
betController : process (CLOCK_50)
begin
end process;
colorController : process (CLOCK_50, KEY)
begin
if(KEY(0)='1') then
NC<=0;
RC <= RC+1;
end if;
if(KEY(1)='1') then
RC<=0;
NC <= NC+1;
end if;
end process;
end str
How can I operate in the same signal/variable from two different processes?
VHDL is a hardware description language. A VHDL description can be simulated (executed a bit like you do with most programming languages) or synthesized (transformed in a network of interconnected simple hardware elements). Some tools are pure simulators (Mentor Graphics Modelsim, Cadence ncsim...), others are pure synthesizers (Mentor Graphics Precision RTL, Cadence RTL compiler...) and others can do both. Quartus pertains to the last category. So, the first thing to do is to decide whether you want to simulate, synthesize or both.
In case you want to simulate you must fix three errors:
the position of your signal declaration,
the way you assign it (:=) which is the variable assignment operator, not the signal assignment (<=)
and the fact that you drive it from two processes while it is of an unresolved type (real). See this other answer for resolved / unresolved VHDL types.
Your code could then look like this (but as I do not know what you are trying to do, it is probably not what you want):
architecture V1 of AOI is
Signal foobar : real := 0.0;
begin
OneTwo : process (clk)
Begin
Foobar <= foobar + 2.0;
End process;
end V1;
If you want to synthesize you will have to fix a few more problems:
You are using the real type which is the floating point VHDL type. This is not synthesizable by the synthesizers I know. Indeed, what would you expect the synthesizer to do? Instantiate a complete floating point unit? What brand? So, you will have to replace real by some other type (integers, bit vectors...).
You are assigning your signal on both edges of what I believe is your clock (clk). This is probably not what you want.
You are initializing the signal at declaration time. This is usually not synthesizable by the synthesizers I know. In fact this initialization time has a clear meaning for simulation: it is the beginning of the simulation. But what about hardware? What is the beginning of a piece of hardware? Manufacturing? Power up? So, if you want the signal to be initialized at some point you will have to add a hardware reset, driven by a reset input.
All in all you could have something like:
architecture V1 of AOI is
Signal foobar : natural range 0 to 255;
begin
OneTwo : process (clk)
Begin
if rising_edge(clk) then
if reset = '1' then
foobar <= 0;
else
foobar <= foobar + 2;
end if;
end if;
End process;
end V1;
Notes:
VHDL is case insensitive but you should try to be consistent, it will help you.
You should probably take a VHDL course or read a VHDL primer before trying to use the language. It is radically different from the programming languages you already know. Hardware and software are pretty different worlds, even if they are strongly connected at the end.
I'm new to VHDL, Quartus II and ModelSim. Now I'm doing a lab where we are constructing a blinking LED. How should simulation be handled when the construction deals with relatively long time periods. The frequency of the blinking LED is 1 Hz and the clock on the dev board I'm using (Terasic DE2-115) is 50 MHz. In the code I'm counting the clock pulses and turn on the LED accordingly. However, when I want to verify my code with ModelSim, I get in to troubles dealing with times as long as seconds. So I solved it just by changing the period in the code to a couple of clock cycles to see that the waves behave as expected. For final compilation, I just change the count value that corresponds to 1 second.
But there should be a better way. I don't really want to touch the VHDL code after simulation. Should I use two rtl's, one for synthesis and one for simulation when dealing with time periods approaching 1 ms and higher?
The VHDL code
library ieee;
use ieee.std_logic_1164.all;
entity lab4 is
port( CLOCK_50 : in std_logic; -- DE2-115 internal clock
KEY : in std_logic_vector(0 downto 0); -- Push-buttons, active 0
-- KEY(0) as reset
LEDG : out std_logic_vector(7 downto 0)); -- Green LEDs
end entity lab4;
architecture lab4_rtl of lab4 is
signal RESET_N : std_logic;
begin
-- Parallel VHDL
constant CLK_FRQ : integer := 50000000;
RESET_N <= KEY(0); -- Here we connect reset to a push-button
-- synch process with asynch reset, i.e. reset as soon as reset is active
p1 : process(CLOCK_50, RESET_N)
variable counter : integer := 0;
variable led_num : integer := 0;
begin
-- reset part
if RESET_N = '0' then --KEY is active 0
counter := 0; --reset counter
LEDG(0) <= '0'; --turn OFF leds
-- synch part, updates depending on clock
elsif rising_edge(CLOCK_50) then
counter := counter + 1;
if counter < 50000000 then;
LEDG(0) <= '1';
elsif counter >= 50000000 AND counter < 100000000 then
LEDG(0) <= '0';
else
counter := 0;
end if;
end if;
end process p1;
end architecture lab4_rtl;
You have declared a named constant, then ignored it...
constant CLK_FRQ : integer := 50000000;
First you can rewrite the counter in terms of CLK_FRQ and CLK_FRQ * 2 instead of magic numbers.
Then you can set different values for CLK_FRQ in sim and synth. There are various ways to do it but my preference is for a function.
function Clock_Frequency return natural is
begin
-- synthesis translate_off
return 50;
-- synthesis translate_on
return 50000000;
end Clock_Frequency;
It uses the "magic" pragmas translate_off (and _on) which may vary between synthesis tools but are accepted by most. These direct synthesis to ignore bits of the source : in this case, the first Return which is only seen by the simulator.
Now you can call this function to initialise the constant
constant CLK_FRQ : integer := Clock_Frequency;
Job done.
I would not change the clock frequency, because this doesn't change the count of events which have to be simulated by the simulator (this is also the time consuming factor). I think it's better to change the number of cycles which must pass until you change the LED output.
You can define a VHDL function which returns TRUE if you are in a simulation environment:
function SIMULATION return boolean is
variable ret : boolean;
begin
ret := false;
--synthesis translate_off
if Is_X('X') then ret := true; end if;
--synthesis translate_on
return ret;
end function;
In addition to this, you can define a if-then-else function to simplify your code:
function ite(cond : BOOLEAN; value1 : INTEGER; value2 : INTEGER) return INTEGER is
begin
if cond then
return value1;
else
return value2;
end if;
end function;
And now it's possible to select the counter's max value in one line like this:
constant COUNTER_MAX : INTEGER := ite(SIMULATION, 500, 50000);
Reviewing your code from above, there are some errors:
the LED is blinking at 0.5 Hz not 1 Hz (regarding your if
the duty-cycle is not 50.00000 %, because your counter is set to zero one cycle to late.
I think it's not intended that LED is synthesized as an addition Flip-Flop.