<povikMartinPovie>
what is this dispatch on cell_repr for? couldn't have it all been handled with the generic case?
<Wanda[cis]>
for slicing
<Wanda[cis]>
basically it computes bit-wise uses
<whitequark[cis]>
we do actually have CellRepr::slice now, but it's not even committed yet i think
<povikMartinPovie>
ah I see
<Wanda[cis]>
yeah we can simplify this pass with slice a little
<whitequark[cis]>
and it might not handle adc there anyway
<Wanda[cis]>
oh yes.
<povikMartinPovie>
so what's the preferred way of allocating per-net data inside a pass? can a contiguous array do?
<whitequark[cis]>
BTreeMap
<Wanda[cis]>
we just use a hashmap
<Wanda[cis]>
... or btreemap which is better in some circumstances, yes
<whitequark[cis]>
(BTreeMap if you iterate over it, HashMap if not)
<Wanda[cis]>
oh um
<Wanda[cis]>
thanks for the reminder I'll fix up lut lowering
<povikMartinPovie>
what's the idea with ChangeQueue?
<whitequark[cis]>
you don't want builder methods to take `&mut Design` because of infuriating lifetime issues
<whitequark[cis]>
so you queue updates to the netlist, then apply them in one go
<whitequark[cis]>
this has some other benefits too
<whitequark[cis]>
e.g. that's how we allow you to create a reference to a cell that's not yet been created (add_void())
<povikMartinPovie>
so is it just a device for working with Rust, or do you foresee using it in the flow for journaling, reverting changes in speculative optimization?
<whitequark[cis]>
kind of neither of those two options?
<povikMartinPovie>
:D
<whitequark[cis]>
you want something like apply() because in rust, design.add_not(design.add_not(...)) is invalid no matter what's your actual internal representation
<Wanda[cis]>
I mean, it also prevents fucking yourself over because one part of the pass sees inconsistent state because another part of the pass is in the middle of some work
<Wanda[cis]>
this came up all the time in yosys
<whitequark[cis]>
but it also lets you sta... yes, exactly
<whitequark[cis]>
i haven't wanted journaling at any point personally
<whitequark[cis]>
if you started building up some structure and then decided it's not worth it just leave it there to be cleaned up by the next call to compact()
<povikMartinPovie>
there may be little use for it in fpga flows; I've seen it being useful in physical optimization in asic flows since updates are done in place, and they have both downstream and upstream influence, so being able to revert to a known-good state at any point helps
<_whitenotifier-4>
[prjunnamed/prjunnamed] wanda-phi 4fe8c0b - Fix root cell set in split pass.
leocassarani[m] has joined #prjunnamed
<leocassarani[m]>
Hello! This is such an exciting project
<leocassarani[m]>
Is the plan to support parsing Verilog into a netlist, or go straight from Amaranth?
<Wanda[cis]>
very long-term, we'd wish to have a proper Verilog frontend
<Wanda[cis]>
however, for the near future, the frontend options will be Amaranth via direct unnamed IR export, or anything supported by yosys via JSON import
<Wanda[cis]>
Verilog elaboration is ... well, let's just say it's not a fun thing to write
<leocassarani[m]>
Yeah, I can imagine
<Wanda[cis]>
actually I could probably just write Verilog elaboration without too much pain
<Wanda[cis]>
the problem with that is that then inevitably people start wanting SystemVerilog features
<leocassarani[m]>
How much Verilog pre-processing do you need Yosys to do before you get a compatible netlist you can use as a JSON input? e.g. proc, flatten, etc?
<Wanda[cis]>
and retrofitting those to something that started as plain Verilog elaboration is what kills you
<Wanda[cis]>
(yosys failed at it hard)
<leocassarani[m]>
Pre-processing is the wrong word I guess -- I really just mean Yosys passes
<Wanda[cis]>
proc, tribuf, flatten, some memory_* passes
<leocassarani[m]>
Nice, that's fewer passes than I thought
<Wanda[cis]>
these are basically the passes that should've been part of the Verilog frontend in the first place (except flatten)
<leocassarani[m]>
Yeah, I'm sure there are good reasons for it but I've always found it bewildering that you need a separate proc pass before you can actually see what your design is doing
<whitequark[cis]>
the reasons are in fact not that good
<whitequark[cis]>
i've previously brought this up at yosys dev JF that we should just automatically run proc if needed, basically
<povikMartinPovie>
I agree, and I've gotten the rest of the team to agree
<povikMartinPovie>
now it's a question of someone writing the PR, I will merge it
<whitequark[cis]>
oh, neat
<whitequark[cis]>
I will not be writing this PR :D
<whitequark[cis]>
should've asked sooner
<povikMartinPovie>
no prob, someone else will
<Wanda[cis]>
leocassarani[m]: so one of the yosys original sins is actually that it's based on Verilog
<Wanda[cis]>
a lot of Verilog details leak out everywhere in the IR
<Wanda[cis]>
causing all sorts of trouble
<Wanda[cis]>
basically Verilog is not a good thing to base your IR on.
<Wanda[cis]>
one, there's no clean separation of concerns between the actual frontend and later passes
<whitequark[cis]>
yeah. "decision trees" are a good and necessary thing to have in your IR. "processes" are just, not
<Wanda[cis]>
second, there's things like zero/sign extension in every cell, init values being stored separately from their DFFs, memory ports that start out as async and are fixed up back to sync by a later pass, ...
<leocassarani[m]>
Oh man, the init value thing
<whitequark[cis]>
the init value thing is completely unhinged
<whitequark[cis]>
elsewhere i've called it "probably the single worst design decision in yosys"
<leocassarani[m]>
I assume you're talking about how init values are stored with the netnames and not with the DFFs
<Wanda[cis]>
I have lost SO MANY HOURS of my life on this bullshit
<Wanda[cis]>
yes
<leocassarani[m]>
So fucked up
<povikMartinPovie>
whitequark[cis]: are they? will you have them in unnamed as part of the netlist? I see them as something that need not exit the frontend
<Wanda[cis]>
so. this is one major advantage of starting the project as basically amaranth's backend.
<Wanda[cis]>
the IR starts out clean.
<leocassarani[m]>
I was working on kind of a pure Rust CXXRTL over the holidays and I couldn't believe how long I had to go without init values because it meant having to link netlists to dffs
<leocassarani[m]>
s/netlists/netnames/
<Wanda[cis]>
if I started this project as I originally planned, Verilog frontend first, I'd likely have my brain completely fucked by Verilog by the time I got to the actual synthesis part, and end up with Verilog-poisoned IR
<Wanda[cis]>
in fact that's kinda what happened with my first draft, years ago
<Wanda[cis]>
glad we rebooted the whole thing
<Wanda[cis]>
povikMartinPovie: optimizing decision trees is a useful and language-independent thing
<whitequark[cis]>
also, it is in general not possible to expand decision trees in a way that lets you collapse them back
<whitequark[cis]>
this is something that CXXRTL would greatly benefit from
<povikMartinPovie>
the question I wonder is, can't you optimize the mux tree just as well
<whitequark[cis]>
you remove information
<whitequark[cis]>
specifically, the choice of the column to eliminate from the decision tree to put into a mux is irreversible
<whitequark[cis]>
(and yosys makes a particularly stupid one)
<whitequark[cis]>
there's no canonicalization that lets you go from muxes to decision trees since there's an n:m correspondence between them
<whitequark[cis]>
also i'm pretty sure that "find minimal decision tree corresponding to this muxtree" is also np-complete
<Wanda[cis]>
btw, we're also somewhat likely to have an FSM cell in the early passes
<Wanda[cis]>
(perhaps even emitting the cursed thing directly some day in a future VHDL frontend)