Require signals crossing clock domains to be explicitly marked

[whitequark]

17:30 < sb0> whitequark: for multi clock domain designs, I'd also like signals driven in one domain and sampled in another to cause a warning
17:30 < sb0> unless each such path is explicitly marked by the user as valid
17:30 < whitequark> sure
17:30 < whitequark> that's even easier
17:31 < whitequark> what about I/O pins?
17:31 < whitequark> forgetting a MultiReg is a fairly frequent error
17:31 < sb0> ideally, there should be some framework to automatically instantiate LVDS buffers and such
17:31 < sb0> ah, for CDC
17:32 < whitequark> oh, I have this kind of thing in Glasgow
17:32 < whitequark> maybe we should rethink I/O for nmigen
17:32 < sb0> in artiq there are certain things that are sometimes run over CMOS (on KC705) and LVDS (on Kasli over the ribbon cables)
17:33 < sb0> right now this is not handled in an elegant manner
17:34 < sb0> I guess I/O pins could be marked as asynchronous by default, and also could have a clock domain associated with them
17:34 < sb0> then the same rule applies
17:34 < whitequark> ok
17:35 < sb0> the "asychronous mode" is basically another "invisible" clock domain
17:36 < whitequark> what if one half of a comb signal is driven from domain A and another half from domain B?
17:36 < whitequark> how should this be handled?
17:39 < sb0> 1. emit a warning (unless the user says it is valid) 2. treat the result as asynchronous ?
17:40 < whitequark> ok
17:41 < sb0> also, there should also be warnings for paths that are marked as valid CDC but end up being in the same domain
17:41 < sb0> i.e. anything other than marking exactly the CDC paths as valid CDCs results in warnings

[whitequark]

@sbourdeauducq Here's the major obstacle to getting this done: instance ports. Inout and in ports can in principle be ignored (though that raises the question of whether we're going for full correctness or best-effort detection), but all out ports would require some annotation or they'd just emit false violations. I'm not sure how to best handle this yet.

Maybe the platform could provide an annotated list of primitives? But that doesn't help external Verilog.