ComponentInterface typing wrapper for lib.wiring interfaces

[piotro888]

Redesign of concept from Coreblocks PR kuznia-rdzeni/coreblocks#726.
Class that can be used both for typing and to get amaranth Signature for use in Component constructor.

[piotro888]

Improvement from previous version: now separate FlippedComponentInterface is used to implement flips cleanly, without using copy and getting is_flipped under try/catch.

[piotro888]

amaranth-stubs commit needs to be changed before merge

[tilk]

Can this handle arbitrary ShapeLikes as members?

[piotro888]

Yes, tested here for int:

transactron/test/utils/test_component_interface.py

Line 21 in 81cf873

self.i = CIn(2)

and is ShapeLike in type stubs.

I can additionally include some ShapeCastable field in testbench.

[piotro888]

Turns out there was an unnecessary early Shape.cast that broken View wrapping trick around Signal, and Layouts were flattened. Fixed now and added to tests.
Thanks!

[tilk]

This ComponentSignal feels hacky, which could be fragile with future Amaranth updates. Is it possible to implement it as a ShapeCastable?

[piotro888]

No, it needs to be type-equivalent to Signal.
I'm now thinking of making AbstractSignal instead.

[piotro888]

There is a problem with typing of ComponentSignal.shape(). It is required from View that it returns Shape, but it is not true from lib.data fields that use a hack to wrap around Signal and return ShapeLike/ShapeCastable? instead.

AbstractSignal with shape changed to always return Shape | ShapeCastable (without Value inheritance) should solve this issue, but loosen typing a bit, but I don't think that Shape ShapeCastable distinction is that critical in calling shape() and I don't see other way to do it.

[piotro888]

I think this problem is not addressed in current amaranth-stubs: Signal(ArrayLayout(2, 3)).shape() == ArrayLayout(2, 2)), but according to stubs it must be Shape.
It is true for Amaranth Signal, but not one extended with lib.data

[tilk]

I think this problem is not addressed in current amaranth-stubs: Signal(ArrayLayout(2, 3)).shape() == ArrayLayout(2, 2)), but according to stubs it must be Shape.

This is not true. Signal(ArrayLayout(2, 3)) is not a Signal, it's a View.

[piotro888]

This is not true. Signal(ArrayLayout(2, 3)) is not a Signal, it's a View.

How this is described in stubs? Maybe similar method could be used here?
I know about Signal -> View conversion, but didn't expect it to be possible to define in stubs.

[tilk]

This is not true. Signal(ArrayLayout(2, 3)) is not a Signal, it's a View.

How this is described in stubs?

See _SignalMeta: https://github.com/kuznia-rdzeni/amaranth-stubs/blob/d62b68241fa1881244470e63931ceb635ac91044/amaranth-stubs/hdl/_ast.pyi#L497

(By the way, there is a slight problem in the stubs here - the overload for ShapeLike should be for ShapeLikes which are not ShapeCastable. This leads to misleading inferred types when developing components which are generic in arbitrary ShapeLikes - like current MemoryBank.)

Maybe similar method could be used here?

Maybe. But please consider again if ValueCastable, ShapeCastable or something like this could be used here. It would be preferable to use standard Amaranth methods for customizing the language.

[tilk]

Another thought: maybe handling everything at type level via typing.Annotated could work for this?