[aon_timer, rtl/doc] No wakeup signalled on watchdog bite if it occurs before bark

[GregAC]

aon_timer has a top-level signal wkup_req_o which is asserted on either the wakeup timer triggering or the watchdog bark triggering. The watchdog bite does not inherently assert this signal, it only asserts aon_timer_rst_req_o.

Provided the bark is configured to occur before the bite this should be no issue. First a wakeup will occur and assuming the bark is ignored, the bite will happen with wkup_req_o still asserted and now with aon_timer_rst_req_o too.

If the bite is configured to occur first you will only get aon_timer_rst_req_o.

I don't think this is a big issue as bark before bite is the sane configuration and signalling aon_timer_rst_req_o without wkup_req_o may have the desired effect (a chip reset) anyway?

The only action here may be to clarify this behaviour in the documentation. P1 as we need to discuss and agree no RTL change is needed here for M2.5.1

@msfschaffner @matutem any thoughts?

[matutem]

If I understand correctly, your concern is that there is a case where a bite may be triggered by aon_timer_rst_req_o while wkup_req_o is still asserted. In that case we should just assert, and wkup_req_o should be inconsequential. I see no need to clarify or change this, since it is what should be expected when the CPU disables or otherwise doesn't handle the wakeup interrupt.

If that is the case, the only item is to make sure we have tests that triggers this condition.

[GregAC]

It's the other scenario, where we assert aon_timer_rst_req_o without first asserting wkup_req_o. I presume we still get a reset here anyway so there's no real issue? Though we should ensure it's documented properly at the block level should it prove to be a problem for future uses of the block.

[matutem]

Got it. There should be no problem: during low power the pwrmgr slow fsm will exit from low power due to a wakeup or a reset request. And if it is due to a reset it won't trigger a wakeup interrupt (if enabled).

Notice when entering low power we don't reset aon domains (specifically aon_timer and sysrst_ctrl), so when waking up from low power due to a reset the reset request persists, and pwrmgr will take the reset right after waking up, at which point it will reset aon domains.

[matutem]

@GregAC this seems all clear from my side. If you agree, could you close it?

[GregAC]

Yup all good, I'll leave it open but as a doc only issue.

[moidx]

Moving to M2.5.3 as part of the datasheet/documentation updates task.

[matutem]

I checked https://opentitan.org/book/hw/ip/aon_timer/index.html#aon-watchdog-timer mentions the bite reset request "is independent of the IRQ sent as part of the watchdog bark". Do you think this needs further clarification? If so, any suggestions?