10:36 <Guest86> is it bad if yosys-abc failed with return code 134?

10:40 <Guest86> or asked differently: what is the impact (I'm naive about it and the resulting bitstream works), and how do I track down what causes it?

10:41 <gatecat> Guest86: it's because of https://github.com/YosysHQ/yosys/pull/1974

10:42 <gatecat> theoretically, a failure of &mfs might produce slightly worse results (e.g. a higher percentage of resources used), but if it's fitting fine anyway, then you don't really need to worry

10:42 <gatecat> it's unlikely that anything specific in the design is causing it, just bad luck

10:45 <Guest86> we're targeting ECP5 and we know that the commercial lattice tools can probably reach much higher frequencies, but it's not a big problem yet

10:46 <Guest86> (the worse issue is that the open source tools can't use some ALU elements)

10:56 <Guest86> are there any recommendations about how to implement CDC on a yosys based toolchain? you need to ensure that FFs are not optimized away or duplicated, that they're placed close together, potentially using robust FFs suited for it; on xilinx I'd just use the xpm_cdc macros to handle the low level details

11:04 <Guest86> all I can think of is setting the "keep" attribute (documented in yosys/README.md only?), and hope for the best

11:38 <lofty> gatecat and Guest86: &mfs failures should be less of an issue after https://github.com/YosysHQ/yosys/pull/4351

11:39 <lofty> Guest86: speaking officially, "hope for the best" is recommended practice

11:40 <lofty> ... Yosys isn't timing aware, so CDC isn't something considered by it. nextpnr *is* timing aware, however it doesn't perform anything special with regards to CDC, AIUI.

11:44 <lofty> Guest86: if you get that ABC error with Yosys 0.40, file a bug; I'll take a look at it.

11:59 <Guest86> lofty: I just tried with oss-cad-suite 2024-05-07 and can confirm the crash is gone in my case (with a ~2 month old release it happened on every run)

12:02 <Guest86> lofty: in my opinion (I'm normally software developer) the only sane way to even have a chance of getting CDC right is if the toolchain provides special CDC modules (at least for synchronized FFs that won't do surprising things after optimization), even if they get reduced to nothing special during synthesis for a specific FPGA

12:03 <lofty> They normally control timing like false-paths etc. nextpnr isn't quite smart enough to handle this properly, but usually it works in practice.

12:20 <tnt> I usually have an eye at the max delay between the two domain to make sure it didn't do anything crazy, but that's as much as you can do I think. It'd be nice if we could actually constrain it but ...

12:21 <Guest86> my main issue here is that my shiny new code might work now, but could break when the tools get more sophisticated optimizations

12:22 <tnt> Well `keep` is documented and should ensure the FF doesn't get optimized. You can also instanciate the actual FF primitive with dont_touch to make extra sure.

12:22 <tnt> What you can't really do is control where those will be placed (short of fully placing them manually) or the delay between them.