You need a small model - code a scoreboard containing a behavioral model of your counter/timer [make it accurate enough for your spec and test plan but not too complicated].
It would watch config register changes [triggered from the ‘bus’ end of the register model where they actually take effect, not from the ‘API’ end]
It would watch the clock source to the counter [via a small interface/monitor if anything other than the bus clock. Consider whether you only need the simple case where the clock is running all the time at the same period or the more complex case where you need to count each clock edge.]
It would watch the interrupt output via a small interface/monitor.
It would predict how many clock cycles remain before the interrupt would be expected, update that prediction with each config register change or clock edge observed, and do 2 checks: (1) triggered by the interrupt - did the interrupt occur too soon → fail, and (2) triggered by its internal prediction - did too many clock cycles pass without an interrupt yet → fail.
That’s the checking side, the rest is stimulus (registers and clocking and a higher level reflecting the use model: setup, wait for interrupt, clear interrupt, etc)
Good luck…