Making a frequency reducer

Eric J. (coderic) OP 2022-03-19 15:13 #7008277

Rate this post

•	▲ useful ▼ not useful

I am working with an online learning tool for VHDL, trying to make a 
frequency reducer using generics.
The basic idea is: Set 'DIVIDE_BY' to a value, then get 'clk_en_out' = 1 
on every 'DIVIDE_BY'th rising edge of 'clk_in' for one pulse, before 
setting it back to 0.

E.g.: DIVIDE_BY = 8: wait for 7 rising edges, on the 8th, set clk_en_out 
= 1, on the 9th, set it back to 0, repeat.

If 'reset' = 1, reset the cycle and start at 0.

Unfortunately, I do not know what values the tool tests, so I cannot 
check why it doesn't work/on what pulse it wants me which test instance 
to be 1.
I do know though that 'DIVIDE_BY' is less than 16, so an overflow of my 
'counter' signal should not be the problem.

In the attached screenshot, the 'valid' line stops being 1 on rising 
edge 4, yet when I twisted the code so as to have 'clk_en_a' (test 
instance one; the second one is 'clk_en_b') be 1 there, it didn't 
change. I assumed that trying to get 'b' to be 1 there would be 
pointless, as that would make 'a' be 1 much earlier, which in theory 
should set the valid line to 0 much earlier.

Can someone help me figure out why it does not work?

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity ClockEnableGenerator is
generic (
    DIVIDE_BY : integer
    clk_in : in std_logic;
    clk_en_out : out std_logic;
    reset : in std_logic
end ClockEnableGenerator;
architecture rtl of ClockEnableGenerator is
signal counter : unsigned(3 downto 0) := (others => '0');
signal clk_out2 : std_logic := '0';
process(clk_in)
    begin
        if(rising_edge(clk_in)) then
            counter <= counter + 1;
            if (to_integer(counter) = DIVIDE_BY) then --reset the counter at 'DIVIDE_BY'
                counter <= (others => '0');
                clk_out2 <= '1'; --set the out2 signal
            else
                clk_out2 <= '0';
            end if;
        end if;
        if reset = '1' then --reset on HIGH reset input
            counter <= (others => '0');
            clk_out2 <= '0';
        end if;
end process;
clk_en_out <= clk_out2; --update out to out2
end architecture rtl;

Attached files:

Screenshot_2022-03-19_151237.png (79 KB)

Reply Quote Edit Move Thread sperren Anmeldepflicht aktivieren Anpinnen Delete topic Thread mit anderem zusammenführen Report post

Lothar M. (lkmiller) Moderator (Company: Titel) 2022-03-19 22:29 #7008678

Rate this post

•	▲ useful ▼ not useful

It looks fairly fine, all in all.

One problem is the well known one-by-one error: you are counting one 
step to far. With DIVIDE_BY-1 set to 8 you will see:

0,1,2,3,4,5,6,7,8

Try it this way:

if (to_integer(counter) = DIVIDE_BY-1) then...

An additional hint: why don't you simply use an integer as counter?

Eric J. wrote:
> In the attached screenshot
What's the testbench code for that waveform?

Reply Quote Edit Delete Report post

Eric J. (coderic) OP 2022-03-20 07:24 #7008833

Rate this post

•	▲ useful ▼ not useful

Hi, thanks for the reply.
I tried the -1 in the if... didn't work either, unfortunately.

Uh, good question with the integer. Most of the code was copied from my 
solution for a previous task, that's why it is a binary vector.

For the screenshot, I do not know what the testbench code is... that's 
the problem with the online tool.

Reply Quote Edit Delete Report post

Lothar M. (lkmiller) Moderator (Company: Titel) 2022-03-20 13:33 #7009122

Rate this post

•	▲ useful ▼ not useful

Eric J. wrote:
> I do not know what the testbench code is...
The testbench code is useless for counters more than 7..8 clocks, 
because then the external reset pops up.

Reply Quote Edit Delete Report post

Lothar M. (lkmiller) Moderator (Company: Titel) 2022-03-21 08:35 #7009763

Rate this post

•	▲ useful ▼ not useful

I had a chance to put your code on a testbench. What I found: you have a 
weird async reset structure:

process(clk_in)
    begin
        if rising_edge(clk_in) then
        end if;
        if reset = '1' then
        end if;
end process;

That means: your sensitivity list is incomplete, reset is missing. Due 
to that you see a strange behaviour of your design: although reset pop 
up at a absolutely random time, the counter value is reset with the next 
change of the clk_in and therefore at the falling(!!) edge of this 
clk_in.

Two solutions:
1. Add the reset to the sensitivity list

process(clk_in, reset)
    begin
        if rising_edge(clk_in) then
        end if;
        if reset = '1' then
        end if;
end process;

2. Change the structure to a synchronous reset:

process(clk_in)
    begin
        if rising_edge(clk_in) then
           if reset = '1' then
           end if;
        end if;
end process;

I prefer the unmentioned third one, so I get a synchronous design with 
no hazzle about a sensitivity list at all:

process begin
   wait until rising_edge(clk_in);
   if reset = '1' then
   end if;
end process;


See my solutions attached. I wrote a simple testbench generatin an 
100MHz clock and a reset signal every 331ns. Both of them behave the 
same and like I expect them to.

Attached files:

cegenerator_unsigned.vhd (807 Bytes) | highlighted code
cegenerator_integer.vhd (714 Bytes) | highlighted code
tb_cegenerator.vhd (2.14 KB) | highlighted code

WF_cegenerator.PNG (9.7 KB)

Reply Quote Edit Delete Report post

Eric J. (coderic) OP 2022-03-21 19:13 #7010469

Rate this post

•	▲ useful ▼ not useful

Thank you for the detailed explanation. Made my code prettier with the 
reset.
It didn't fix the problem, though; after some trial and error, I landed 
at:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity ClockEnableGenerator is
generic (
    DIVIDE_BY : integer := 1
    clk_in : in std_logic;
    clk_en_out : out std_logic;
    reset : in std_logic
end ClockEnableGenerator;
architecture rtl of ClockEnableGenerator is
signal counter : integer range -1 to 15 := 0;
process(clk_in, reset)
    begin
        if(rising_edge(clk_in)) then
            counter <= counter + 1;
            if (counter = DIVIDE_BY-2) then --reset the counter at 'DIVIDE_BY'
                counter <= -1;
                clk_en_out <= '1'; --set the out2 signal
            else
                clk_en_out <= '0';
            end if;
        end if;
        if reset = '1' then --reset on HIGH reset input
            counter <= 0;
            clk_en_out <= '0';
        end if;
end process;
end architecture rtl;


Note that counter is set to -1 once the DIVIDE_BYth rising edge is 
reached - because the interval clk_out_en is 1 apparently should not be 
counted. By giving the counter one more rising edge to count, the 
problem is fixed.

Thank you for the help!

Reply Quote Edit Delete Report post

Lothar M. (lkmiller) Moderator (Company: Titel) 2022-03-22 10:03 #7010975

Rate this post

•	▲ useful ▼ not useful

Eric J. wrote:
> the problem is fixed.
What "problem"? As far as I see the problem is your understanding of 
what should happen.

> because the interval clk_out_en is 1 apparently should not be counted.
Look on any µC or any other computing device with a counter inside all 
over the world: each of them continues counting when reporting an 
overflow or a match or something else.

> because the interval clk_out_en is 1 apparently should not be counted.
Based on what "appearance" do you come to this conclusion? What should 
happen, when DIVIDE_BY is 1? If you have a clock of 10 MHz and DIVIDE it 
BY  1, then the clockenable must be '1' all the time. Because dividing 
by 1 means "run with the clocks frequency". And exactly thats what my 
code does (see the screenshot)...


Running your code against my testbench leads to

# RUNTIME: Fatal Error: RUNTIME_0067 design.vhd (24): Value 16 out of range (-1 to 15).
# KERNEL: Time: 165 ns,  Iteration: 0,  Instance: /tb_cegenerator/uut,  Process: line__20.

And its obviously why: you initialize counter with 0. Then you set 
DIVIDE_BY to 1. Then you assign a clock and do this comparison "if 
(counter = DIVIDE_BY-2) then..." which is the same as "if (counter = -1) 
then...". And as counter value is "0 and increasing" that compare 
against -1 is always wrong and the counter counts on and on until it 
reaches the end of its range generating an error message.

Check it out yourself: https://www.edaplayground.com/x/DZuL

Attached files:

WF_cegenerator_divideby1.PNG (7.8 KB)

Reply Quote Edit Delete Report post