Catherine

I would like to avoid introducing that functionality (and the associated syntactic burden) until someone actually needs it.

Okay. I still think it should be done separately because while this one is fairly straightforward (it's just a way to write a tuple that's less error prone than usual),...

I think we can do it upstream; I said [earlier](https://github.com/nmigen/nmigen/issues/510#issuecomment-713453939) that I'd like to avoid introducing it because it sounded theoretical (which is usually bad because features done in abstract...

We discussed inversion of connector signals at the last meeting. Because inversion of single ended signals is rarely needed and can also complicate things even further (you have to keep...

My current plan for addressing this need is providing some example linters, and if the idea turns out to be popular, we can figure out some nice way to integrate...

> Regarding width, fortunately Signal is not final (`@final` is [commented out](https://github.com/amaranth-lang/amaranth/blob/db49294cf722e9463666bd06f81a86f930b8707c/amaranth/hdl/ast.py#L896) ). This will stop being the case once `amaranth.compat` is deprecated for good. We'll need to come up...

I reviewed a few argument parsing libraries and I didn't like any of them, so at some point likely I'll rewrite argparse.

I feel like this ought to be addressed systematically. Let's leave this out of C0; if someone wants digipots, they can use the testpoints. Once the need and a good...

> Yeah, we'd need supplies to make this actually useful (and depending on what the user is doing, that might mean 3V3 or VioA or VioB or even also 5V)...

My additional experience with I2C on revC0 indicates that *any* fault on the bus tends to bring the device to its knees until it's power cycled, and USB is not...