Catherine

You aren't using `dummy.y` at all in this code, no?

> Was this changed already? I didn't intend to change this. I think the reason you see the behavior you do is that I did not understand the design of...

The basic idea is sound, thanks. But, what happens if someone uses a negedge clock domain (#185) in the design? There are many valid reasons to do so, and even...

In terms of the UI, currently `add_process` requires submitting explicit wait commands (i.e. `Tick("domain")`, and `add_sync_process(domain=)` automatically substitutes `yield Tick(domain)` for any `yield` with no arguments. We could split that...

Can you provide some examples of those reasons?

> If your process wants to do the equivalent of comb logic, this is limiting. Comb processes are something I wanted to introduce explicitly (that's the second oldest nMigen issue,...

Perhaps a trio of `yield Tick(domain)` (where if the domain is omitted, it is taken from the process), waiting until clock edge; `yield Settle()`, waiting until comb fixpoint; `yield Wait(signals...)`,...

> Do you even need to differentiate `add_sync_process` and `add_comb_process` with the above? No, but for that matter, `add_sync_process` was never strictly a necessity either. Today it is simple syntactic...

> And now we can debate if `yield Tick(domain)` should be "settle, update sync, and settle again". Then it would be robustly equivalent to the current behavior. I would not...

You're right. We want the same thing but I was not describing it precisely. Thank you for this discussion. I now have a very clear picture of how the next...