Better definition of clock domains

[galibert]

Rendered

[josuah]

The new syntax, in particular the new ClockDomain constructor, makes it a whole lot easier to read!

To have an insight on who used the existing API:
https://github.com/search?q=enableinserter+language%3APython&type=code&l=Python

[whitequark]

This all is broadly reasonable and in line with what I've been planning already. It is a very large change however, and I think we won't get around to it particularly soon. Ultimately something like this needs to be done before 1.0, and probably this year.

[jevinskie]

Has anybody thought about adding clock frequency information to ClockDomains?

I opened enjoy-digital/litex#1310 because I wanted build-time assertions to ensure that a hard IP block wasn’t being overclocked.

Perhaps freq, freq_min, freq_max and maybe a freq_margin (for PLL outputs that have guaranteed tolerances) could be useful? Or would that be better served by a new RFC?

[whitequark]

Has anybody thought about adding clock frequency information to ClockDomains?

Yes. This is a rather complex problem in situations where frequency can change at runtime. It should not be a part of this RFC.

(In addition the assertions probably need to run post-elaboration, which isn't something we currently have at all.)

[whitequark]

Reopened as requested by the author.

[whitequark]

I've listed the challenges associated with the current clock domain system in this conversation. To move this proposal forward, it will have to give an answer to these challenges, especially the interaction of sync reset, async reset, and enable.

More broadly, I think that the domain scoping and the domain control set semantics are topics that can probably be addressed separately. Given how troublesome domain scoping is for both understanding the language and for implementing it (NIR and the platform layer struggle with it) this may be worth addressing separately.