Open
Description
Friday Dec 14, 2018 at 17:40 GMT
Originally opened as m-labs/nmigen#4
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