<widlarizerEmilJT>
Is it expected that writing UIR out from Amaranth doesn't use slices? %96:34 = adc [ 0 %0+31 %0+30 ... as of amaranth 050afd00
<whitequark[cis]>
cc Wanda but i would just check the source
<whitequark[cis]>
i believe the amaranth backend prioritizes simplicity and so it doesn't use many of the more complex UIR features
Wanda[cis] has joined #prjunnamed
<Wanda[cis]>
mmm that's part of the reason
<Wanda[cis]>
but mostly
<Wanda[cis]>
it was written before we had slices
<whitequark[cis]>
oh
<widlarizerEmilJT>
I see
<widlarizerEmilJT>
a CXXRTL-like system for simulating prjunnamed without going to RTLIL would be fun right
<Wanda[cis]>
there's plans for that
<Wanda[cis]>
but without any particular timeframe, for now
<widlarizerEmilJT>
neat
<whitequark[cis]>
it wouldn't be that challenging to rewrite CXXRTL in prjunnamed
<whitequark[cis]>
but I want to fix the clocking-related issues that have plagued it
<Wanda[cis]>
you want CXXRTL2, not CXXRTL
galibert[m] has joined #prjunnamed
<Wanda[cis]>
a bit, but not really
<galibert[m]>
Yosis-induced?
<Wanda[cis]>
having a flattened hierarchy and no SigMap will fix some of it
<Wanda[cis]>
but there's more to it
<widlarizerEmilJT>
From a brief glance at the yosys issue tracker, is this about flop driving click inputs of other flops?
<whitequark[cis]>
anything but toplevel PIs
<widlarizerEmilJT>
Has the fact that Amaranth emits each instance of a module as a module of its own ever come up as a limitation for Amaranth-based designs when synthesized with yosys?
<whitequark[cis]>
no
<Wanda[cis]>
the RTLIL emitter does have to do some work to construct ports between modules, something that wouldn't be necessary for UIR
<Wanda[cis]>
which is something that, in prjunnamed, will have to be done in the Verilog backend (or any backend that needs proper hierarchy, really)
<Wanda[cis]>
but that's a rather minor thing
<Wanda[cis]>
and not a limitation
<widlarizerEmilJT>
so what I meant is that in Yosys unflattened flows you have more modules to synthesize. Since each module is synthesized without information about its instancing or what it instances, it doesn't net you any benefit, you're really doing the same work multiple times
<widlarizerEmilJT>
Not more work on the emission side
<whitequark[cis]>
but yosys flows start with proc; flatten?
<whitequark[cis]>
oh i see, "unflattened"
<whitequark[cis]>
i'm not sure if anybody is actually using those
<whitequark[cis]>
but more importantly, i think "verilog module" is the wrong boundary to split synthesis on
<whitequark[cis]>
the right boundary is something like "synthesis block", which in yosys is done by keep_hierarchy (rather than an unflattened flow) and in vivado is done by horrific EDIF hacks
<widlarizerEmilJT>
definitely
<whitequark[cis]>
but also consider
<whitequark[cis]>
if you have any genericism at all--something that is a given in amaranth or systemverilog code--then hierarchy will already duplicate modules even in yosys
<widlarizerEmilJT>
yeah, I was thinking about that, and how the Amaranth+Yosys status quo will allow you making use of even an output staying unused right
<whitequark[cis]>
if you really wanted it, you could find and merge identical modules, sure. (nobody is doing that as far as i know)