<whitequark>
using retiming to hide *global interconnect deays*
<whitequark>
this seems like it'd need nextpnr support
<daveshah>
I think that might be more for ASIC than FPGA
<daveshah>
from memory ASIC flows have much larger routing to logic delay ratios
<whitequark>
oh interesting
<daveshah>
logic delay only based retiming should be good enough for most FPGA cases
<daveshah>
not to say interconnect delay retiming won't be useful at all
<whitequark>
so i looked through the slides
<whitequark>
and
<whitequark>
it's literally the same basic graph manipulation as in FlowMa
<whitequark>
i can definitely implement it
<whitequark>
this guy is a genius. no normal person can do so many optimal algorithms *and* make them easy to implement
<swetland>
retiming feels like one of those things you want to have individual control over
<whitequark>
well either that or everyone else just sucks a lot
<daveshah>
ad retiming - the current Yosys/ABC retiming is badly broken, definitely need to think about improving things (this was going to be fixed in the abc/xaig stuff)
<daveshah>
right now it gives a separate netlist to ABC for each clock domain
<daveshah>
which seems sensible except "clock domain" includes different ce/sr too
<whitequark>
oh
<swetland>
as optimizations go, since shuffling the relative positions of logic vs registers feels like one of those "makes it harder to understand the final results and has opportunity for subtle effects"
<daveshah>
yes, that's why almost no flows - even vendor - have significant retiming enabled by default
<whitequark>
>h. By gradually increasing the depth bounds, we
<whitequark>
are able to produce a set of mapping solutions with smooth
<whitequark>
area and depth trade-off for a given design.
<whitequark>
oooh.
<sorear>
even asic flows you opt in retiming on a module by module basis
<daveshah>
that makes sense
<daveshah>
guess you might want it in say a filter pipeline, but definitely not in your control mcu
<sorear>
rocket does this for the FPU, much nicer to do a combinatorial FMA unit and stick four stages after it then to try to figure out where to put pipeline regs *inside* a FMA
<swetland>
yeah one thing I would love to see better support for is setting boundaries (at the module level) for certain classes of optimizations. just from a making-it-easier-to-reason-about-results standpoint. sure optimize the cpu and the peripherals, but don't start combining logic/registers or pushing bits of one into the other
<whitequark>
so, hierarchical synthesis?
<daveshah>
afaik at the moment that is in the realm of supported, but not well used enough to be bug free
<swetland>
I think so.
* swetland
will happily add it to his list of things to experiment with.
<daveshah>
I think some of the people doing ASIC stuff with Yosys have done fully hierarchical stuff
<daveshah>
should just be a case of adding -noflatten to synth_ice40; then flatten and opt_clean at the end to make a flat netlist for nextpnr
<swetland>
maybe more subtle if you want some hierarchies flattened
<swetland>
eg, cpu may be composed of 4-5 modules (regfile, decoder, etc) and I don't mind *them* being optimized together, just want to keep the top level components (cpu, peripherals, etc) from bleeding into each other)
<whitequark>
probably a (*flatten="always"*) attribute or something
<daveshah>
There is (* keep_hierarchy *) already
<daveshah>
> The keep_hierarchy attribute on cells and modules keeps the flatten command from flattening the indicated cells and modules.
<swetland>
but that makes nextpnr cranky, no? need to do some kind of force flatten as a final step perhaps?
<daveshah>
ah no, that's not quite the same thing
<daveshah>
yes, need `opt_clean; flatten` before netlist export
<daveshah>
nextpnr will support hierarchical netlists at some point, but imo we should get rid of the hand-written JSON parser first
<whitequark>
handwritten json parser....
<daveshah>
badly ripped out of Yosys too (don't @ me, not my code)
<whitequark>
daveshah: oh what the hell...
<whitequark>
FlowMap-r is ... trivial to implement
<swetland>
at least it's not xml ^^
m4ssi has joined ##openfpga
gardintrapp has joined ##openfpga
<whitequark>
and it also preserves all original network properties
<daveshah>
very nice
<whitequark>
ahaha
<whitequark>
>Experimental results show that the run time of SeqMapII for
<whitequark>
computing the optimal solutions is too long in practice (e.g.,
<whitequark>
more than 12 h of CPU time for a design of 134 gates on a
<edmund>
mwk: can you please send me your email address
<mwk>
edmund: mwk@0x04.net and I thought you had it already?
<gruetzkopf>
qu1j0t3: 1998-01 was the first month of ultra5 availability
<edmund>
mwk: Lost in translation :-)
<edmund>
You should have gotten an invite by email.
<qu1j0t3>
gruetzkopf: hm :)
<tnt>
whitequark: in glasgow, are unused pins force to 0 somewhere ?
knielsen has quit [Ping timeout: 240 seconds]
<tnt>
Mmm, looks like in the verilog io[n] (n being the unused IO) is not connected to anything ... and then yosys or nextpnr decides to make that 0 which is rather inconvenient.
emeb has joined ##openfpga
X-Scale has quit [Ping timeout: 244 seconds]
knielsen has joined ##openfpga
X-Scale has joined ##openfpga
GuzTech has quit [Ping timeout: 246 seconds]
GuzTech has joined ##openfpga
GuzTech has quit [Remote host closed the connection]
pie__ has joined ##openfpga
m4ssi has quit [Quit: Leaving]
<tnt>
mithro: btw, not sure if that's helpful at this stage but I wrote some hack to run sigrok PD inside gtkwave. Useful to debug USB probably.
<mithro>
tnt: that would be useful
<tnt>
mithro: do you have a .vcd for me to try it on to make sure it works with the usb pd first ? Then I'll send it along with how to run it. (gtk wave tends to be a bit picky and just plain freeze if you don't do thing exactly right)