cr1901_modern has quit [Ping timeout: 265 seconds]
cr1901_modern has joined #yosys
Degi_ has joined #yosys
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
Cerpin has quit [Quit: leaving]
Cerpin has joined #yosys
pie_[bnc] is now known as pie
pie is now known as pie_
freemint has joined #yosys
freemint has quit [Ping timeout: 260 seconds]
Vinalon_ has quit [Ping timeout: 240 seconds]
freemint has joined #yosys
freemint has quit [Ping timeout: 260 seconds]
Vinalon has joined #yosys
parport0 has quit [Read error: Connection reset by peer]
parport0 has joined #yosys
parport0 has quit [Read error: Connection reset by peer]
parport0 has joined #yosys
parport0 has quit [Ping timeout: 258 seconds]
parport0 has joined #yosys
parport0 has quit [Ping timeout: 264 seconds]
parport0 has joined #yosys
emeb_mac has quit [Quit: Leaving.]
Vinalon has quit [Ping timeout: 265 seconds]
N2TOH_US has quit [Ping timeout: 240 seconds]
vidbina has joined #yosys
N2TOH_US has joined #yosys
vidbina has quit [Ping timeout: 256 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Vinalon has joined #yosys
Jybz has joined #yosys
parport0 has quit [Ping timeout: 256 seconds]
parport0 has joined #yosys
Jybz has quit [Excess Flood]
Jybz has joined #yosys
emeb has joined #yosys
strobokopp has joined #yosys
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` has joined #yosys
X-Scale` is now known as X-Scale
ouznext has joined #yosys
<ouznext>
hi
<ZirconiumX>
hello
<ouznext>
I'm getting "ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc." in nextpnr, is there any place in the log I can look for any hint anout where is the proiblem?
<ZirconiumX>
It'll be from Yosys if anywhere
<ouznext>
If I use arachnepnr I get no error, that 's weird. Maybe NextPNR is more strict...
<ZirconiumX>
You really shouldn't use arachne these days
<ouznext>
Do you think I'll get the error in yosys's log?? not in nextpnr log?
<ZirconiumX>
Nextpnr will be complaining because the loops will be in the input, rather than output
<ouznext>
I'd rather use nextpnr, if it help me find the error lol. ArachePnR doesn't spit any error :(
<ZirconiumX>
And Yosys will be the one producing the input nextpnr consumes
<ZirconiumX>
ouznext: Do you have latches in your design?
<ZirconiumX>
That would be the biggest instance of a combinational loop
<ouznext>
hum, I may have some but I'm not conscious of it. I don't thin my design should have latches (not on purpose/by design I mean)
<daveshah>
You can run with --ignore-loops if you just want to ignore the error
katharina has joined #yosys
citypw has quit [Ping timeout: 240 seconds]
<daveshah>
If you save the Yosys output to a log file, you can grep for 'Latch inferred'
<mwk>
ouznext: the `check` pass of yosys (run near the end of synthesis) should notice if there are logic loops
<mwk>
and emit a warning
<daveshah>
It won't detect logic loops post-synthesis
<daveshah>
but an earlier call to check should do that
<katharina>
you can also `dump` the design and grep for latches
<mwk>
huh?
<mwk>
oh right, it doesn't know which cells are combinatorial.... arrrggh
<daveshah>
It has no knowledge of what is a FF or LUT after techmapping
<ouznext>
yeah, but I would assume skipping an error is a bad decision. I'd rather find it, but the message as such doesn't give any indication of where to find it. Is there any word / warning I could try and find in yosys/nextpnr outputs to help me narrow to the origin of it?
<mwk>
... perhaps it should ...
<daveshah>
> If you save the Yosys output to a log file, you can grep for 'Latch inferred'
* ouznext
is reading latest messages you all wrote
<katharina>
Hello, I wanted to ask whether there are any downsides to using `-abc9` with ice40 devices. I have seen quite a substantial reduction in LC usage using it, and the designs seem to work fine on real hardware.
<ouznext>
thank you all, I found a latch infered! :)
<daveshah>
There is no downside. Occasionally it can increase LC usage or decrease Fmax
<daveshah>
but if it works for your design, enjoy the benefit!
<ZirconiumX>
katharina: I've generally experienced that ABC9 behaves worse than default for iCE40
<ZirconiumX>
There's actually an outstanding bug to that effect
<katharina>
daveshah: Okay, I did notice the Fmax decrease. In my case i lost about 15-20%, but it made my design fit, so I guess I dont have a choice until I optimize further
<ZirconiumX>
Try `synth_ice40 -abc2`
<katharina>
ZirconiumX: I will try that. Do you mean "worse" in terms of LC usage?
<ZirconiumX>
Both that and Fmax
<katharina>
Interesting, `-abc2` makes the LC utilization jump from 78% (with `-abc9`) to 97%, and it makes the timing analysis fail :) I guess my design just happens to work best with `-abc9`
<ZirconiumX>
Hmm, that *is* odd.
<daveshah>
abc2 is a bit dodgy
<Vinalon>
maybe you could also try '-retime' and '-relut'?
<ZirconiumX>
katharina: So, the long and short of it is that ABC (the default) is kinda dumb; ABC9 is smarter in a few different ways, but has known bugs.
<daveshah>
relut should be on by default now
<katharina>
I don't know if this observation has any foundation in reality, but this design is an educational CPU design that is very heavily modularized to be able to discuss the different parts seperately from each other. And I have observed that yosys seems to dislike that
<katharina>
When i manually flattened some of it as a test, I got better LC utilisation, which is weird, considering yosys flattens by default
<ZirconiumX>
katharina: If you really want to live on the edge, try adding `scratchpad -copy abc9.script.flow3 abc9.script` before `synth_ice40 -abc9`.
<ZirconiumX>
As it turns out "run it again" works quite well for ABC :P
<katharina>
ZirconiumX: Considering this being just something used in a classroom, I'm willing to try that. What does it do exactly? Some bleeding edge version of abc9? Or two passes of it?
<ZirconiumX>
katharina: 3 passes of it, actually.
<ZirconiumX>
Internal to ABC9.
<Vinalon>
hm, maybe there should be a '-abc92' option? :P
<katharina>
ZirconiumX: Thanks for your help. Ill try that.
<ZirconiumX>
ABC is very heuristic, so after running it an initial time, you can run it again to further improve the design
<ouznext>
thank you all for the help, found the infered latch, fixed it, no more error in netxtpnr, happy again :) - hope y'all are safe in quarantine whereever you live.
<ZirconiumX>
ouznext: you're welcome :P
<katharina>
ZirconiumX: Your three-pass abc9 call makes the LC usage slighty worse than just -abc9 (only by like 3%, thats fine) but gives me vastly higher Fmax. I call that a win
<katharina>
I assume the 3% difference is just based on it being a heuristic process i guess
<ZirconiumX>
Yep
<katharina>
Thanks!
<ZirconiumX>
We *do* have an option which finds a formally depth-optimal solution, but it bloats area so much it wastes much of its own gain
<daveshah>
And it's not necessarily depth-optimal in general
<daveshah>
only a depth-optimal mapping of the circuit Yosys generates
<ZirconiumX>
It is, as far as I understand the paper
<daveshah>
If the circuit could be optimised away altogether (ie depth=0) I don't think it would necessarily find that, for example
ouznext has left #yosys [#yosys]
<ZirconiumX>
Okay, from that point of view, sure
<daveshah>
Consider
<daveshah>
module top(input [7:0] a, b, output [7:0] q);
<daveshah>
assign q = a + b - b;
<daveshah>
endmodule
<daveshah>
yosys -p "synth_ice40 -nocarry" addsub.v gives no LUT4s
<daveshah>
-nocarry -flowmap gives 26 LUT4s
<ZirconiumX>
Because ABC can perform boolean resynthesis and flowmap can't.
<daveshah>
(ignoring carries for a simple pure logic test case, if you include carries then only abc9 will optimise it away)
<daveshah>
Indeed
<daveshah>
Yosys' freduce can optimise stuff like this away too
<daveshah>
it's hopelessly slow for non-trivial designs though
fengling has quit [Ping timeout: 258 seconds]
fengling has joined #yosys
strobokopp has quit [Read error: Connection reset by peer]