<sf-slack4>
<arvindsrinivasan> Okay, sorry for the delay, I now built with the latest yosys and that version of plugins: `Yosys 0.9+3911 (git sha1 dcd9f0af, gcc 10.2.0-13ubuntu1 -fPIC -Os)` ```make: Entering directory '/home/arvindsrinivasan/Documents/GTRI/symbiflow-examples/xc7/counter_test' cd build/basys3 && symbiflow_synth -t top -v /home/arvindsrinivasan/Documents/GTRI/symbiflow-examples/xc7/counter_test/counter.v -d artix7 -p
<sf-slack4>
<arvindsrinivasan> I still get this error though
ByteLawd has quit [Remote host closed the connection]
ByteLawd has joined #symbiflow
<sf-slack4>
<arvindsrinivasan> @lofty, where did you get the 0.9+3833 version from?
<Lofty>
Arvind: it's from my personal fork of Yosys, but it works well enough
<Lofty>
So, I'm running `yosys -p "synth_xilinx -flatten -abc9 -nosrl -noclkbuf -nodsp -iopad -nowidelut" counter.v`, which is taken straight out of symbiflow_synth
<Lofty>
And it compiles cleanly
rj has joined #symbiflow
<sf-slack4>
<arvindsrinivasan> Hmm
<sf-slack4>
<arvindsrinivasan> So did you try to run the symbiflow_synth directly?
<Lofty>
I haven't, since there's a lot of stuff it needs that I don't :P
ByteLawd has quit [Remote host closed the connection]
<sf-slack4>
<arvindsrinivasan> Hmm okay
ByteLawd has joined #symbiflow
ByteLawd has quit [Remote host closed the connection]
ByteLawd has joined #symbiflow
<sf-slack4>
<arvindsrinivasan> Yes okay I can confirm taht behavior
<sf-slack4>
<arvindsrinivasan> So this is an issue with the symbiflow_synth script then?
<sf-slack4>
<arvindsrinivasan> Given I removed the calls by the script to hide its output, I saw this ```21.5.9. Executing ABC9_OPS pass (helper functions for ABC9). <suppressed ~2 debug messages> ERROR: Assert `cell->parameters.empty()' failed in passes/techmap/abc9_ops.cc:781.```
<sf-slack4>
<arvindsrinivasan> Specifically it seems to make these two yosys calls which I’m confused how you got `yosys -p "synth_xilinx -flatten -abc9 -nosrl -noclkbuf -nodsp -iopad -nowidelut" counter.v` from as I’m a bit unfamiliar with the tool ```yosys -p tcl /home/arvindsrinivasan/opt/symbiflow/xc7/install/share/symbiflow/scripts/xc7/synth.tcl -l top_synth.log
<Lofty>
The only thing that comes to mind is the "overwrite some models" step and the retarget step
<Evidlo>
anyone know of open source ethernet IP cores I could use on ECP5?
<Evidlo>
long term I'd be looking for 10GbE, but I'm struggling to find even 1GbE or slower
rvalles has quit [Read error: Connection reset by peer]
rvalles has joined #symbiflow
kraiskil_ has joined #symbiflow
kraiskil_ has quit [Ping timeout: 246 seconds]
kraiskil_ has joined #symbiflow
phire has quit [Ping timeout: 260 seconds]
phire has joined #symbiflow
kraiskil_ has quit [Ping timeout: 240 seconds]
epony has quit [Remote host closed the connection]
kgugala has quit [Quit: -a- Connection Timed Out]
kgugala has joined #symbiflow
epony has joined #symbiflow
citypw has joined #symbiflow
<gatecat>
Evidlo: liteeth supports 1GbE on ECP5. I don't know of anyone who's done 10GbE, 10GbE is about at the limit of what the ECP5 can do (particularly in terms of SERDES pin count if you want to actually do smthg useful with it)
Degi_ has joined #symbiflow
ZirconiumX has joined #symbiflow
TMM__ has joined #symbiflow
rvalles_ has joined #symbiflow
ssb_ has joined #symbiflow
rvalles has quit [*.net *.split]
Degi has quit [*.net *.split]
TMM has quit [*.net *.split]
ssb has quit [*.net *.split]
Lofty has quit [*.net *.split]
Degi_ is now known as Degi
ZirconiumX is now known as Lofty
cr1901_modern has joined #symbiflow
kgugala_ has joined #symbiflow
kgugala has quit [Read error: Connection reset by peer]
TMM__ is now known as TMM
craigo has joined #symbiflow
<_whitenotifier-5>
[fpga-interchange-schema] gatecat opened issue #14: Inverter cell type - https://git.io/JtF47
epony has quit [Quit: upgrades]
citypw has quit [Ping timeout: 268 seconds]
rj has joined #symbiflow
epony has joined #symbiflow
<sf-slack4>
<arvindsrinivasan> Lofty, I guess what do you suggest at this point?
<sf-slack4>
<arvindsrinivasan> like I guess I could write my own makefile to support this process and not use the existing scripts
<Lofty>
Hmm.
<sf-slack4>
<arvindsrinivasan> Though I’m confused by how when you run it without the script it doesn’t give the error that I am able to get here
ssb_ is now known as ssb
Niklas[m] has quit [Quit: Idle for 30+ days]
<sf-slack4>
<arvindsrinivasan> Does anyone have recommendations for a project I can copy a good makefile from for this?
<sf-slack4>
<pgielda> I do not see honestly how rewriting it as a new Makefile should help. especially if you plan to take it from another place...
<sf-slack4>
<pgielda> also contrary to what Lofty says I would not say that "my personal fork of Yosys, but it works well enough" is a great approach if you expect anyone to reproduce the problem
<Lofty>
pgielda: which is why I also tested with Yosys master
<sf-slack4>
<pgielda> You have to define Yosys master
<sf-slack4>
<pgielda> which has changes that YosysHQ does not have
<sf-slack4>
<arvindsrinivasan> Okay, so I can confirm the version I tried was the one Lofty recommended
<sf-slack4>
<arvindsrinivasan> 0.9+3911 and it had the same issue with ABC9_ops
<sf-slack4>
<pgielda> I mean its fine to use anything anyone wants, I just mean that the toolchain is tested against a different repo
<sf-slack4>
<arvindsrinivasan> I’ll try building the one for symbiflow yosys now
<sf-slack4>
<pgielda> also symbiflow-examples is hooked to a specific commit for those repos
<sf-slack4>
<arvindsrinivasan> Yes I tried to build that commit
<sf-slack4>
<arvindsrinivasan> except I encountered the error that I’ve been trying to debug for a while now
<sf-slack4>
<pgielda> there is a CI in symbiflow-examples
<Lofty>
pgielda: I am pretty confident that SymbiFlow did not change ABC9 in any fundamental way
<sf-slack4>
<arvindsrinivasan> The issue I’m having is CI uses conda for its packages
<sf-slack4>
<pgielda> Sure, but why use something else while hunting a bug?
<Lofty>
But it certainly doesn't hurt to check if the version can be reproduced with YosysHQ master
<sf-slack4>
<pgielda> I mean if there is a bug with conda
<sf-slack4>
<arvindsrinivasan> and I’m trying to not rely on conda but build my own version
<sf-slack4>
<pgielda> it would make sense to try to only have one moving piece
<sf-slack4>
<pgielda> (I am not saying its impossible that there is some kind of a bug, e.g. something wrong with conda packaging etc, but then it has to be proven somehow)
<sf-slack4>
<pgielda> preferably with an issue that proves it by providing a set of instructions
<sf-slack4>
<pgielda> that can be run in a container
<sf-slack4>
<pgielda> and show the issue
<Lofty>
pgielda: to me that moving piece is SymbiFlow's fork of Yosys, and to control the baseline should not be the SymbiFlow fork but the upstream codebase
<Lofty>
pgielda: also, arvind did exactly that
<Lofty>
(and thank you, arvind, for that)
<sf-slack4>
<pgielda> You mean there is an issue?
<sf-slack4>
<pgielda> I might have overlooked it
<Lofty>
I mean there are steps pasted in the backlog to reproduce
<sf-slack4>
<pgielda> beacuse chat is lossy, it will disappear in few days, covered with new conversations. If there is a bug it would make sense to open the issue on github (unless its already there and I've overlooked it)