davidlattimore has quit [Ping timeout: 272 seconds]
sorear has quit [Ping timeout: 260 seconds]
jopdorp has quit [Ping timeout: 260 seconds]
sorear_ is now known as sorear
jopdorp_ has joined #symbiflow
futarisIRCcloud has quit [Ping timeout: 264 seconds]
davidlattimore has joined #symbiflow
futarisIRCcloud has joined #symbiflow
_florent_ has joined #symbiflow
goku12 has quit [Quit: WeeChat 3.0]
citypw_ has joined #symbiflow
Degi_ has joined #symbiflow
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
andrewb1999 has quit [Quit: Konversation terminated!]
andrewb1999 has joined #symbiflow
andrewb1999 has quit [Ping timeout: 264 seconds]
_whitelogger has joined #symbiflow
QDX45 has quit [Remote host closed the connection]
kuldeep_ has quit [Remote host closed the connection]
citypw_ has quit [Ping timeout: 268 seconds]
citypw_ has joined #symbiflow
hansfbaier has joined #symbiflow
hansfbaier has quit [Read error: Connection reset by peer]
<_whitenotifier>
[symbiflow-arch-defs] Xiretza opened issue #1973: symbiflow_write_xml_rr_graph toolchain wrapper is not installed - https://git.io/JtZpU
duck2 has quit [Quit: Ping timeout (120 seconds)]
duck2 has joined #symbiflow
sf-slack2 has joined #symbiflow
sf-slack has quit [Remote host closed the connection]
<lambda>
`make -C xc7/counter_test TARGET=arty_35` in symbiflow-examples fails with `ERROR: Assert `cell->parameters.empty()' failed in passes/techmap/abc9_ops.cc:781.`, even with symbiflow's yosys fork. commenting out line 158 in synth.tcl works, but it's rather ugly a fix.
<lambda>
after some digging with gdb, I found that it's erroring on a `CARRY4_VPR` cell, which indeed has parameters - I just don't know what part is to blame here
andrewb1999 has joined #symbiflow
josi7 has quit [Quit: josi7]
citypw_ has quit [Ping timeout: 268 seconds]
<Lofty>
kgugala_: quicklogic-design8-workaround has a workaround patch for the `bram` testcase; want me to include it in the quicklogic-sta branch?
<sf-slack2>
<kgugala> yep, it will be easier to test it that way
<sf-slack2>
<kgugala> thanks
<Lofty>
Done
<sf-slack2>
<kgugala> awesome, thanks
<Lofty>
kgugala_: Also, I fixed the bug in `scc -specify` for the present testcase. ABC9 still crashes, but at least `scc` detects the loop now.
<sf-slack2>
<kgugala> cool
<lambda>
could someone with a working conda/etc setup build the xc7 counter_test example for arty_35 and send me their top.json.pre_abc9.ilang? it's not part of the CI artifacts unfortunately
kgugala has joined #symbiflow
cr1901_modern has quit [Ping timeout: 264 seconds]
kgugala_ has quit [Ping timeout: 256 seconds]
sf-slack has joined #symbiflow
sf-slack2 has quit [Read error: Connection reset by peer]
<litghost>
So I'm unclear what is different beteween your setup and the CI's setup
<litghost>
failure*
cr1901_modern has joined #symbiflow
<lambda>
litghost: that's what I'm trying to figure out too - I'm using arch packages instead of all the vendored/pinned dependencies from conda though, so I don't really want to waste too many support resources for something that is clearly not the intended way of doing things
<litghost>
lambda: If you can replicate when building from source, that should be enough to replicate the failure
<lambda>
yosys and vtr are built from source, don't have the RAM to build arch-defs unfortunately
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #symbiflow
<litghost>
lambda: That shouldn't be a problem. Your replication could be something akin to 1) build yosys from source, 2) build vtr from source 3) download a particular arch-def output 4) run this command, which generates assertion
<litghost>
Just provide exactly git hashes from yosys, vtr, arch-def URL etc
<lambda>
will do
<litghost>
And the commands you used to build and install the products
<litghost>
In theory, I should be able to replicate your failure same as you
<lambda>
I'm on yosys 54294957e (4 days old), arch-defs bff52005 (latest), vtr 991b11422 (latest) FWIW
<lambda>
so probably newer than is pinned in the conda configs
<litghost>
Have you tried yosys 2116c585?
<litghost>
If that works, then the assertion error is something that arose since then
<lambda>
I happen to have that exact commit packaged already, let me try
<lambda>
nevermind, have to rebuild anyway
<lambda>
yes, still happens with 2116c5858 - I'll write up more detailed build steps in an issue
<litghost>
Ok, thanks!
<litghost>
Suprising, will need to figure out what is going on. Thanks
cr1901_modern has quit [Quit: Leaving.]
cr1901_modern has joined #symbiflow
kgugala_ has joined #symbiflow
kgugala has quit [Ping timeout: 264 seconds]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #symbiflow
andrewb1999 has quit [Quit: Konversation terminated!]
<mithro>
litghost: Excited to see the progress here!
<litghost>
Hey it is all acomodi/kowalewskijan/tmichalak/dnltz doing the work!
<mithro>
Yeah, I'm excited to see dnltz doing the work here!
kraiskil has joined #symbiflow
* nickoe
just wonder how this bitstream reverse engineering really works in practice
<mithro>
nickoe: We document the bitstream to enable us to create compatible tooling. There is a pretty good description in the prjxray documentation.
<nickoe>
I mean I can read the readme in https://github.com/SymbiFlow/prjxray, but if I am sorta clueless about how to write a fuzzer, but I think that is more a problem of my experince / knowledge than the project docs :D