Meaning of "modulo" for a counter.

[Circlotron]

I've read the datasheet and the term still seems ambiguous.
Say we have the counter in a MCU with the modulo set to decimal 25.
Does that mean
1/ the instant the counter gets to 25 it resets to zero so that there are 25 different count states (0-24)
or 2/ the counter can get up to 25 and the next clock tick rolls it over to zero.

I'm thinking 1/ but I'm not totally sure.

[SiliconWizard]

No one knows what datasheet you're referring to...

But as far as 'modulo' is concerned mathematically, it's the remainder of the division of a number by the modulo. Meaning that any multiple of the modulo will be congruent to 0.
So yeah, 25 (mod 25) is 0 (mod 25).

[hans]

Modulo mathematically speaking is the first option. In hypothesis 2 you would have 26 numbers (namely 0-25) in a modulo 25 system (which imply a range of 25 numbers, e.g. 0-24), which doesn't make sense.

How it is defined in a datasheet is anyone's guess if we don't have a reference to it. However, typically they are not written by mathematicians.

[westfw]

Which chip has a "modulo" setting?

I hope it's (1), because that lines up with the math definition!

Most of the counter/timers I've seen have a "top" register setting, and you have to pay careful attention to whether they reset to 0 when they WOULD reach "top", or on the tick after "top."

[MK14]

The number of different output states a counter can produce is called the modulo or modulus of the counter. The Modulus (or MOD-number) of a counter is the total number of unique states it passes through in one complete counting cycle with a mod-n counter being described also as a divide-by-n counter.

I.e. The link, seems to say it is answer 1) in the OP.

Source:
https://www.electronics-tutorials.ws/counter/mod-counters.html#:~:text=The%20number%20of%20different%20output,divide%2Dby%2Dn%20counter.

[Circlotron]

In the 9S08PA16 datasheet:

12.3.6 Modulo High (FTMx_MODH)
The Modulo registers contain the high and low bytes of the modulo value for the FTM
counter. After the FTM counter reaches the modulo value, the overflow flag (TOF)
becomes set at the next clock, and the next value of FTM counter depends on the selected
counting method (Counter).

Assuming the counting method is arranged to overflow to zero, that *seems* to say that if the modulo was set to 25 then the counter would have 26 states, 0-25, and that sounds weird.

[retiredfeline]

Well the counter must have one state extra, at least internally, and possibly transient, to be able to detect overflow. But what does that matter to you? Why not take what it says at face value, and accept that when the counter reaches the modulo value, something happens? Usually reset to 0, but it could be preset to N, who knows, in which case it would be a shortened count cycle.

I'm reminded of the ancient 7490 counter. It has a 2 input AND gate for reset to 0, so it seems impossible use it to divide by 7. But the trick is the use the 2 input AND reset to 9 (another reset gate) to detect 6, so the states become 9, 0, 1, 2, 3, 4, 5 (and transiently 6).

[MK14]

In the 9S08PA16 datasheet:

12.3.6 Modulo High (FTMx_MODH)
The Modulo registers contain the high and low bytes of the modulo value for the FTM
counter. After the FTM counter reaches the modulo value, the overflow flag (TOF)
becomes set at the next clock, and the next value of FTM counter depends on the selected
counting method (Counter).

Assuming the counting method is arranged to overflow to zero, that *seems* to say that if the modulo was set to 25 then the counter would have 26 states, 0-25, and that sounds weird.

If my somewhat quick look at the datasheet is right. You (assuming you are going for the UP counting mode), set the lowest and highest count values, and hence get (page 307 of the datasheet):

The FTM period when using up counting is (MODH:L – CNTINH:L + 0x0001) × period
of the FTM counter clock.

(Max-value - Min-Value) + 1, counts.

So if you wanted to make a modulo 25 counter, you would set the start to 0, end to 24, and hence get a modulo 25 counter (assuming UP mode is selected).

Datasheet:
https://www.nxp.com/docs/en/reference-manual/MC9S08PA16RM_Rev.1.pdf

[Circlotron]

Actually, what I really want to do is see if a certain time interval has been exceeded by checking the timer overflow bit. If only I could get a proper night's sleep this would be easy peasy. 

[Cerebus]

Well the counter must have one state extra, at least internally, and possibly transient, to be able to detect overflow. But what does that matter to you? Why not take what it says at face value, and accept that when the counter reaches the modulo value, something happens? Usually reset to 0, but it could be preset to N, who knows, in which case it would be a shortened count cycle.

I'm reminded of the ancient 7490 counter. It has a 2 input AND gate for reset to 0, so it seems impossible use it to divide by 7. But the trick is the use the 2 input AND reset to 9 (another reset gate) to detect 6, so the states become 9, 0, 1, 2, 3, 4, 5 (and transiently 6).

No need for any extra, hidden or transient states, normal synchronous logic can take care of determining in the last but one state that the following state should be zero:

Code: [Select]

`timescale 1ns / 100ps

module  Test (
    input wire clk,
    input wire reset,
    output reg [31:0] counter,
    input wire [31:0] modulo
);
   
    always @(posedge clk)
    begin
        if (reset)
            counter <= 32'b0;
        else
            if ((counter + 1) == modulo)
                counter <= 32'b0;
            else
                counter <= counter + 1;
    end
endmodule

`ifndef SYNTHESIS

module TestBench();
    parameter
        clock_period = 50,
        clock_pulse_width = clock_period/2;
   
    reg clk;
    reg reset;
    always #(clock_pulse_width) clk = ~clk;
   
    wire [31:0] counter_out;
    reg [31:0] supplied_modulo;
   
   
    initial begin
        $dumpfile ("Test.lxt");
        $dumpvars (0, TestBench);
        supplied_modulo = 25;
        clk = 0;
        reset = 0;
        #(clock_period) reset = 1;
        #(clock_period) reset = 0;
   
        #5000 $finish;
    end
   
    Test DUT (clk, reset, counter_out, supplied_modulo);
   
endmodule
`endif


[PCB.Wiz]

Actually, what I really want to do is see if a certain time interval has been exceeded by checking the timer overflow bit. If only I could get a proper night's sleep this would be easy peasy. 

Off-by-one errors are common in MCU designs,  so rather than overthink it, take a guess and then measure it on a test bench to verify what actually happens.

[Cerebus]

A better route would be educating the tech writer who produced ambiguous documentation with the traditional cluebat. More satisfying too. 

[timenutgoblin]

But as far as 'modulo' is concerned mathematically, it's the remainder of the division of a number by the modulo. Meaning that any multiple of the modulo will be congruent to 0.
So yeah, 25 (mod 25) is 0 (mod 25).

This is how I understand it.

Thinking of modulo in terms of a clock face with a hand pointing straight up to '0' for the starting position and then moving in discrete steps of (360/n) degrees per step where n is the modulo number before arriving at the penultimate step of (n-1) then returning to '0'.

Since counters can count forwards or backwards, the hand of the clock face can move clockwise or anticlockwise accordingly.

[westfw]

A better route would be educating the tech writer who produced ambiguous documentation with the traditional cluebat.

For a 9S08 ?  They've probably retired by now. :-)
(9S08 is semi-ancient Motorola 6805-like 8bit chip.)

[Cerebus]

A better route would be educating the tech writer who produced ambiguous documentation with the traditional cluebat.

For a 9S08 ?  They've probably retired by now. :-)
(9S08 is semi-ancient Motorola 6805-like 8bit chip.)

"Wake them all up! Put some stick about!"
- Francis Urquhart [Fictional] Chief Whip

[SiliconWizard]

For timers, the meaning of the "period" value you set depends on how they are implemented and whether they are up- or down-counting.
The period value is most commonly never reached - it's the modulo value indeed. But depending on the timers and the direction of counting, you sometimes have to set it to the required period in cycles minus one. Only the manual can tell you. And... those with timing diagrams are better, because words only can be ambiguous, and it's a hard skill to be able to convey 100% non-ambiguous technical specs with just words.

[Benta]

it seems the MCU definition is more complex than for hardware counters.

For hardware counters "modulo" is simply the number of counts before the counter "rolls over" and starts again.
Example: a modulo-3 counter would simply count 0-1-2-0-1-2 or 2-1-0-2-1-0

[Circlotron]

it seems the MCU definition is more complex than for hardware counters.

For hardware counters "modulo" is simply the number of counts before the counter "rolls over" and starts again.
Example: a modulo-3 counter would simply count 0-1-2-0-1-2 or 2-1-0-2-1-0

And right there is an example of the problem.
The counter you describe has 3 different states for sure, but "the number of counts before the counter "rolls over" and starts again" sounds like there are only two counts then it rolls over. 

[Benta]

And right there is an example of the problem.
The counter you describe has 3 different states for sure, but "the number of counts before the counter "rolls over" and starts again" sounds like there are only two counts then it rolls over.

Why? 0 is also a count.
You mention the important point yourself: the counter has three states. Whether these are 0-1-2-0. 1-2-3-1 or 12-13-14-12 is irrelevant and just a question of bit coding.
Modulo is 3.

[Circlotron]

Yeah, sounds like part of the confusion is cardinal vs ordinal numbers.
0, 1, 2 vs first, second, third.

[Benta]

Yeah, sounds like part of the confusion is cardinal vs ordinal numbers.
0, 1, 2 vs first, second, third.

Yep. It's about expanding your view. Not everything is 1-2-3

[Circlotron]

There are so many contradictory explanations of all this. For example at https://www.electronics-tutorials.ws/counter/mod-counters.html we read

Modulus Counters, or simply MOD counters, are defined based on the number of states that the counter will sequence through before returning back to its original value. For example, a 2-bit counter that counts from 002 to 112 in binary, that is 0 to 3 in decimal, has a modulus value of 4 ( 00 → 1 → 10 → 11, and return back to 00 ) so would therefore be called a modulo-4, or mod-4, counter. Note also that it has taken four clock pulses to get from 00 to 11.

To my mind the statement
"the number of states that the counter will sequence through before returning back to its original value"
should read
"the number of states that the counter will sequence through to get back to its original value"
The word "before" indicates that the counter has not yet rolled over or reset to it's original value.

And...

Note also that it has taken four clock pulses to get from 00 to 11

What??? Four???

I'm just gonna write a few lines of assembly and stick a scope on one of the pins and be done with it. 

[timenutgoblin]

Actually, what I really want to do is see if a certain time interval has been exceeded by checking the timer overflow bit. If only I could get a proper night's sleep this would be easy peasy. 

If the timer overflow bit is taken into consideration then it becomes an additional count state. Instead of 25, 24, 23, ... , 3, 2, 1, 0 there is also 0xFF when the counter overflows before being reset to 25 and starting again. The counter is being decremented 26 times because of the overflow event. If you need to decrement the counter 25 times then it should be set to 24.

[SiliconWizard]

(snip)

Note also that it has taken four clock pulses to get from 00 to 11

What??? Four???

Seems you have a hard time grasping the idea. Possibly comes from having too much of a "software" view of things - while Cerebus took the time to illustrate how that works from a low-level logic standpoint.

Indeed, if you have a hard time escaping the "software" view, you may have a hard time understanding how a counter can roll over at a specific value without actually using a "state" for which it does hold that particular value.

But even that can be easily achieved in pure software (say 'n' is your counter and 'm' holds the value of the modulo):

Code: [Select]

// Next state.
if (n < m-1)
    n++;
else
    n = 0;
It will indeed cycle through m values but n will never reach m.

But if you write it this way:

Code: [Select]

// Next state.
n++;
if (n == m)
    n = 0;
then n will reach m before being reset to 0. The end result being the same, but there is an additional step here.

(Was just trying to guess what confuses you, but maybe I just haven't understood what you had a hard time understanding.)

But I just said this to address what seemed to be your other sources of confusion in the thread; as to the statement

Note also that it has taken four clock pulses to get from 00 to 11

you just replied to, it is actually wrong, put like this. It takes 4 clock cycles to get from 00 to 00 again, and 3 cycles from 00 to 11. As I'm pretty sure the author of this knew that, that's possibly a good illustration of how many people have a hard time expressing unambiguous statements with words. Possibly what was meant here was not "from 00 to 11", but assuming there was an initial clock pulse to get from the previous state (which then here would be 11) to the initial 00. An horrible way of expressing oneself if so, and yet another reason for providing diagrams to settle any written ambiguity.

[Benta]

To my mind the statement
"the number of states that the counter will sequence through before returning back to its original value"
should read
"the number of states that the counter will sequence through to get back to its original value"
The word "before" indicates that the counter has not yet rolled over or reset to it's original value.

I agree that the problem here is "software thinking". For a HW engineer the statement is unproblematic, but has to be qualified and sorted into two cases:
1: free running counter. Normal in HW, rare in SW.
2: one-shot counter. Normal in SW, rarer in HW.

For 1, the analysis is unproblematic. Any periodic count sequence has a modulo. 00-01-10-11-00-01 etc.
For 2, it can be difficult. Initial and end-of-count states need to be analyzed to avoid an "N+1 or N-1" error. Eg, "for 0...n" actually counts n+1 states.