03:58 <whitequark[cis]> finalization is such a broken concept in Migen

03:58 <whitequark[cis]> (so broken that Amaranth does not have anything like it at all, intentionally, and never will)

04:14 <whitequark[cis]> the main problems with it is that (a) you only get one finalization order and if you don't like it, tough luck and (b) if you add another module to the tree in the finalizer, that one is never finalized

18:14 <jersey99> whitequark[cis] I hear you .. What is final and when is final. It's a hack, but it's been working. If we have distinctive phases of the transpilation with some sort of callbacks, that can be nice!

18:20 <whitequark[cis]> I actually think that is the wrong approach entirely

18:21 <whitequark[cis]> Amaranth only has one phase: elaboration. but before it, you can do whatever you want with the objects, so that they know exactly what to elaborate to

18:21 <whitequark[cis]> by the time you are in def elaborate, there should be no order dependence, no mutation whatsoever, nothing like that

18:22 <whitequark[cis]> if you are doing something really complicated that needs multiple phases of preprocessing? great! I am sure you can express that as a normal Python program better than I could anticipate :)

18:29 <jersey99> Like, how do you take care of automatic address assignment?

18:33 <jersey99> The HDL you write needs a phase where addresses need to be assigned, it would be great if they can even be used back inside the HDL as constants. There is a parse phase that would be useful here.

19:00 <jersey99> After thinking about it a little more, what I said can still be achieved with a single elaboration phase. The address assignment can be part of the elaboration stage and made available to the user at the end in some form

19:00 <jersey99> simplicity is good

19:01 <jersey99> Also, good to see you back. Is Amaranth a happening place these days?

19:23 <whitequark[cis]> you can look at the changelog

19:23 <whitequark[cis]> <jersey99> "After thinking about it a little..." <- nope

19:24 <whitequark[cis]> you assign addresses while constructing a representation of your design

19:24 <whitequark[cis]> this in no way relates to anything "HDL"

19:24 <whitequark[cis]> it's just manipulation of normal Python object

19:24 <whitequark[cis]> s/object/objects/

19:26 <whitequark[cis]> and if all you want to do is to e.g. write JSON metadata containing your SoC's addresses, you don't ever need to make any netlist or AST or anything like that

20:15 <jersey99> I am seeing that the philosophy is let the user figure out bells and whistles by empowering them with python object introspection. Is that right?

20:29 <jersey99> I am now actually curious to see how one would do something like Litex's AutoCSR around Amaranth

20:47 <jersey99> AutoCSR in Amaranth would be some form of a trait/MixIn where member functions of it would introspect and provide information about some submodules, and the address assignment be something that it would return (in the form of some some Amaranth objects) which then Amaranth can use to generate RTL

20:47 <jersey99> Looks promising!