emeb_mac has quit [Read error: Connection reset by peer]
emeb_mac has joined #yosys
nak has quit [Ping timeout: 240 seconds]
nak has joined #yosys
GenTooMan has joined #yosys
nak has quit [Ping timeout: 250 seconds]
FabM has joined #yosys
FabM has joined #yosys
FabM has quit [Changing host]
bpye has quit [Ping timeout: 276 seconds]
emeb_mac has quit [Quit: Leaving.]
bpye has joined #yosys
bpye has quit [Ping timeout: 276 seconds]
bpye has joined #yosys
kristianpaul has quit [Ping timeout: 246 seconds]
kristianpaul has joined #yosys
bpye has quit [Ping timeout: 276 seconds]
bpye has joined #yosys
nak has joined #yosys
nak has quit [Ping timeout: 240 seconds]
vidbina has joined #yosys
nak has joined #yosys
nak has quit [Ping timeout: 250 seconds]
somlo has quit [Remote host closed the connection]
nak has joined #yosys
somlo has joined #yosys
<rowang077[m]>
Is it somehow possible to setup min/max delays and false paths in yosys or nextpnr? I'm working on a multiclock design and need some timing constraints on an async fifo synchronizer.
<rowang077[m]>
I can't find anything in the doc
<tnt>
nope
<rowang077[m]>
so multiclock is not supported? How do other projects handle this I see litex entire socs. I assume they must have multiple clock domains?
<tnt>
ATM it's sort of cross your finger and hope the placer put them close enough.
<tnt>
But there is no cross-clock analysis done at all.
<tnt>
it does _report_ the max delay in the report but you can't constrain it.
<rowang077[m]>
:( I see. That's unfortunate
<rowang077[m]>
Is this something that would be implementable in a few days? I could try my hand at it.
<rowang077[m]>
I'd wager from scratch would be a lot of work
<tnt>
I have no clue whatsoever tbh ... but for someone without good knowledge of how the current code works, I feel like it's a long shot.
<tnt>
gatecat would know better for sure
<gatecat>
yeah, even scoping it out would be more than a few days work tbh
<gatecat>
it will be done at some point but with my schedule being somewhat chaotic rn it's hard to help more than that
<gatecat>
unless you happen to have $50k in your back pocket ;)
<rowang077[m]>
haha I wish
adjtm has quit [Quit: Leaving]
<killjoy>
Frankly, yosys should have kickstarter campaigns for each feature request. The ones that get funded get implemented. :D
<tnt>
Not sure about kickstarter, but some official bounty system would be nice. No clue if there'd be enough support to be worth it but ... (also it's nextpnr for this particular case)
<lkcl>
rowang077[m], ls2 (a peripheral fabric i'm developing) has multiple clock domains and uses alex forenchich's async-wishbone
nak has quit [Ping timeout: 250 seconds]
<lkcl>
tnt: interesting to know that CDC isn't really part of the PnR, that's going to be fun
<lkcl>
does anyone know how to override a specific techmap?
<lkcl>
currently i'm compiling nextpnr-xilinx with -nocarrylut due to a limitation of yosys/nextpnr-xilinx/vtr/symbiflow
<lkcl>
there's only room for up to 23-26 CARRY4 blocks within the A7 FPGAs before you have to "cross over" to a different block
<lkcl>
translation: any add, sub, or cmp that's greater than around 96 bits is guaranteed to fail (in symbiflow/VTR) or to 100% lock up in nextpnr-xilinx
<lkcl>
solution:
<lkcl>
in a yosys techmap, instead of creating a naive CARRY4 chain, split the add/sub/cmp into sections of at most 96(ish) bits, with a manual carry-in carry-out bit
<lkcl>
that's context
<lkcl>
question, therefore:
<lkcl>
how do you override *just one* techmap file of standard techmap commands for a given synth command? (in this case, synth_xilinx)?
<lkcl>
i'd greatly prefer not to be running with a fork of yosys.
<lkcl>
that's a naive carry4-chain which is *too long* for A7-35t, 100t (and probably 200t) FPGAs, they can only handle 23-26 CARRY4s.
<lkcl>
several people have encountered this and are suffering (tolerating) a whopping 30% clock-speed drop by having to use LUT4/6s instead
vidbina has quit [Ping timeout: 260 seconds]
vidbina has joined #yosys
<jix>
not really my area, but is this something that should be handled at the techmap stage? isn't it just creating individual CARRY4 with CI/CO chained, i.e. there would be no difference to splitting the add and manually chaining carry between the split parts?
<lkcl>
jix: there's some debate about this. on the one hand, the _easiest_ way to do it is at the techmap stage
<lkcl>
on the other "it's supposed to be the P&R's job"
<lkcl>
in between, there's a really *really* nice piece of work by a pair of phd students that actually does an astoundingly awesome job of auto-generating some seriously optimal ASIC techmaps for add/sub/cmp, let me find it...
<lkcl>
now, it should be pretty obvious from the level of sophistication involved there that trying to teach VTR, nextpnr-ecp5, nextpnr-xilinx etc. etc. etc. how to do that astounding optimisation job is... ah.. not very sane/sensible? :)
<lkcl>
sure, you can, but by that point it's the equivalent of running disasm and hand-patching binaries, to try to desperately reconstruct the higher-level concept of the bit-level adders
<lkcl>
in order to run the *higher-level* concept of optimising the layouts, with parallel carry-propagation etc. etc. etc.
<jix>
hmm, I guess I'd go with "P&R should at least split long chains and not fail/deadlock, but if you want to do anything more fancy you need to do that before" then
<lkcl>
in a word, yes
<lkcl>
you should see the job that symbiflow does of attempting to adjust the naive-long-carry4-chains that yosys throws at it
<lkcl>
i mean, it works, but it's done by:
<lkcl>
* exporting to JSON
<lkcl>
* running a python script that searches through the Abstract Syntax Tree looking for patterns involving CARRY4
<lkcl>
* performs (in python) JSON DOM Node rewriting (in memory)
<lkcl>
* dumps the JSON file back out
<lkcl>
* calls a yosys script to re-import the JSON and convert it back to BLIF
<lkcl>
as you can probably guess, the time taken and the memory usage is astounding
<lkcl>
and it has to do that on the *output* of the yosys nextpnr-xilinx techmap, involving (by that point) about 5 or 6 separate and distinct blocks (CARRY4 being one of them)
<lkcl>
whereas if that job was done *by* the yosys techmap for xilinx arithmetic, it would have been done in a few milliseconds of CPU time.
<lkcl>
oh and then nextpnr-xilinx has to do the exact same job.
<lkcl>
duplicated developer effort, huge amounts of CPU power wasted, vast amounts of memory needed.
<lkcl>
or
<lkcl>
a simple optimisation of yosys techmaps could be done
<lkcl>
just a thought :)
<jix>
yeah I'm not arguing against improving techmap :)
<lkcl>
:)
<lkcl>
hence my question, i'd like to have a go at over-riding the techmaps, but without hard-forking yosys.
<lkcl>
in theory i could create an non-built-in command script which duplicates the contents of the synth_xilinx one?
<tpb>
Title: Yosys Open SYnthesis Suite :: Command Reference :: synth_xilinx (at bygone.clairexen.net)
<lkcl>
where the "fine" sub-command on that has this:
<lkcl>
techmap -map +/techmap.v [-map +/xilinx/arith_map.v] (skip if '-nocarry')
<lkcl>
that's the bit i'd like to override, i just don't know how
<jix>
lkcl: I guess you could compile a modified synth_xilinx pass as a loadable plugin? but I haven't looked into plugins besides "debugging" why the plugin test failed when linking with mold
* lkcl
ponders
<lkcl>
there's enough examples, it should be doable from cut/paste
<lkcl>
it does seem... how-to-say... somewhat overkill to have to write in c/c++ in order to override something like this
<jix>
I could've used an easy way to selectively override yosys's share files for something completely different
<lkcl>
ah yeah
<lkcl>
good point
* lkcl
wonders if there's a way to hook into that
<jix>
I didn't see one, adding one that replaces the share path completely wouldn't be too hard
<jix>
even better would be to have a list of search paths IMO, but I haven't looked into whether that can work without changing things all over the place
<lkcl>
yehyeh, but... nggggh forks. meh :)
<lkcl>
i like that. i mean, it's how python works (sys.path), and LD_LIBRARY_PATH, and etc.
vidbina has quit [Ping timeout: 246 seconds]
FabM has quit [Quit: Leaving]
<checkpoint>
guys, has anyone tried synthesizing for GW1NR chips (synth_gowin) ?