One thing to add is that for a while I wanted to add some first-class interface for specifying port directions, essentially the same thing as describing something as Signal(8), in in documentation but in code. Python type annotations might be helpful here.

• Provide verification processes for simulation that assert the correct timing pattern (of e.g. the stb signals) at the module boundaries. I.e. allow verification of the specified latency matrices.

Not just simulation; assertions for property testing ("formal verification") are much more valuable for this, since they are better at discovering edge cases.

• handle framed data that spans multiple clock cycles (eof a.k.a. sop/eop): determine overall cycle periods

There has been interest in having an AXI4-Stream-like interface in nMigen core (from @lambdaconcept, and it also exists in LiteX, showing substantial interest), so I think such stream interface should be added first.

Right. A good stream interface is the foundation for all this.

My proposal for the stream interface is to use four signals: data, ack (aka tready in AXI4), stb (aka tvalid in AXI4), and eop (aka tlast in AXI4), all with AXI4-Stream semantics. Any objections?

Perfect. It would be great if we can make this interface so smooth that the even the dumb usage (data in every cycle, no handshaking, always valid) requires no additional manual strapping of signals and is just as easy to use and always preferable over self.data = Signal(). That would preempt lots of adapter boilerplate when reusing components.

We can make ack, rdy and eop be Signal(reset=1), that should do the trick.

Or a different constructor to make this usage explicit.

Would be good to understand how this might match wishbone too?

I don't think this is relevant to Wishbone, since it does not have a streaming interface.

I believe that @wallento was claiming otherwise at OrConf. Maybe he can confirm or deny that?

I believe that an implementation of Rigel would provide every single feature @jordens requested.

I would love something like that in nMigen, and might even be able to help next year. My past experience of line-buffer based video processing with moving windows has been very enjoyable, it would be interesting to work with something like that again.

Sweet!

That paper is super interesting! This stuff is something that I could potentially look at providing funding around. I'm more interested in actually using it for graphics related stuff.