<Degi>
Is there anything to help prevent "failed to find a route for arc 0" errors in nextpnr?
<ZipCPU>
Degi: I know there's been a lot of work on the router recently, so it might make a difference how up to date your version of nextpnr is in the first place
emeb has quit [Quit: Leaving.]
<mwk>
Degi: is your design near the capacity of the device?
<mwk>
if not, it could be a problem with dedicated routing paths
<mwk>
ie. some blocks connected the wrong way
<mwk>
what kind of net is it failing to route?
<mwk>
(also, please specify the fpga architecture)
<Degi>
Hm sometimes it was a ECLK signal, sometimes some logic signal, sometimes it works (I added -r --placer sa), the architecture is ecp5g-85k
<mwk>
so, intermittent failure? okay, that's... probably router quality issues
<Degi>
Its not really near the limit, there's still a bunch of space. I should try updating nextpnr sometime
<mwk>
upgrade nextpnr and/or ping daveshah
citypw has joined #yosys
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #yosys
qu1j0t3 has quit [Quit: WeeChat 0.4.3]
qu1j0t3 has joined #yosys
emeb_mac has quit [Quit: Leaving.]
Kamilion has quit [Ping timeout: 268 seconds]
Kamilion has joined #yosys
anticw has joined #yosys
anticw_ has quit [Ping timeout: 265 seconds]
dys has joined #yosys
m4ssi has joined #yosys
klotz has joined #yosys
twnqx has joined #yosys
<twnqx>
"ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc." is a pretty bad message for "gave a module fever signals than it requires"....
<twnqx>
shouldn't that throw a syntax error much earlier?
<twnqx>
or does yosys have some equivalent to gcc's -Wall -Werror
<daveshah>
The timing analysis is a bit dodgy, it shouldn't be an error at all usually
<twnqx>
well, i'd consider connecting 5 ports to a module that expects 7 at least worth a warning
<twnqx>
iverilog gives this: ledpwm.v:230: error: Wrong number of ports. Expecting 10, got 8.
<twnqx>
(ok, so 8/10, not 5/7, but still)
<daveshah>
I think Yosys will usually produce a warning for unconnected inputs at some point
<twnqx>
there's nothing from the verilog frontend with default parameters
<daveshah>
It wouldn't be from the frontend it would probably be from one of the check calls in synth_ice40
<twnqx>
and since i usually have my outputs at the end... it's unconnected outputs
<daveshah>
Oh
<daveshah>
Thats even stranger because I would expect the dangling logic to be trimmed
m4ssi has quit [Remote host closed the connection]
<daveshah>
Unconnected outputs are pretty common in more complex cases so I don't think they'd deserve a warning
<twnqx>
yeah, but i get inputs connected to inputs, with nothing driving them, failing the timing analysis
<tnt>
twnqx: there are plenty of modules / hw primitives that don't need all input connected
<daveshah>
Is this a noflatten flow or do you have any keep attributes?
<daveshah>
I have seen some timing analysis bugs around unreachable dangling logic before (thought they were fixed though) but I don't see where that dangling logic would come from
<daveshah>
opt_clean should trim it
<twnqx>
i'd say some used output with no driven input
<twnqx>
so it can't be removed
<twnqx>
anyway, i'll just use iverilog as a first pass input checker then
<daveshah>
But you are just doing synth_ice40, no noflatten or anything?
<twnqx>
yeah, no options - yosys -p "synth_ice40 -top top -json ledpwm.json" ledpwm.v
<daveshah>
Hmm, can you post ledpwm.v so I can sort out the nextpnr bug at least?
<twnqx>
it's so ugly i feel ashamed of it :/
<daveshah>
Well then nothing can be improved
_whitelogger has joined #yosys
develonepi3 has quit [Remote host closed the connection]
develonepi3 has joined #yosys
klotz has quit [Ping timeout: 240 seconds]
az0re has quit [Ping timeout: 240 seconds]
klotz has joined #yosys
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 260 seconds]
X-Scale` is now known as X-Scale
jakobwenzel1 has joined #yosys
jakobwenzel2 has joined #yosys
jakobwenzel1 has quit [Quit: jakobwenzel1]
jakobwenzel2 is now known as jakobwenzel1
klotz has quit [Quit: klotz]
citypw has quit [Ping timeout: 256 seconds]
az0re has joined #yosys
dys has quit [Ping timeout: 246 seconds]
dys has joined #yosys
gmc has quit [Ping timeout: 246 seconds]
gmc has joined #yosys
jakobwenzel1 has quit [Quit: jakobwenzel1]
SpaimaCarpatilor has joined #yosys
SpaimaCarpatilor has quit [Remote host closed the connection]
SpaimaCarpatilor has joined #yosys
klotz has joined #yosys
emeb_mac has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<ZirconiumX>
daveshah: Do you think Minimig (mini-Amiga) would be a good benchmark for Yosys-tests?
<daveshah>
Yosys-bench you mean?
<daveshah>
It's probably reasonable enough
<ZirconiumX>
Yeah
<ZirconiumX>
It'd need some amount of porting, since it targets a Xilinx chip by default I think
<daveshah>
I don't think it's valuable enough as a benchmark to be worth porting
<daveshah>
But if you want to port it to actually run it then why not
<ZirconiumX>
Lots of small modules makes for a useful flatten/noflatten comparison IMO
<daveshah>
Yes, a smaller case like that could be interesting
<daveshah>
The sparc, rocket and boom benchmarks are bigger cases of designs with lots of small modules