<leocassarani[m]>
Ooh, I like the *n repetition syntax!
<Wanda[cis]>
it's pretty useful for eg. memory write masks
<Wanda[cis]>
(which are currently annoying me a fair bit as I'm writing memory lowering tests)
<leocassarani[m]>
I was thinking also if a signal is undriven then X*len is going to be nicer than XXXXXXX…
<galibert[m]>
We hates X
<Wanda[cis]>
we're also considering converting the mux cell to be fully bitwise
<Wanda[cis]>
and this make the display of that thing be not completely horrible for the common case of single-net-selection muxes
<Wanda[cis]>
but we may back out of that one yet, as it's not clear whether bitwise muxes are all that useful (they come up in memory lowering because of write masks, and it's not clear where else)
<Wanda[cis]>
galibert[m]: can I ask you to stop making irrelevant remarks? this is tiresome.
<Wanda[cis]>
leocassarani[m]: yeah, compressing long runs of all-0 / all-1 / all-X consts is also something I'd like to do, but I'm not sure how to decide on the cutoff here
<Wanda[cis]>
(also const printing and parsing goes through separate paths)
<mei[m]>
datapoint: 5 and above is guaranteed to not make things longer
<mei[m]>
and "up to 4 gets printed as is" is a nice number
<Wanda[cis]>
wasn't it 3?
<Wanda[cis]>
we uh.
<mei[m]>
assuming you want to detect runs in the middle of things
<mei[m]>
in which case you need to account for spaces
<Wanda[cis]>
oh.
<Wanda[cis]>
yeahhh this is where the usefulness gets unclear
<Wanda[cis]>
if we start shortening repetitions in the middle of a constant, we run a risk of making the IR harder to read instead of easier
<Wanda[cis]>
consider: you may want to copy-paste the raw binary value to python or something
<leocassarani[m]>
Yeah I think the point of something like 1*16 is to make it clear that every single bit in this 16-bit signal is 1, for mixed signals introducing concatenation would probably make things harder to understand
<leocassarani[m]>
But maybe the fact that there isn't a clear universal rule for this is a sign that it's not worth introducing this yet
<Wanda[cis]>
yeah
<Wanda[cis]>
I'm not sure if the rules as-PRed aren't too aggressive already, btw
<Wanda[cis]>
%123+4:5*6 is... not that pretty to read
<Wanda[cis]>
and then there's the ugly edge cases (like the two last ones in my commit message) where it's unclear how to pattern-match the value into repetitions vs. slices
<Wanda[cis]>
(as originally discussed with Cat irl, repetitions would apply only to single nets, at least for printing; I implemented it for multi-bit chunks mostly so we could discuss its usefulness, I'm not actually convinced it's useful)
<jix>
fwiw I added bitwise muxes to yosys because I needed them for the xprop pass that allows you to run FV with x propagating semantics, but that's not a synthesis usecase
<Wanda[cis]>
jix: ohhh I see; I was wondering about that, thanks
<leocassarani[m]>
As a point of feedback about your PR description, I got a little mixed up with your %123+1:4 example because it could legitimately be interpreted either as "take 4 bits" or "the msb is at index 4"
<jix>
iirc povik had a use for bitwise muxes in yosys-slang too, though
<Wanda[cis]>
yeah, hence the example
<Wanda[cis]>
that's hm
<Wanda[cis]>
I suppose it's also up for discussion
<Wanda[cis]>
I do like being able to see the chunk width at a glance
<leocassarani[m]>
Yeah I think you've probably chosen the better option of the two, but if you rephrased it as %123+2:4 = bits 2–5 that would eliminate the ambiguity
<Wanda[cis]>
yeah good idea
<_whitenotifier-4>
[prjunnamed] wanda-phi synchronize pull request #11: [RFC] netlist: accept and print fancier value slices and repetitions. - https://github.com/prjunnamed/prjunnamed/pull/11
<jix>
iirc also masked writes, but to registers in general, not memory
<jix>
but I might be misremembering details
<Wanda[cis]>
oh.
<Wanda[cis]>
riiight
<Wanda[cis]>
because slice assignments are a thing
<Wanda[cis]>
btw I'm not quite happy with the lowering we used for those in Amaranth
<Wanda[cis]>
(basically an assignment to a var-slice gets converted to a switch over every possible useful value of the selector, with an assignment to a const-slice in each branch)
<Wanda[cis]>
but I couldn't really justify anything better at that point because we had to work within the confines of what could be lowered to RTLIL processes, and those don't support var-slice assignments
<Wanda[cis]>
a previous unnamed IR draft had an "insert bitfield" cell for that purpose
<Wanda[cis]>
but I suppose shl + shl + bitwise mux would work too?
<jix>
and do_assign emits a $bwmux if the mask isn't constant
<jix>
so it's what you just suggested
<Wanda[cis]>
mhm
<Wanda[cis]>
yeah, that makes sense
<jix>
(found this by searching for the single use of bwmux and hadn't looked at any of the yosys-slang code before, that's all context I have)
<Wanda[cis]>
... I see my demux cell is also getting some use, heh
<Wanda[cis]>
we don't have that one in unnamed, and I'm wondering whether I should just use the match cell instead
<Wanda[cis]>
it's kinda obviously a superset of its capabilities
<Wanda[cis]>
(as it stands, the memory lowering code just emits a lot of eqs right now, mostly because I'm still not sure of the pass ordering)
<mei[m]>
didn't you say that the memory lowering will make use of the fact that match outputs are one-hot
<mei[m]>
therefore memory lowering must occur before decision tree lowering
<mei[m]>
therefore memory lowering can freely emit additional matches
<Wanda[cis]>
yeah that's most likely what's going to happen
<Wanda[cis]>
though there were also other ideas
<Wanda[cis]>
such as the match pass emitting some sort of "a is exclusive with b" and "a implies b" annotations into the netlist
<Wanda[cis]>
hmm
<Wanda[cis]>
so the last 2h is kind of a blur and I'm not quite sure how it happened but it seems I have a SiliconBlue BRAM lowering pass in front of me
<galibert[m]>
sometimes those things just happen
<Wanda[cis]>
now, how the fuck do I test this
<mei[m]>
<Wanda[cis]> "such as the match pass..." <- i feel like this is gonna be a pain. you'd probably want something like the Debug cell semantics, so that the annotations aren't keeping things alive for no reason, but then if you have "a implies b" and "b implies c" and then b becomes unused, garbage collecting it will lose the information that "a implies c"
<Wanda[cis]>
this would be easier if we had any sort of models for these cells
<Wanda[cis]>
looks at the glasgow to the right orrrr I could do it the YOLO way
<galibert[m]>
well, real hardware is the ultimate test after all
<mei[m]>
so, how does actually generating bitstreams look at the moment? do you defer p&r and bitstream generation to yosys for now?
<Wanda[cis]>
to nextpnr
<Wanda[cis]>
yosys is not involved anymore
<Wanda[cis]>
okay I screwed up something in swizzle selection
<Wanda[cis]>
oh. it works better when I set it to minimize the mapping cost instead of maximizing it.
<galibert[m]>
huhu
<Wanda[cis]>
hmm from a glace at the output for a few cases, it seems to actually work?
<Wanda[cis]>
including the weird cases where I have to artificially create a wide write port
<galibert[m]>
excellent, congrats
<Wanda[cis]>
too bad I never implemented Amaranth RFC 56
<Wanda[cis]>
idk I just read through the language guide then sat down and started writing prjcombine
<Wanda[cis]>
(it's kinda why the earliest parts are ... weird)
<mei[m]>
yeah, kinda same. i read through the rust book in 10m increments during breaks in high school and rotated it in my mind until I felt confident enough to just start writing a project with it
<Wanda[cis]>
holy shit that was Dec 2020
<Wanda[cis]>
oh. right. I started this shit because I got fired from a job.
<Wanda[cis]>
how fitting
<galibert[m]>
Damn
<Wanda[cis]>
(for context: Q4 2020 was when Edmund decided to fire literally everyone in SymbioticEDA, rehire an asshole who was fired by Claire for transphobia, and pivot to making [redacted] instead of developing yosys; this led to YosysHQ being founded a few months later)