*** tpb has joined #yosys | 00:00 | |
*** emeb has quit IRC | 00:31 | |
*** tlwoerner has quit IRC | 05:51 | |
*** rohitksingh has joined #yosys | 05:52 | |
*** craigo has joined #yosys | 05:52 | |
*** tlwoerner has joined #yosys | 06:29 | |
*** emeb_mac has quit IRC | 06:58 | |
*** citypw has joined #yosys | 06:58 | |
*** fsasm has joined #yosys | 07:02 | |
*** citypw has quit IRC | 07:08 | |
*** rohitksingh has quit IRC | 07:25 | |
*** dys has joined #yosys | 09:11 | |
*** vidbina_ has joined #yosys | 09:31 | |
*** vidbina_ has quit IRC | 10:02 | |
*** vidbina_ has joined #yosys | 10:04 | |
*** fsasm has quit IRC | 10:12 | |
*** fsasm has joined #yosys | 10:20 | |
*** vidbina_ has quit IRC | 11:27 | |
*** az0re has joined #yosys | 11:40 | |
*** GenTooMan has quit IRC | 11:47 | |
*** GenTooMan has joined #yosys | 11:48 | |
*** fsasm has quit IRC | 12:06 | |
*** az0re has quit IRC | 12:08 | |
*** GenTooMan has quit IRC | 12:37 | |
*** craigo has quit IRC | 13:13 | |
*** craigo has joined #yosys | 13:13 | |
*** dh73 has joined #yosys | 13:23 | |
*** dh73 has quit IRC | 14:04 | |
*** X-Scale` has joined #yosys | 14:06 | |
*** X-Scale has quit IRC | 14:08 | |
*** X-Scale` is now known as X-Scale | 14:08 | |
*** attie has joined #yosys | 14:50 | |
*** emeb has joined #yosys | 15:44 | |
*** dh73 has joined #yosys | 16:01 | |
*** GenTooMan has joined #yosys | 16:08 | |
*** jakobwenzel has quit IRC | 16:30 | |
*** captain_morgan20 has quit IRC | 16:39 | |
*** alexhw has quit IRC | 17:10 | |
*** alexhw has joined #yosys | 17:12 | |
*** alexhw has quit IRC | 17:14 | |
*** alexhw has joined #yosys | 17:25 | |
*** alexhw has quit IRC | 17:27 | |
*** dys has quit IRC | 17:35 | |
*** Jybz has joined #yosys | 17:43 | |
*** craigo has quit IRC | 17:56 | |
*** attie has quit IRC | 18:13 | |
*** emeb has left #yosys | 18:25 | |
*** Jybz has quit IRC | 18:26 | |
*** alexhw has joined #yosys | 18:44 | |
ZirconiumX | Welp; I found another Yosys bug | 18:46 |
---|---|---|
ZirconiumX | But it seems to be an infinite loop? | 18:46 |
*** attie has joined #yosys | 19:15 | |
ZipCPU | Really? | 19:20 |
ZirconiumX | ZipCPU: https://github.com/YosysHQ/yosys/issues/1634 <-- not an infinite loop, but unreasonably high | 19:24 |
tpb | Title: fsm_detect takes a very long time · Issue #1634 · YosysHQ/yosys · GitHub (at github.com) | 19:24 |
*** indy has quit IRC | 19:26 | |
*** X-Scale` has joined #yosys | 19:45 | |
*** X-Scale has quit IRC | 19:48 | |
*** X-Scale` is now known as X-Scale | 19:48 | |
*** attie has quit IRC | 19:51 | |
*** az0re has joined #yosys | 19:53 | |
*** attie has joined #yosys | 20:03 | |
*** indy has joined #yosys | 20:14 | |
ZipCPU | ZirconiumX: Which block is the one giving you the problem? | 20:28 |
ZirconiumX | ZipCPU: "which block"? What do you mean by "block" here? | 20:29 |
ZipCPU | always | 20:29 |
ZirconiumX | ZipCPU: I'm working in nMigen, so there's no direct correlation as such | 20:31 |
ZipCPU | So ... this isn't the Yosys input? | 20:31 |
ZirconiumX | It is the Yosys input | 20:32 |
ZipCPU | So then one of the always blocks must be the one giving yosys the hassle | 20:32 |
ZirconiumX | Yes, but I don't know which and Yosys does not have the functionality to diagnose the issue by itself at present | 20:33 |
whitequark | always blocks in verilog correspond to processes in nmigen-generated rtlil | 20:33 |
ZipCPU | Bisect the code then? | 20:33 |
whitequark | or you could also use nmigen to write verilog | 20:34 |
whitequark | also that | 20:34 |
daveshah | what about bugpoint -yosys <script containing timeout 10 yosys> | 20:34 |
ZipCPU | daveshah: Is there any documentation on how to use that? | 20:34 |
daveshah | help bugpoint | 20:35 |
daveshah | "-yosys" is intended to use an alternative Yosys binary | 20:35 |
daveshah | but I think timeout should work here too | 20:35 |
daveshah | *a shell script containing timeout | 20:35 |
ZirconiumX | Fortunately the bug is reproducible with my current nMigen code | 20:35 |
ZirconiumX | Given the warning, I think it's a misrecognised FSM register | 20:36 |
ZirconiumX | Even so, it should not take five and a half minutes | 20:36 |
ZipCPU | Absolutely! | 20:36 |
ZipCPU | The question is how to narrow the problem down sufficiently to find the root cause | 20:36 |
ZipCPU | Not whether or not there's a problem | 20:36 |
ZirconiumX | daveshah: Hmm, I'd need to combine it with -grep or else any Yosys error counts as a "crash" | 20:41 |
ZirconiumX | But I don't see a way to get `timeout` to do that | 20:41 |
ZirconiumX | Either way, there are only about 54 lines in the output verilog between "working" and "broken" | 20:43 |
whitequark | you can make a shell conditional | 20:44 |
whitequark | along the lines of `if timeout yosys` | 20:44 |
ZirconiumX | Right, think I've got it | 20:53 |
*** attie has quit IRC | 20:57 | |
ZirconiumX | So, I'm noticing that nextpnr's SA seems to produce higher but less-consistent Fmax values than HeAP. Is this expected? | 21:20 |
daveshah | Slightly higher is definitely possible on some designs | 21:22 |
daveshah | less-consistent is probably just down to the more random nature of Sa | 21:22 |
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 | 21:22 |
ZirconiumX | (ECP5) | 21:22 |
daveshah | Oh, do you have any IO constraints? | 21:23 |
ZirconiumX | At present no | 21:23 |
daveshah | As it stands to avoid a singular matrix HeAP randomly constrains unconstrained IO at the start, whereas SA optimises IO | 21:23 |
daveshah | I haven't done a nicer solution as 99.9% of real world designs have constrained IO | 21:24 |
ZirconiumX | Ah, fair enough | 21:24 |
*** fsasm has joined #yosys | 21:38 | |
*** fsasm has quit IRC | 23:05 | |
*** emeb has joined #yosys | 23:23 | |
*** TheHolyC has quit IRC | 23:50 | |
*** TheHolyC has joined #yosys | 23:50 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!