Simulink counter - 'hit' behaviour for the first run

Hello! I've recently started to use the simulink 'counter' module (that comes with simulink).

I notice that the counter has the count values being in the range ZERO to N ..... so N+1 values altogether in the set.

There is a user option that allows us to set an 'initial value' ... such as 0.

Now, when '0' is set as the initial value, and the maximum count is set to N = 14, and the 'hit value' is set to '14', then the very first run will occur after 14 values are counted, right? That's because the counter is already sitting on '0' to begin with for the first run, and so next edge will be 1, then 2, then 3.... so 1 to 14 makes 14 values. So first 'hit' will come up when fourteen values are counted (not including the initialised zero value).

However, for the second run (and successive runs), the 'hit' will come up when 15 values are counted.

So the behaviour of the very first run will be different from all other runs, right?

This means that - if we want the first run of the counter (during first start up) to behave like all the other ones (ie. second run and beyond), then we would have to purposely add some extra simulink components to create a feature that is the equivalent of making the initial value of the very first run to be -1, so that the the very first edge detected for the very first run (of the counter when it first starts up) will assign the 'first' count to zero?

The example is.... initial value is 'zero' and N = 14. And hit value is also set to '14'.

The counter runs for the first time. So the first detected edge makes the count go to 1. So it will take 14 values (1 to 14) to reach the hit value of '14'. That is --- initially sit at 0. Next edge is detected....so next value is 1. So, relative to the initial '0' value (which doesn't count for the first run), we have 14 values.

For the second run..... the next edge (after the value of 14) will make the counter index go to '0'. So the value of '0' is the first value of the second run. The counter than keeps going and goes up to 14 for the second hit, which makes a total of 15 values (0 to 14) for the second run.

This means the first run is different from all the rest.

This behaviour won't impact many applications, but it could impact some applications. Are there publically available simulink counter modules out there that get around this behaviour? Thanks for your help with my question in advance!

It would be nice to have a 'first run only' option having initial value of '-1', and separate reset value of '0'. This then allows the first run to begin with '-1'. So the very first count will be '0'.