<cr1901>
Oh I could've sworn you were already in this room, q3k :P
<q3k>
so did i
<cr1901>
When I switched to an IRC client w/ better autojoin, I stopped trying to keep all the rooms I'm in in my head. And it's only like 30 now
<cr1901>
(across 3 networks)
kraiskil has joined #yosys
<killjoy>
tmux -> weechat -> znc ftw.
<killjoy>
I don't remember any channels I'm in, or networks, or passwords, or whatever.
<killjoy>
I'm apparently down to 59 buffer windows though. I think my highest number was in the 120's.
emeb_mac has quit [Quit: Leaving.]
adjtm has joined #yosys
<q3k>
anyway i'm here because i'm debugging some wierd behaviour when doing synth_ecp5 w/abc9: seems like when yosys parses the resulting AIG and renames cells to $lutfoo / $lutbar[baz], it attempts to rename two different cells to the same name, thereby triggering an assertion
<q3k>
i've got stuck attempting to understand what exactly the aiger frontend is doing and why, so i guess i should just file an issue for it? problem is, i can't seem to even minify my test case well enough, attempts at simplifying cause the issue to not manifest then
<q3k>
as in, this is what happens after adding some log() based debugging:
<q3k>
Renaming $lut$aiger244019$22639 to $lut\qf100_frontend.forkDMem_fifoReqRAMA_rv$port1__read[36]
<q3k>
Renaming $lut$aiger244019$26516 to $lut\qf100_frontend.forkDMem_fifoReqRAMA_rv$port1__read[36]
<q3k>
a naive interpretation of what happening is that abc emits two different LUTs with their Y (iiuc, output) ports connected to the same net, and since the LUTs get renamed based on their outputting net (?) the assert fires
<q3k>
but that in turn implies that the netlist is junk, why would two LUTs have their outputs tied together?