[asserts] Different assert disable condition for clocks

[tjaychen]

For known output asserts in clocking modules, see here, the clocks technically should be known even before the reset release.

There should be a different condition for these specific cases other than reset.

estimate 12

[cindychip]

Hey Tim,
Not sure if this is what you are looking for. I wonder if this would work-
ASSERT_KNOWN(ExportClocksKownO_A, clocks_${intf}_o, clk_i, 0)

[tjaychen]

ah that's not QUITE it. Because i think the clocks will be unknown at some point (when the system is still spinning up). But they do need to become known before the reset release.

So I think i need to find a different signal somehow..except that signal might not exist in clkmgr itself :)

[msfschaffner]

@tjaychen can this issue be updated?

[andreaskurth]

Triaged for clkmgr. Assigning to M2.5 with Priority:P3 Priority: low because I think it would be nice to have stricter assertions but what we have covers the essentials.

[msfschaffner]

CC @matutem

[matutem]

Hmm, maybe we should clock these assertions on each clock's reset. Something like

assert property @(posedge rst_ni) !$isunknown(clk) else error;

Or we could use clk_aon for an assertion as in this pseudo code

`ASSERT(the clock known, $rose |-> !$isunknown($past(the clock)), clk_aon_i)

[matutem]

Creating per clock and reset pair SVA for this condition seems tricky. Perhaps we can change strategy and check that when the root resets are released the AST clk_en outputs are active. We can create assertions that rely on this for some derived resets, like those that are software triggered, since we can check a clock is active against a root clock by checking it at the root clock negedges, similar to what is done in https:/lowRISC/opentitan/blob/master/hw/ip_templates/clkmgr/dv/sva/clkmgr_div_sva_if.sv.