0

I'm trying to create a very simple watch (I don't use the word "clock" to avoid misunderstandings) on my FPGA (it displays seconds, minutes and hours) for an assignment and a friend of mine gave me some code that actually works when I synthesize it on my FPGA, but I can't understand why. Here's the main process.

main: process(clk)
begin

    if((clk='1' and clk'event) and en='1') then
        if(init = '0') then
            sec <= conv_integer(seconds_in);
            min <= conv_integer(minutes_in);
            hour <= conv_integer(hours_in);
            init <= '1';
        else
            count <= count + 1;
            if(count = 1000000) then
                sec <= sec+1;
                count <= 0;
                if(sec=59) then
                    min <= min+1;
                    sec <= 0;
                    if(min=59) then
                        hour <= hour+1;
                        min <= 0;
                        if(hour=23) then
                            hour <= 0;
                            count <= 0;
                        end if;
                    end if;
                end if;
            end if;
        end if;
    end if;

end process main;

It starts by initializing the integers sec, min and hour to the initial value set by the user. Then, it does the actual work of incrementing the variables every second, minute or hour. The frequency of clk is 1 MHz.

Reading the code, it seems that hour (for istance) should increment just after min turns to 59, without waiting a full minute. But, when I synthesize it on the FPGA, it works fine, just as you would expect. Unfortunately, I can't run a simulation. Maybe this has something to do with the scheduling of the process? I'm still a beginner and maybe I'm missing something.

[EDIT] Thanks to the comments, I noticed a small error in the code above (count was not correctly reset). Fixed it!

Alessandro
  • 319
  • 2
  • 3
  • 15
  • 1
    In `min <= min + 1; if (min=59)`, if `min` is 59 at the start of the process, its *next* value (after the process has ended) will be 0, but it is still 59 during the whole process, so the body of the `if` will be executed. – mkrieger1 Feb 05 '17 at 18:29
  • Thanks @mkrieger1 . So I assume that the same applies if `min` is 58 at the start of the process: in this case, the `if` will _not_ be executed and `min` will be incremented only after the process has ended. Did I understand correctly? Anyway, does this happen even if `min` is an integer variable and not a signal? – Alessandro Feb 05 '17 at 18:37
  • 1
    It works like this *because* `min` is a signal. If it were a variable, it would be updated immediately within the process and the logic would have to be written differently. Whether it's an integer (its *type*) is an orthogonal concept to whether it's a signal or a variable. – mkrieger1 Feb 05 '17 at 18:49
  • Thanks, now it's clear. I originally thought that `min` was a variable, while it is (as you correctly pointed out) a signal. – Alessandro Feb 05 '17 at 18:52
  • 3
    And DOES it actually work? It looks to me as if it doesn't clear COUNT prroperly every second. – user_1818839 Feb 05 '17 at 18:59
  • 1
    I agree that it looks like `count` fails to get reset when it should. if a 20-bit signal was used, you probably wouldn't notice because it would only run 5% slow (`2**20` is only 5% larger than `10**6`, at which point a 20 bit signal would roll over implicitly). – QuantumRipple Feb 09 '17 at 19:51
  • Yes, you're both right. `count` should be reset after the increment of `sec`. I'll edit the post. – Alessandro Feb 10 '17 at 11:16

0 Answers0