<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] c38dc97 - Deploying to main from @ amaranth-lang/amaranth@d27681b15720220460bb7e7ab36407b7305cc960 🚀
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 4651182 - Deploying to main from @ amaranth-lang/amaranth@04b542a626f81f07333bda1dc976b6b7d3db26ca 🚀
pepijndevos[m] has joined #amaranth-lang
<pepijndevos[m]>
Does Amaranth aim to have LiteX-like support for assembling SoC or is it a more generic/low-level thing? Since LiteX is built on top of classic Migen and in no hurry to upgrade
<jfng[m]>
the latter at the moment, while we are working our way towards a full blown SoC builder
Guest46 has joined #amaranth-lang
<galibert[m]>
Is there information on how to go about proving stuff in amaranth. Like the arbiter enhancement I’m working on?
<whitequark[cis]>
not really at the time
<charlottia>
there's the amaranth-exercises by robert someone, which worked as a tutorial for me.
<whitequark[cis]>
the formal interface has been in a bit of a flux; I've gotten more clarity on it earlier this year so I think I know what its final form could/should be
<charlottia>
yepyep. It is indeed targeting the current API (with Rose/Fell etc.), so it'll be out of date soon.
<galibert[m]>
Ok, interesting, thanks
<galibert[m]>
I think eventually some interfaces in -soc could provide the needed formal description for things like initiators and targets on a bus
<galibert[m]>
That could become really powerful
<whitequark[cis]>
yep, that would be nice; however it is extraordinarily difficult to do so
<galibert[m]>
It is? Damn
<galibert[m]>
Not that surprised, formal is hard, but damn
<whitequark[cis]>
yeah, I've seen Diego put so much effort into this, I don't think it's tractable for someone working in their spare time
<Guest46>
I’m renew around here and I’ve been looking at documentation. Collecting it that is
<Guest46>
Since I last looked, about 3 years ago, I can say that there’s a lot more of it around than there used to be
<Guest46>
and that it is higher in overall quality than it once was
<whitequark[cis]>
we're workin' on it!
<whitequark[cis]>
all of the additions are covered with documentation by policy before they're signed off as complete, so that helps
<Guest46>
I am working my way through it and trying to make sense of it at the moment but I do have a couple of screens worth of interesting links
catlosgay[m] has joined #amaranth-lang
<catlosgay[m]>
im down to potentially contribute somewhat to how formal looks in amaranth at somepoint (timeline depending a bit cos i do that for a job with the commercial tools atm and ndas, but that may not be the case soonish)
<catlosgay[m]>
but you are right that creating good quality VIP for buses etc can be a lot of work
<Guest46>
I have an aspiration to add to the useful pile of documents around Amaranth. I found Divio’s Documentation System post really helpful when thinking about what is necessary.
<cr1901>
Suppose you have my_initiator with a .bus attribute that is wishbone.Signature. Is the intended connection sequence connect(m, flipped(intr_1), my_initiator.bus)?
<cr1901>
Or in "real world code" are you always expected to do "dut.add(my_initiator.bus)"?
<cr1901>
I like the decoupling of the former approach, but I'm not sure that's a very ergonomic use of "flipped" (it's not forwarding an inner module to an outer one)
<jfng[m]>
my_initiator.bus would be an interface and not a signature, right ?
<cr1901>
Yes, I'm sorry.
<jfng[m]>
cr1901: i think so, for bus primitives like decoders etc
<cr1901>
So the latter case is always what you intended?
<cr1901>
(dut.add(my_initiator.bus))
<jfng[m]>
but for example, when wiring a bus arbiter to a decoder for a shared interconnect, one would connect()
<jfng[m]>
cr1901: .. i think so ?
<cr1901>
Okay, I think I have a better way to ask the question I'm actually trying to ask (sorry for the XY problem)
<jfng[m]>
right now, the idea is just that we have replaced records with lib.wiring primitives
<jfng[m]>
but the bus interfaces are more or less used the same way
<cr1901>
https://github.com/amaranth-lang/amaranth-soc/blob/main/amaranth_soc/wishbone/bus.py Within this file, when I grep for "flip", there are exactly 0 matches. This means that every usage of wishbone.Signature/wishbone.Interface within the bus module is a non-flipped signature. How do you use "connect()" with to e.g. connect an Arbiter to a Decoder without using flipped()?
<galibert[m]>
William D. Jones: remember that In() flips
<jfng[m]>
by default, the bus interface is directed from the initiator's point of view
<jfng[m]>
so you would do something like connect(m, arbiter.bus, flipped(decoder.bus))
<galibert[m]>
jfng: shouldn’t a decoder be a target?
<cr1901>
^was my follow up q
<jfng[m]>
perhaps the decoder's bus interface should be flipped by default
<jfng[m]>
yes
<galibert[m]>
Yeah it should
<cr1901>
galibert[m]: I guess the rationale for decoder not being flipped was to be able to pass an initiator bus straight to one of Decoder's methods, but...
<cr1901>
and connect straight to initiator bus*
<cr1901>
but there's no way to do that, AFAICT :P
<galibert[m]>
Plus you should get rid of the weird resizing but you agree with that already
<cr1901>
I feel like flipped() has more utility than forwarding interfaces, so indeed I'm starting to be glad that the name bikeshed settled on flipped() for somewhat parity with Signature.flip
<jfng[m]>
in this case, Decoder.add() should probably also require a flipped bus interface
<jfng[m]>
hmm, not sure about that actually
<jfng[m]>
yes, it must be flipped
<jfng[m]>
that stuff just gives me headaches..
<cr1901>
wishbone.FlippedInterface?
<cr1901>
jfng[m]: Directionality is hard. I desperately with it wasn't, but it is
Guest46 has joined #amaranth-lang
<cr1901>
or wishbone.DeviceInterface and "wishbone.InitiatorInterface = wishbone.Interface"
<cr1901>
Unfortunately I will not be here for Friday's meeting :.
<cr1901>
(prior engagement)
Guest46 has quit [Client Quit]
<whitequark[cis]>
you cannot inherit from FlippedInterface, it is a final class
<cr1901>
you don't have to
<whitequark[cis]>
and if you need to, that sounds indicative of a deeper issue in Amaranth
<cr1901>
call "flipped(self) within the DeviceInterface constructor"
<whitequark[cis]>
huh?
<cr1901>
Incomplete thought, ignore
<cr1901>
Why is "wishbone.DeviceInterface = flipped(wishbone.InitiatorInterface)" wrong?
<jfng[m]>
i prefer having only wishbone.Interface, and use flipped(wishbone.Interface) when necessary
<jfng[m]>
e.g. the Decoder.bus property would return a flipped wishbone interface
<cr1901>
jfng[m]: That's fine. I'm just worried that I'm using flipped() to go beyond it's intended purpose of forwarding (as described in RFC 2). I certainly don't _mind_ doing this tho.
<cr1901>
And if this is a bad use of flipped(), I'd rather be told now rather than later. (You also would need to know that buses you add via decoder.add() are flipped)
<cr1901>
(and error out otherwise?)
<jfng[m]>
<cr1901> "(and error out otherwise?)" <- i'm starting to think that `Decoder.add` should just accept both, as it depends on the context
<jfng[m]>
as it does currently
<cr1901>
yes. You could add another initiator to a decoder
<cr1901>
(although you can also have two different WB buses for that... one for the initiator side, one for the device side)
<cr1901>
>as it does currently <-- wait, how does it accept both?
<jfng[m]>
cr1901: no, it is a target in any case, from the perspective of the bus
<jfng[m]>
its direction depends on whether you are looking at it from the decoder side, or the peripheral side
<jfng[m]>
yes, it doesn't use connect() internally
<cr1901>
Right, that was my follow-up q. So the current usage of not needing flipped() is correct. It just took a conversation w/ you to make me realize it's correct :P
<cr1901>
not needing flipped() inside Decoder.add()*
<galibert[m]>
A target (decoder included) should have .signature = { "bus": In(wishbone.Signature) } and you're done
<_whitenotifier-f>
[YoWASP/runtime] whitequark 97b6f08 - [autorelease] Update Python version requirement to ~=3.8.
<galibert[m]>
Also there's a possible discussion to be had on whether on arbiter/decoder .add() you either should pass a bus or instead it returns a bus you connect() to
<_whitenotifier-f>
[YoWASP/runtime] whitequark 2d89db4 - [autorelease] Update wasmtime version requirement from <13 to <14.
<_whitenotifier-f>
[YoWASP/runtime] whitequark 68a33e6 - [autorelease] Rebuild for wasmtime-py 13.0.1.
<_whitenotifier-f>
[YoWASP/runtime] whitequark 70ec9cc - [autorelease] Update Python version requirement to ~=3.8.
<jfng[m]>
<galibert[m]> "A target (decoder included..." <- agreed, but first we need to sort out the current situation, where `memory_map` is assigned to an interface _after_ its creation
<jfng[m]>
this prevents us from just calling `create()` on a wishbone.Signature for a decoder bus interface
<jfng[m]>
(whereas it is straightforward for arbiters, like your PR does)
<galibert[m]>
Not sure where the memory map goes in the interface? I didn’t see that interaction in rfc#2
<galibert[m]>
(My lap has been taken over by the cat, I can’t open the pc)
<jfng[m]>
this problem is specific to amaranth-soc, and the solution (for me) should be to stop doing that
<whitequark[cis]>
good afternoon. it is time for our regular Monday meeting for the Amaranth language and standard library
<galibert[m]>
Yay
<jfng[m]>
oh, right
<whitequark[cis]>
today we have two nominated items but only one item on the agenda; I've had quite a busy day so I'll have to punt on some of the nominated ones
<whitequark[cis]>
I think this is the right change to do and it would probably not have negative downstream effects, but as it is technically breaking I'd like to hear any objections from those present
<cr1901>
I'm basically useless wrt to metaclasses. So I wasn't actively using that functionality within my code. No objections from me.
<jfng[m]>
i have never relied on this for anything, iirc
<jfng[m]>
merge
<galibert[m]>
Will you still detect unused Elaboratable?
<jfng[m]>
perhaps it was intended to make elaborate() an abstract method at some point ?
<whitequark[cis]>
cr1901: this means if you ever relied on @abstractmethod you will need to define metaclass on your own
<cr1901>
Nope, never used @abstractmethod
<whitequark[cis]>
jfng: I honestly don't remember. hm.
<whitequark[cis]>
we don't really have a clear position on whether we use @abstractmethod or not... in case of ValueCastable for example there's a different mechanism being used
<whitequark[cis]>
part of the problem is that you can't make a class method an abstractmethod
<whitequark[cis]>
ValueCastable is actually a slightly more appropriate place for using ABCMeta since ABCMeta was developed for a similar use case (collections.Iterable, etc) than Elaboratable, which just needs a method not implemented by default
<whitequark[cis]>
this code does not raise an error
<whitequark[cis]>
yeah; ABCMeta being limiting is why I think we're better off just not using it at all
<charlottia>
whitequark[cis]: it does on `B()`, though.
<charlottia>
B.f(), on the other hand, does not.
<whitequark[cis]>
but that doesn't matter if B() is never called, e.g. B is used as a shape
<charlottia>
yeah, this is a bit silly.
<whitequark[cis]>
we're literally better off defining a dummy implementation raising NotImplementedError, in no small part because that works better with typecheckers like pyright than pass at the end (I just fixed a related issue)
<whitequark[cis]>
the manual check in __init_subclass__ would have to be adjusted to check for a change from our base method rather than no method at all
<whitequark[cis]>
but that's it
<charlottia>
(that could be refactored with several other places, too.)
<charlottia>
looks like there's no real objection, and any actual presumably-rare breakage is easily addressed.
<galibert[m]>
So, merge? I'll abstain, I really don't have enough clue to have a decent pov
<_whitenotifier-f>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 9399367 - Deploying to main from @ amaranth-lang/amaranth@fcafad1f70fb6cd949902d1956cc42547ebb59ee 🚀
josuah has joined #amaranth-lang
Wanda[cis] has quit [Quit: Idle timeout reached: 172800s]