le-million[m] has quit [Ping timeout: 246 seconds]
XgF has quit [Ping timeout: 246 seconds]
le-million[m] has joined #amaranth-lang
buganini has joined #amaranth-lang
XgF has joined #amaranth-lang
buganini has quit [Ping timeout: 246 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 260 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 248 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 246 seconds]
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 272 seconds]
_whitenotifier-3 has quit [Ping timeout: 245 seconds]
jjsuperpower__ has quit [Ping timeout: 248 seconds]
maikmerten[m] has joined #amaranth-lang
<maikmerten[m]>
hi there, I'm quite interested to give Amaranth a whirl (up to now I'm mostly a Verilog + Yosys on ice40 guy), but am somewhat worried regarding stability. The latest version being 0.5.1 (noticing the leading 0) should give me a hint that things may be very much still in flux, but wonder what more Amaranth-experienced people think.
<whitequark[cis]>
maikmerten: we have a fairly strong stability policy: if your code works on version 0.x, it will work on version 0.(x+1), albeit perhaps with warnings
<whitequark[cis]>
also, all language changes have to go through RFC process (similar to Rust), where you can provide feedback on any newly added or planned to remove features
<maikmerten[m]>
that sounds quite neat!
<whitequark[cis]>
more generally, we don't plan to radically change the language any more; we do have some changes planned to the core parts of the language (mainly clock domains), but they're mostly backwards compatible
<maikmerten[m]>
my primary reason for asking: I'm trying to get https://github.com/grahamedgecombe/icicle to work (which apparently was in a working state last year), but with the Amaranth-versions specified there things won't install, and when forcing 0.5.1 Amaranth will install fine, but the project won't generate Verilog
<maikmerten[m]>
so that gave an impression of things still moving somewhat fast
<maikmerten[m]>
(I assume referencing @main that's not best practice)
<maikmerten[m]>
s/that's/is/
<whitequark[cis]>
oh, icicle shouldn't be doing that, yeah
<maikmerten[m]>
I'm usually a Java guy (so everything introduced within the last 15 years is still "too new to be considered for production"), so Python is scary already ;-)
<whitequark[cis]>
isn't Python at least 7 years older than Java?
<whitequark[cis]>
re icicle: we only guarantee compatibility across released versions, even though main is pretty stable in practice
<whitequark[cis]>
if you're using git versions you should be using specific git revisions to make sure your code continues building; this isn't really specific to Amaranth
galibert[m] has joined #amaranth-lang
<galibert[m]>
python 1991, java 1995 fwiw
<maikmerten[m]>
yeah, Python is older, but the language core had breaking changes, which resets the "last breaking changes" counter to 0 days ;-)
<maikmerten[m]>
indeed, this is an icicle issue of being too lax when specifying its dependencies
<whitequark[cis]>
the way we do breaking changes is: we do break the langauge or stdlib if there are good reasons for it (evolution, inadequate APIs, etc) but we provide at least one, sometimes two, versions of grace period, and the breakage must have a "reasonable" migration path
<whitequark[cis]>
i.e. you might have to do some work, but this work should be fairly straightforward and not too cumbersome
<maikmerten[m]>
that sounds like a very good approach
<whitequark[cis]>
in many cases it consists of copy-pasting a deprecated module into your own code, for example. in others you may need to move some of your code around. very rarely you'd have to run a search&replace (we had an RFC recently that was like that, `reset=` -> `init=`)
<whitequark[cis]>
despite still being in 0.x version cycle and the fact that breaking changes do happen, I would consider the language maturing in its core concepts
<whitequark[cis]>
overall, we are currently getting to a place where we can release 1.0, which is a high bar: every public API must have both guide-level and reference-level documentation, all core concepts have to be in a place where we can support them either forever or at least for many years, and we just aren't there yet
<whitequark[cis]>
but piece by piece, we are arriving there; the simulator and amaranth.lib.io for example were two major jumps done this year, bringing us much closer to that goal
<galibert[m]>
Is domains overhaul a target for 1.0?
<whitequark[cis]>
yes, absolutely
<galibert[m]>
Nice
<whitequark[cis]>
I can't imagine supporting the current domain system forever
jeanthomas has joined #amaranth-lang
<whitequark[cis]>
how old is icicle anyway?
<whitequark[cis]>
5 years, wow
<maikmerten[m]>
ah, I think icicle doesn't like some Wishbone changes regarding "Interface" in amaranth-soc
jfng[m] has joined #amaranth-lang
<jfng[m]>
icicle hasn't been updated in a year and we had few breaking changes in bus interfaces since, so that would be plausible
<whitequark[cis]>
yes, Record (which was one of the biggest API mistakes in Amaranth 0.1) has finally been removed
<maikmerten[m]>
seems like a very sensible breaking change
<whitequark[cis]>
tl;dr Record tried to be both "a packed bunch of fields in a structure" and "an interface with ability of bidirectional connection"
<whitequark[cis]>
the API was a nightmare full of footguns
<whitequark[cis]>
the replacement is a lib.wiring interface, in case of Wishbone
<maikmerten[m]>
btw, big fan of having Wishbone as part of library. It's a bus I'm somewhat familiar with, having used it for my own little toy SOC: https://www.youtube.com/watch?v=cRvr-RU-Ct8
<jfng[m]>
very cool!
<whitequark[cis]>
from what I can see, the changes to icicle will need to be more than merely mechanical to bring it to 0.5+
<whitequark[cis]>
re Wishbone: it's unfortunately fairly underspecified and we've already ran into issues where it seems not possible to implement some functionality because the spec just doesn't say how to do it correctly
<whitequark[cis]>
AXI isn't used a lot in open source but I personally took a liking to it having understood it better recently
<whitequark[cis]>
for example nothing in Wishbone says how rty or err are to be implemented. are they asserted together with ack? what is the phase relation if not? do they end the transaction?
<maikmerten[m]>
the WB spec sadly seems to be abandoned
<whitequark[cis]>
also, in order to make a Wishbone interface cross clock domains, you basically have to convert it to AXI and back
<maikmerten[m]>
I think beta3 from 2002 (!!!) is still the latest version
<whitequark[cis]>
at which point why not just use AXI
<jfng[m]>
also, compatibility between "pipelined" and "classic" Wishbone interfaces is underspecified
<maikmerten[m]>
I remember having "fun" when switching my SOC from classic to pipelined mode
<whitequark[cis]>
honestly, the fact that there are two incompatible versions of Wishbone defined the way they are is already credibility-straining
<whitequark[cis]>
jfng: do you recall if there's one-way compatibility between them, or none at all?
<maikmerten[m]>
well, my attraction to Wishbone was mostly fueled by me having a vague sense of "understanding" the classic bus in a few hours of perusing the document. All I needed was one bus master and several devices and that appeared "doable"
<jfng[m]>
whitequark[cis]: i won't talk without my lawyer
<whitequark[cis]>
hahaha
<maikmerten[m]>
I assume that if one, e.g., needs transactions (is this a thing on busses?) and throws in some DMA engines, Wishbone may loose the appeal of simplicity, and go "nightmare of being underspecced"
<maikmerten[m]>
for silicon SoCs, it appears AXI (or AXI-Lite) has "won" the great bus wars
<galibert[m]>
Even with riscv?
<maikmerten[m]>
not sure if that spec comes with a "ARM now owns everything you have"-clause
<jfng[m]>
tilelink seems to be mostly used by sifive
<maikmerten[m]>
oh, things might be different with risc-v. There, I only know of one AXI SoC with RISC-V cores (the RP2350)
<palmer>
the RISC-V stuff is very AXI, it's just the coherence bits (IIRC called ACE) that are TileLink at SiFive
<maikmerten[m]>
and looking at providers such as Imaginationtech (PowerVR graphics) that pivot towards RISC-V, AXI also appears to be on their menu
<whitequark[cis]>
the AXI4 spec forbids you from building a non-ARM-licensed ARM ISA CPU
<whitequark[cis]>
* 2. LICENSEE hereby agrees that the licence granted in Clause 1 is subject to the following restrictions:
<whitequark[cis]>
(i) where a product created under Clause 1(i) is an integrated circuit which includes a CPU then either: (a) such CPU shall only be manufactured under licence from ARM; or (b) such CPU is neither substantially compliant with nor marketed as being compliant with the ARM instruction sets licensed by ARM from time to time;
<maikmerten[m]>
that's most unfortunate.
<whitequark[cis]>
it's not an "open source hardware" specification in the usual sense
<maikmerten[m]>
yeah, but doesn't (b) still grant a license, as long as the CPU-part is non-ARM? (which is still very non-open-source)
<whitequark[cis]>
yes
<whitequark[cis]>
it's just an anticompetitive clause
<maikmerten[m]>
that'd explain why RISC-V vendors don't shy away, but it's certainly a very unfriendly clause nonetheless
<palmer>
ya, and IIRC they backed that out for AXI-5?
<whitequark[cis]>
they being?
<palmer>
Arm. So you don't get the same quirk where you can build RISC-V cores with the newer AXI
<whitequark[cis]>
ah
<whitequark[cis]>
that doesn't look right, AXI5 has the same notice
<whitequark[cis]>
2. LICENSEE hereby agrees that the licence granted in Clause 1 is subject to the following restrictions:
<whitequark[cis]>
(i) where a product created under Clause 1(i) is an integrated circuit which includes a CPU then either: (a) such CPU shall only be manufactured under licence from Arm; or (b) such CPU is neither substantially compliant with nor marketed as being compliant with the Arm instruction sets licensed by Arm from time to time;
<whitequark[cis]>
looks word for word identical
<palmer>
ah, cool. I must have been thinking of some other thing
<jfng[m]>
this is a stricter superset than Wishbone, that removes the ambiguity
<whitequark[cis]>
subset?
<jfng[m]>
right, sorry
<galibert[m]>
wishbone-strict?
<jfng[m]>
"biblically accurate Wishbone"
<maikmerten[m]>
Wamabone
<maikmerten[m]>
or do it USB-style: Wisbhone 4 Gen 3.2 2x2 Data Delivery
buganini has joined #amaranth-lang
buganini has quit [Ping timeout: 244 seconds]
<mabl[m]>
<whitequark[cis]> "the AXI4 spec forbids you from..." <- How does that even work in Xilinx, where they try to sell you a softcore (microblaze) at any corner and now even have a RISC softcore (microblaze V)