[LTL] Add ClockedAtomOp description

[Clo91eaf]

Motivation

ltl.clock currently carries too many responsibilities.

As clock operands become explicit on operations such as ltl.clocked_delay and ltl.past, the remaining scope of ltl.clock becomes much smaller. Once frontends stop emitting implicitly clocked temporal operations, the remaining necessary use of ltl.clock is to assign a sampling clock to boolean atoms.

Change

This PR introduces ltl.clocked_atom to separate out that responsibility. It converts an i1 into an !ltl.sequence under an explicit clocking event.

With this op, LTL can move toward a cleaner form: no ltl.clock, every operation that needs a clock gets one explicitly from the frontend, and every !ltl.sequence produced from an i1 is clocked through ltl.clocked_atom.

Follow-up

ltl.clocked_atom will require updates to passes and canonicalizations that currently handle ltl.clock. Those changes will be implemented in follow-up PRs.

Assisted-by: Codex:gpt-5.5

[Clo91eaf]

@TaoBi22 wdyt? actually i'm now do some experimental work in Zaozi SVA to try to make a clean sva frontend, this pr will be a small step of a big try

[circt-bot]

Results of circt-tests run for 64d84ff compared to results for 0f6f59d: no change to test results.

[circt-bot]

Results of circt-tests run for 3ecef0f compared to results for 0f6f59d: no change to test results.

[TaoBi22]

This looks like it's moving in the right direction to me (though CC: @fabianschuiki since he and I have spoken about this kind of thing a few times).

I wonder if it's worth holding off on merging this until we've finished migrating the DelayOp? Otherwise it seems like we might end up with no way to provide a clock for a DelayOp.

(sorry for the Copilot review, I hit the button by accident and it doesn't seem to let you cancel it 🤦)

[Clo91eaf]

@TaoBi22 That's perfectly fine👍 ! But what means finished migrating the DelayOp, In my immature assumption, we will have two sets of clock APIs: one is the ltl.clock and ltl.delay we used before, which has always been working properly.

Another set of analyses includes ltl.clocked_atom, ltl.clocked_delay, which we've recently added, and the merging @(posedge clock) analysis pass that we plan to add.

These two solutions are independent of each other. My expectation is that after the latter is implemented, these two solutions will coexist for a period of time, then we will migrate to Chisel and completely deprecate ltl.clock and ltl.delay. I'd like to know your thoughts on this? Did you have a plan to migrate ltl.delay in some way?