| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 01:08 | |
| *** Degi_ <[email protected]> has joined #litex | 01:34 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 248 seconds) | 01:35 | |
| *** Degi_ is now known as Degi | 01:35 | |
| *** ElfenKaiser <ElfenKaiser!~deadsalmo@2a0a-a541-7975-0-b37f-5d86-29c9-d62b.ipv6dyn.netcologne.de> has quit IRC (Quit: Konversation terminated!) | 01:52 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 02:05 | |
| *** TMM_ <[email protected]> has joined #litex | 02:05 | |
| *** sakman_ is now known as sakman | 02:46 | |
| *** indy_ is now known as indy | 03:56 | |
| *** lexano <[email protected]> has joined #litex | 03:59 | |
| *** Melkhior_ <Melkhior_!~Melkhior@2a01:e0a:1b7:12a0:225:90ff:fefb:e717> has joined #litex | 04:26 | |
| *** Stary_ <Stary_!Stary@hacksoc/infrastructure> has joined #litex | 04:29 | |
| *** mupuf <[email protected]> has joined #litex | 04:29 | |
| *** Melkhior <Melkhior!~Melkhior@2a01:e0a:1b7:12a0:225:90ff:fefb:e717> has quit IRC (*.net *.split) | 04:35 | |
| *** Stary <Stary!~Stary@hacksoc/infrastructure> has quit IRC (*.net *.split) | 04:35 | |
| *** whitequark[cis] <whitequark[cis]!whitequa_1@2a01:4f8:c012:5b7:0:1:0:4> has quit IRC (*.net *.split) | 04:35 | |
| *** mupuf_ <[email protected]> has quit IRC (*.net *.split) | 04:35 | |
| *** whitequark[cis] <whitequark[cis]!whitequa_1@2a01:4f8:c012:5b7:0:1:0:4> has joined #litex | 04:42 | |
| *** jersey99 <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 05:23 | |
| *** FabM <[email protected]> has joined #litex | 06:16 | |
| _florent_ | whitequark[cis]: When using "do_finalize" method of a Migen Module, the submodules are finalized (and I use this when I need logic to be dynamically generated, sophisticated preprocessing), but concepts are indeed different and only doing one elaboration phase in Amaranth is probably simpler/cleaner. | 06:56 |
|---|---|---|
| whitequark[cis] | _florent_: What doesn't work is adding a submodule *somewhere else in the design tree* | 07:01 |
| whitequark[cis] | That was one of the bugs in Migen that led me to abandoning that design entirely, because there is no way to meaningfully resolve this and have a well defined finalization order still | 07:01 |
| whitequark[cis] | jersey99: there is no AutoCSR in Amaranth. the syntax for creating and adding a CSR is lightweight enough introspection isn't necessary | 07:02 |
| _florent_ | whitequark[cis]: ok thanks, do you have practical example for the this limitation? (sorry still waking up and not sure I encountered this limitation). | 07:14 |
| whitequark[cis] | iirc it was in Glasgow where an applet would run do_finalize, and it held a reference to a multiplexer elsewhere, which would create a per applet module | 07:16 |
| whitequark[cis] | so if the applet would finalize before the multiplexer, everything worked out fine | 07:16 |
| whitequark[cis] | and if it was after, the wires would silently be disconnected | 07:16 |
| whitequark[cis] | after debugging that I was incensed and together with the issue where there was no async reset (another thing that made one of core Glasgow features outright impossible) decided to just rewrite the whole thing more competently | 07:17 |
| whitequark[cis] | though it took some more time to actually do it | 07:17 |
| whitequark[cis] | the core problem with Migen (and MiSoC) is that they were never designed, it is just an amalgamation of features someone needed (in some cases just once) rather than a coherent system with a high-level goal and structure | 07:18 |
| whitequark[cis] | core technological problem, that is | 07:18 |
| *** cr1901_ <cr1901_!~cr1901@2601:8d:8600:226:15db:99dc:8bfc:3735> has joined #litex | 08:47 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:226:4455:6f46:4ebc:3999> has quit IRC (Ping timeout: 248 seconds) | 08:51 | |
| _florent_ | whitequark[cis]: ok I see. For Migen/MiSoC, let's say that LiteX or Amaranth would not even exist without this amalgamation, this was a completely different approach in HDL design that had to be explored and now improved or re-designed through newer projects. At the time, it was also mostly self-funding development and funding was also coming almost exclusively from projects created with the tools. | 12:12 |
| whitequark[cis] | considering that I worked for Sebastien Bourdeauducq, I wish it did not existed, because people like him should not either. | 12:18 |
| whitequark[cis] | if anything, the purpose of Amaranth is to recoup the very personal cost I paid by spending a chunk of my life at M-Labs, a cost that no one should pay | 12:19 |
| whitequark[cis] | I wish you warned me when you've seen him courting me back at #qi-hardware of the kind of person he is, and I wish I never touched any part of this space in my life | 12:20 |
| whitequark[cis] | I don't expect you to understand. I only want to make it clear where I stand. | 12:22 |
| _florent_ | I perfectly understand, I also hard times with him, but only started to realized the situation when you were already involved for quite some time. | 12:27 |
| whitequark[cis] | I would not describe being treated worse than an object (people typically care about their tools, you see) as "hard times" | 12:28 |
| whitequark[cis] | I do not think you actually understand, to be honest | 12:29 |
| *** acathla <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 12:34 | |
| whitequark[cis] | if you did, you would not come and defend him to my face. | 12:35 |
| _florent_ | hard time is probably not the appropriate description indeed, but each time I was receiving a mail from him, it ruined my day and I was completely stressed for a few hours/days. | 12:35 |
| whitequark[cis] | now imagine how it would feel to have your life be completely dependent on him, to the point where he (and his transphobic south african buddy) are the only people you know in the entire country | 12:36 |
| whitequark[cis] | this was intentional, of course; so was paying just enough to stay alive, but never to save enough to be able to easily move on in life | 12:36 |
| whitequark[cis] | (I know because he bragged to one of the people I know--who he also abused--how much money his company has) | 12:37 |
| whitequark[cis] | it's a really straightforward strategy: find technically competent but socially isolated young people, hire, exploit until nothing left, throw in the trash, repeat | 12:38 |
| whitequark[cis] | pay lip service to being queer-friendly while in public and treat us like meat when he thinks no one is listening, too, while at it | 12:40 |
| whitequark[cis] | he made a point out of calling me "Catherine" because I have a large following, while calling a trans friend (who isn't well known) by the name she hates over and over. you have to be really narcissistic to believe no one would notice | 12:42 |
| _florent_ | hmm, I'm not defending him. I also paid enough personally from this "experience". I'm just saying: OK, he created Migen/MiSoC and introduced a different approached to HDL design, now let's just learn from this (technical and behavioral issues) and do something better! | 12:43 |
| whitequark[cis] | all right. I can get behind that | 12:43 |
| whitequark[cis] | the last ... year or so of Amaranth's evolution has consisted mostly of replacing behavior inherited from Migen with something that's much closer to what traditional programming languages do | 12:44 |
| whitequark[cis] | actually, one of my goals when making the very first draft of Amaranth was to do this back in 2018 | 12:45 |
| whitequark[cis] | some of the things I genuinely did not anticipate being a problem and thought they were fine. some others I was pressured to ship ASAP | 12:45 |
| whitequark[cis] | the build/platform system suffered especially badly. I know it's one of the sticking points for LiteX migrating to Amaranth and I entirely agree, it sucks. I did my best to build something that works well in the very limited timeframe but wasn't especially successful | 12:46 |
| whitequark[cis] | one other component that has been a source of a huge amount of the technical debt is the fragment / AST rewriting system | 12:47 |
| whitequark[cis] | and the associated clock domain propagation logic | 12:48 |
| whitequark[cis] | this is actually a potential problem for LiteX migration because I plan to get rid of the clever Migen rules entirely and use a straightforward variable binding system instead, which is as old as ALGOL 60 | 12:50 |
| whitequark[cis] | in short: in the elaboration hierarchy, every scope (not module; scope) has a dictionary of "domain name" to "clock", "sync reset", "enable", "async reset" associated with it | 12:54 |
| whitequark[cis] | instead of modifying what's passed to it, things like DomainRenamer, ResetInserter, EnableInserter would all bind names in this dictionary (rebind in case of renaming, bind to old_rst|inserted_rst in case of ResetInserter, bind to old_en&inserted_en in case of EnableInserter) | 12:55 |
| whitequark[cis] | this makes it really easy to introduce local "clock domains" that are used just inside of one module (maybe you need to resynchronize something and that's it, like in AsyncResetSynchronizer which is expressible in Amaranth without any custom primitives), and also makes the whole thing a lot more structured | 12:59 |
| _florent_ | interesting, I think that's close to what I was also experimenting when doing some tests for an alternative HDL. | 13:00 |
| whitequark[cis] | it's very obvious if you have a good background in programming languages | 13:00 |
| whitequark[cis] | a lot of what I'm doing with Amaranth can be described as "making it boring" | 13:01 |
| whitequark[cis] | I think it's good to have a language that's as boring and usual as possible because then you can rely on this solid base to build exciting things | 13:01 |
| whitequark[cis] | which is I guess why you like the idea of it as a base for LiteX | 13:01 |
| whitequark[cis] | I've done a fair share of experiments myself, e.g. my Yumewatari PCIe stack that used a language-integrated parser, but they never went into Amaranth because they were too complicated and hard to use | 13:02 |
| whitequark[cis] | so for global clock domains, there would at least be a separate pass that plucks out all of the clock domains declared global (i.e. propagating up in the hierarchy) and defines them on the top module, while resolving naming conflicts | 13:03 |
| whitequark[cis] | which is necessary for compatibility | 13:03 |
| whitequark[cis] | the broad approach that Migen used for clock domains isn't that difficult to preserve but there are a lot of edge cases and I'm not thinking of investing too much effort into compatibility with something I think isn't designed very well in first place | 13:19 |
| whitequark[cis] | which is the part where LiteX could have issues in the future | 13:19 |
| *** cr1901__ <cr1901__!~cr1901@2601:8d:8600:226:9d3b:a53f:a76b:d5bd> has joined #litex | 13:27 | |
| *** cr1901_ <cr1901_!~cr1901@2601:8d:8600:226:15db:99dc:8bfc:3735> has quit IRC (Ping timeout: 246 seconds) | 13:30 | |
| _florent_ | thanks, all your efforts to simplify things are indeed going in the right direction. trabucayre just started working with me this week and together we should be able to spend more time on tests with Amaranth. | 13:31 |
| whitequark[cis] | thank you, I appreciate your feedback and the trust you place in me | 13:35 |
| whitequark[cis] | I'm pretty busy getting 0.4 out the door but after that I should be able to look into preserving the compat layer in a reliable way | 13:35 |
| whitequark[cis] | do you think it should be a part of the Amaranth org or of LiteX? | 13:35 |
| whitequark[cis] | I'm happy to offer/donate this work to the LiteX org since then you would be free to hack it to any of your needs or desires | 13:36 |
| whitequark[cis] | I also don't mind having it as a separate package in the Amaranth org | 13:36 |
| _florent_ | having it in LiteX could make senses yes, as you say to have the customize it/maintain it without taking using your time for this. And having control on this is also interesting to speed up adapting things when required. | 13:42 |
| whitequark[cis] | yes, exactly, especially the control aspect I think could really benefit LiteX | 13:47 |
| whitequark[cis] | I can see LiteX continuing to use the old syntax but adjusting semantics to have its own dialect and I think this could be beneficial in a number of ways, potentially | 13:47 |
| whitequark[cis] | okay, in that case, I will prepare the module as a standalone artifact and donate it to LiteX | 13:48 |
| whitequark[cis] | then you can do whatever you want with it, and the technical contract would only have upstream Amaranth in it | 13:48 |
| whitequark[cis] | this is also beneficial to me as the Amaranth language lead | 13:48 |
| _florent_ | great, having control on this intermediate layer is indeed an important aspect and this could also ease potential conversion to native Amaranth (would make it progressive). | 13:53 |
| whitequark[cis] | fwiw, the core idea with the 'new' compat layer is that it won't inherit from Amaranth's classes which at this point resemble Migen's more and more distantly | 13:54 |
| whitequark[cis] | but instead it would have entirely its own class hierarchy which uses Amaranth's ValueCastable to adapt it to what LiteX code expects from the HDL | 13:54 |
| whitequark[cis] | ValueCastable and ShapeCastable are a really powerful technique that let you use the HDL as a LEGO kit and assemble whatever you want out of it, even a completely different HDL | 13:55 |
| whitequark[cis] | I think it might be the single most important Amaranth innovation (though not the most important thing overall; for that I would say it is the diagnostics) | 13:56 |
| whitequark[cis] | for example, it allows having type-safe(-ish) enums, where the toolchain will error out if you are assinging to the wrong enum type without an explicit cast | 13:56 |
| whitequark[cis] | e.g. foo = Signal(EnumA); m.d.comb += foo.eq(EnumB.X) is prohibited if EnumA is an Amaranth enum and not a normal Python one | 13:57 |
| whitequark[cis] | I think complex codebases like LiteX could really benefit from additional safety like this | 13:57 |
| whitequark[cis] | I will most likely throw out the existing amaranth.compat layer entirely and instead take Migen's core modules and rework them to desugar down to Amaranth expressions | 13:58 |
| _florent_ | thanks, having you involved in this will clearly help a lot. BTW, as discussed during the call, happy to see how I can fund or help funding this work. | 14:02 |
| whitequark[cis] | that would certainly help; I have a lot on my plate but I'll work out how this can fit into the overall roadmap and in consideration of other responsibilities | 14:04 |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 252 seconds) | 15:07 | |
| *** so-offish <so-offish!~so-offish@2610:148:610:2b10::7d> has joined #litex | 16:35 | |
| *** cr1901__ is now known as cr1901 | 16:36 | |
| *** jk- <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 17:51 | |
| *** jk- <[email protected]> has joined #litex | 18:13 | |
| *** acathla <[email protected]> has joined #litex | 19:02 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 19:10 | |
| *** TMM_ <[email protected]> has joined #litex | 19:11 | |
| *** sakman_ <[email protected]> has joined #litex | 19:31 | |
| *** sakman <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 19:34 | |
| *** so-offish <so-offish!~so-offish@2610:148:610:2b10::7d> has quit IRC (Quit: Leaving) | 21:21 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!