<tpw_rules>
amaranth is not really a derivative of nmigen imnsho
<whitequark[cis]1>
mcc111: amaranth and nmigen are the same project under a different name
Degi has quit [Ping timeout: 248 seconds]
<whitequark[cis]1>
nmigen™ (note the trademark) is a fork of nmigen (note the lack of trademark) and in practice it's just a slightly modified older version
<whitequark[cis]1>
the reasons aren't actually that complex. i wrote nmigen originally in dec 2018 with essentially no external input, primarily to address the known documented issues with migen, as well as to fit my own needs for the Glasgow Interface Explorer; LambdaConcept provided additional funding and motivated additions to the project that were also designed and implemented almost entirely by myself
<whitequark[cis]1>
when it became popular and I chose to officially make it a community project under its own organization (this was originally motivated by the purely technical want to publish docs under the https://nmigen.github.io/ URL), my employer at the time (who wasn't actually paying me a salary when i wrote nmigen) decided they want in on the party and attempted to establish total control over the project through technical and social
<whitequark[cis]1>
means, because they believed they were entitled to it
<whitequark[cis]1>
i wasn't interested in negotiating with someone who did not value my wellbeing at the workplace and used technical and social means to regain control over the codebase where git annotate had my name next to almost every line of code and the design of which i chose myself (drawing ideas from migen)
<whitequark[cis]1>
later there was a trademark dispute, which i won (i still own https://github.com/nmigen) but which poisoned the name enough i chose to rename the project
<whitequark[cis]1>
hope this clears things up
<mcc111[m]>
Ok
<mcc111[m]>
Sorry to bring it up— I more or less understand the migen/amaranth relationship, although I guess I stated it wrong, was just trying to understand the litex/migen relationship
<whitequark[cis]1>
oh! litex used to be a vendored fork of migen, but florent eventually made migen be a dependency of litex instead
<whitequark[cis]1>
now that was a result of complex political and social factors i will not go into
<mcc111[m]>
Oh. Huh.
<mcc111[m]>
So how much would a litex file need to be doctored to work in amaranth?
<whitequark[cis]1>
okay, so this is a topic of ongoing work
<whitequark[cis]1>
there is the "amaranth.compat" module which was originally designed as a mechanical replacement for migen, i.e. you do a search-and-replace for import migen to import amaranth.compat and everything works.
<whitequark[cis]1>
however it was designed in a suboptimal way and since the main anticipated user (litex) never seemed to take advantage of it, i slated it for removal
<whitequark[cis]1>
when i did so, it turned out that litex is actually quite interested in it. after some discussion we decided that it will be re-engineered in a more principled and less fragile way with the amaranth features that weren't available at the time it was originally designed, and then made a part of litex
<whitequark[cis]1>
there aren't many, if any, anticipated users outside of litex, and being made a part of litex would be a boon for the litex project
<mcc111[m]>
<whitequark[cis]1> "there aren't many, if any..." <- ok. if litex and amaranth could integrate cleanly, i think that would make some of my anticipated use cases easier, as the area i'm stumbling around in (games) seems to have not much adoption of anything in amaranth's direct family tree but LiteX *does* seem to get used
<mcc111[m]>
…i think
FireFly has quit [Server closed connection]
FireFly has joined #amaranth-lang
nyanotech has quit [Quit: No Ping reply in 180 seconds.]
nyanotech has joined #amaranth-lang
jer_emy[m] has quit [Quit: Idle timeout reached: 172800s]
zyp[m] has quit [Quit: Idle timeout reached: 172800s]
<tpw_rules>
i mean i wouldn't consider my little demo adoption
<mcc111[m]>
<tpw_rules> "i mean i wouldn't consider my..." <- oh! i didn't know about your demo. what did you make?
DX-MON has quit [Server closed connection]
DX-MON has joined #amaranth-lang
notgull has quit [Ping timeout: 245 seconds]
notgull has joined #amaranth-lang
<mcc111[m]>
<mcc111[m]> "oh! i didn't know about your..." <- sorry, you mean your litex thing.
<mcc111[m]>
the demo is very cool, by the way. maybe i'll try it out later.
<mcc111[m]>
how does it (does it?) take input for the terminal btw? just usb keyboard on the dock?
<whitequark[cis]1>
mcc111: there is no timeline on amaranth<>litex integration work
GenTooMan has quit [Ping timeout: 258 seconds]
GenTooMan has joined #amaranth-lang
GenTooMan has quit [Ping timeout: 240 seconds]
<josuah>
mcc111[m]: I think this is more about using amaranth as a migen back-end, than using amaranth features in migen
<josuah>
LiteX uses an extended subset of migen... In the end more or less its own language on top of migen.
<josuah>
maybe the compat it will be completely absorbed by LiteX, with features added and removed
<whitequark[cis]1>
not "maybe"; this is the decision I made on amaranth.compat
<mcc111[m]>
<whitequark[cis]1> "mcc111: there is no timeline..." <- good to know
<mcc111[m]>
<josuah> "mcc111: I think this is more..." <- What I am interested in is incorporating LiteX components (terminology?) into an amaranth project, because there are many things like whole riscv chips that can just be packaged into your program if you're using litex
<mcc111[m]>
It seems(?) like amaranth is a slightly more sophisticated language, so being able to I/O cleanly with litex seems like the best of both worlds, get access to existing cpu cores, get to write your added components in the more expressive language
<mcc111[m]>
This is the only thing I know about litex, that people seem to use it for that purpose
<whitequark[cis]1>
there is no interoperability nor is interoperability planned at the moment
<whitequark[cis]1>
you export Verilog from Amaranth or LiteX and then hook it up in the other language
bob_twinkles[m] has quit [Quit: Idle timeout reached: 172800s]
GenTooMan has joined #amaranth-lang
GenTooMan has quit [Ping timeout: 248 seconds]
<cr1901>
mcc111[m]: Even if LiteX used Amaranth fully, at this stage I would treat LiteX as it's own ecosystem, where you're concerned w/ easily gluing a CPU to FPGA peripherals rather than _how_ those CPU and peripherals are glued together. This includes treating Amaranth as an impl detail in LiteX
zyp[m] has joined #amaranth-lang
<zyp[m]>
I wrote some magic for orbtrace because I wanted to be able to easily use luna with litex, so it's got some code that you can tell to hook together pairs of migen and amaranth signals, and it takes care of making an amaranth toplevel exporting those, generating verilog from it, loading it into a migen instance and hooking it up to the migen signals
<zyp[m]>
it's a hack, but it works, and it's way more comfortable than manually having to hook up generated verilog
<mcc111[m]>
<whitequark[cis]1> "you export Verilog from Amaranth..." <- but amaranth doesn't usually export verilog…
<mcc111[m]>
i'm not sure i care what's happening conceptually but in practice i want to be able to build an entire system from one build-script entry point, and if a module i want happens to be in litex i want to be able to use it without it being a pain
<mcc111[m]>
i don't think that's an unreasonable desire
<mcc111[m]>
if it becomes a pain, then that becomes an incentive to write in litex to begin with, especially if my design is other than the imported litex cpu cores relatively simple
<cr1901>
mcc111[m]: Semi-related, did your Python make implementation ever go anywhere?
<cr1901>
I would _love_ to replace LiteX's make dependency with a Python one since Make isn't usually avail on Windoze
<cr1901>
Also /join #litex, since I don't want to drag this channel OT
<mcc111[m]>
cr1901: Have joined.
<mcc111[m]>
Also, here was the make implementation, it worked *great* actually, it had a pool of test scripts, however I never documented it, and (wq made this point) a programming language without docs is functionally useless
<mcc111[m]>
The main reason I stopped working on it was the project that was originally its impetus went away (I stopped using Nim, and I originally needed it because of some Nim programs iwth complex builds)
<whitequark[cis]1>
mcc111: have you seen "doit"?
<cr1901>
Ack. Also, I don't see you on the IRC side in #litex, but maybe the bridge is delayed.
<whitequark[cis]1>
oh sorry I misread
<whitequark[cis]1>
cr1901: the bridge does not synchronize membership lists at all
<whitequark[cis]1>
mcc will only be present if she talks
<mcc111[m]>
Looks compelling, would it be in principle good at driving amaranth or litex builds?
<cr1901>
litex, yes, except for the picolibc dependency which requires ninja b/c it uses meson. Amaranth, I'm trying out pdm to drive everything (as in the template repo)
GenTooMan has joined #amaranth-lang
GenTooMan has quit [Excess Flood]
GenTooMan has joined #amaranth-lang
<whitequark[cis]1>
<mcc111[m]> "Looks compelling, would it be in..." <- we use it at ChipFlow for more complex SoC builds, yeah
<mcc111[m]>
Well, I'll be looking at that rather than my abandoned makeup then (advantage: I don't have to maintain it…)
<cr1901>
haha, indeed an advantage. I just didn't know about "doit"
<mcc111[m]>
The original advantage of makepy was originally that it was under a thousand lines and could be believably checked into a different repo instead of needing any kind of dependency management to install it, but if I'm writing in Python to begin with I can rely on pip…
<cr1901>
The log says it's installing "amaranth 0.1.dev1191+gca77de5", which definitely looks off
* cr1901
just found "[tool.pdm.overrides]"
<cr1901>
Woooooow, this is embarrasing. The solution was in the error message and I didn't even see it until I looked it up via Google. Disregard.
<cr1901>
(Answer is "use the [tool.pdm.resolution.overrides] table".)
<whitequark[cis]1>
oh TIL
<cr1901>
whitequark[cis]1: From the docstring, is amaranth_cli intended to be import-able (intent is to make my fusesoc gen a wrapper around amaranth_cli. A bit more elegant IMO to import and call main rather than subprocess)?
<cr1901>
s/From the docstring//
Raito_Bezarius has quit [Server closed connection]
Raito_Bezarius has joined #amaranth-lang
V has quit [Server closed connection]
V has joined #amaranth-lang
<whitequark[cis]1>
cr1901: no, not intended to be importable
<whitequark[cis]1>
oh, hold on
<whitequark[cis]1>
you're talking about calling main
<cr1901>
yes, call main from an existing python script just to avoid an unneeded "subprocess.Popen"
<cr1901>
absolutely nothing essential, just would be nicer for me
<whitequark[cis]1>
yeah that's perfectly fine
<cr1901>
Excellent, I'll play w/ the cli, integrate it into efbutils, and report feedback
<cr1901>
(integrate it as in "add parameters w/ typing annotations where necessary, so that the cli can generate the Verilog properly"