emeb has quit [Quit: Leaving.]
tlwoerner has quit [Quit: Leaving]
rohitksingh has joined #yosys
craigo has joined #yosys
tlwoerner has joined #yosys
emeb_mac has quit [Quit: Leaving.]
citypw has joined #yosys
fsasm has joined #yosys
citypw has quit [Ping timeout: 258 seconds]
rohitksingh has quit [Remote host closed the connection]
dys has joined #yosys
vidbina_ has joined #yosys
vidbina_ has quit [Ping timeout: 265 seconds]
vidbina_ has joined #yosys
fsasm has quit [Ping timeout: 260 seconds]
fsasm has joined #yosys
vidbina_ has quit [Ping timeout: 268 seconds]
az0re has joined #yosys
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #yosys
fsasm has quit [Ping timeout: 265 seconds]
az0re has quit [Ping timeout: 240 seconds]
GenTooMan has quit [Ping timeout: 260 seconds]
craigo has quit [Quit: Leaving]
craigo has joined #yosys
dh73 has joined #yosys
dh73 has quit [Ping timeout: 268 seconds]
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
attie has joined #yosys
emeb has joined #yosys
dh73 has joined #yosys
GenTooMan has joined #yosys
jakobwenzel has quit [Quit: jakobwenzel]
captain_morgan20 has quit [Ping timeout: 268 seconds]
alexhw has quit [Remote host closed the connection]
alexhw has joined #yosys
alexhw has quit [Client Quit]
alexhw has joined #yosys
alexhw has quit [Remote host closed the connection]
dys has quit [Ping timeout: 245 seconds]
Jybz has joined #yosys
craigo has quit [Ping timeout: 265 seconds]
attie has quit [Ping timeout: 265 seconds]
emeb has left #yosys [#yosys]
Jybz has quit [Quit: Konversation terminated!]
alexhw has joined #yosys
<
ZirconiumX>
Welp; I found another Yosys bug
<
ZirconiumX>
But it seems to be an infinite loop?
attie has joined #yosys
<
tpb>
Title: fsm_detect takes a very long time · Issue #1634 · YosysHQ/yosys · GitHub (at github.com)
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` is now known as X-Scale
attie has quit [Ping timeout: 272 seconds]
az0re has joined #yosys
attie has joined #yosys
indy has joined #yosys
<
ZipCPU>
ZirconiumX: Which block is the one giving you the problem?
<
ZirconiumX>
ZipCPU: "which block"? What do you mean by "block" here?
<
ZirconiumX>
ZipCPU: I'm working in nMigen, so there's no direct correlation as such
<
ZipCPU>
So ... this isn't the Yosys input?
<
ZirconiumX>
It is the Yosys input
<
ZipCPU>
So then one of the always blocks must be the one giving yosys the hassle
<
ZirconiumX>
Yes, but I don't know which and Yosys does not have the functionality to diagnose the issue by itself at present
<
whitequark>
always blocks in verilog correspond to processes in nmigen-generated rtlil
<
ZipCPU>
Bisect the code then?
<
whitequark>
or you could also use nmigen to write verilog
<
whitequark>
also that
<
daveshah>
what about bugpoint -yosys <script containing timeout 10 yosys>
<
ZipCPU>
daveshah: Is there any documentation on how to use that?
<
daveshah>
help bugpoint
<
daveshah>
"-yosys" is intended to use an alternative Yosys binary
<
daveshah>
but I think timeout should work here too
<
daveshah>
*a shell script containing timeout
<
ZirconiumX>
Fortunately the bug is reproducible with my current nMigen code
<
ZirconiumX>
Given the warning, I think it's a misrecognised FSM register
<
ZirconiumX>
Even so, it should not take five and a half minutes
<
ZipCPU>
Absolutely!
<
ZipCPU>
The question is how to narrow the problem down sufficiently to find the root cause
<
ZipCPU>
Not whether or not there's a problem
<
ZirconiumX>
daveshah: Hmm, I'd need to combine it with -grep or else any Yosys error counts as a "crash"
<
ZirconiumX>
But I don't see a way to get `timeout` to do that
<
ZirconiumX>
Either way, there are only about 54 lines in the output verilog between "working" and "broken"
<
whitequark>
you can make a shell conditional
<
whitequark>
along the lines of `if timeout yosys`
<
ZirconiumX>
Right, think I've got it
attie has quit [Ping timeout: 258 seconds]
<
ZirconiumX>
So, I'm noticing that nextpnr's SA seems to produce higher but less-consistent Fmax values than HeAP. Is this expected?
<
daveshah>
Slightly higher is definitely possible on some designs
<
daveshah>
less-consistent is probably just down to the more random nature of Sa
<
ZirconiumX>
Well, this design is kind of artificial, but HeAP seems to max out at 300MHz or so, and SA just gave me a 438 MHz solution
<
ZirconiumX>
(ECP5)
<
daveshah>
Oh, do you have any IO constraints?
<
ZirconiumX>
At present no
<
daveshah>
As it stands to avoid a singular matrix HeAP randomly constrains unconstrained IO at the start, whereas SA optimises IO
<
daveshah>
I haven't done a nicer solution as 99.9% of real world designs have constrained IO
<
ZirconiumX>
Ah, fair enough
fsasm has joined #yosys
fsasm has quit [Ping timeout: 272 seconds]
emeb has joined #yosys
TheHolyC has quit [Max SendQ exceeded]
TheHolyC has joined #yosys
tpb has quit [Remote host closed the connection]
tpb has joined #yosys