06:52 <gatecat> cr1901: there were scripts for some of the lists in it, but https://github.com/YosysHQ/icestorm/blob/master/icebox/iceboxdb.py is the main autogenerated part

10:53 <tnt> ERROR: FF cpu.$auto$simplemap.cc:495:simplemap_dffsre$10047 (type $_DFFSRE_PPPP_) cannot be legalized: dffs with async set and reset are not supported ...

10:54 <tnt> :/ I mean why generate it in the first place. I would have expected a async reset FF and a mux to 0 merged in the preceding lut.

10:55 <gatecat> what code is this coming from ?

10:55 <tnt> Vex

10:55 <tnt> That's a verilog I originally gnerated for the ice40 (and that works fine there) and I was trying to reuse the same on ecp5.

10:56 <gatecat> huh, strange it's hitting a different code path between the two

10:56 <gatecat> neither support those kinds of DFFs

10:56 <tnt> Mmm ... I only tried on the ice40 before I updated my toolchain yesterday. Maybe it's broken now ...

10:59 <tnt> Oh ... it crashes on ice40 too both on old & new toolchain, but only when I try to synth it "alone". If I synth the full project, then it works fine.

11:02 <tnt> That's the exact file btw : https://github.com/smunaut/ice40-playground/blob/master/projects/riscv_doom/rtl/VexRiscv.v

11:03 <tnt> I was just trying yosys -p 'synth_ecp5' VexRiscv.v to get a quick idea of resources.

11:15 <mwk> tnt: the problem here is like 4305

11:16 <mwk> IBusCachedPlugin_fetchPc_pcReg <= externalResetVector;

11:16 <mwk> this one is *bad*

11:16 <mwk> because it's in an async reset block, and externalResetVector is a signal, not a constant

11:16 <mwk> so what we'd technically need to do here is synthesize a FF with async load

11:17 <mwk> which is not actually supported yet, but an early pass will convert it to a FF with async set + reset wired appropriately to the externalResetVector anded with reset

11:18 <mwk> if you use it as part of larger thing, the external reset vector is presumably wired to a const, which is why yosys is able to optimize the crazy reset structure into a plain async reset with a single value

11:21 <mwk> I'd say this is a vexriscv bug, as it's asking for a FF that cannot be reasonably provided by most FPGA targets

11:24 <mwk> about emulation: yes, you can try to emulate the unsupported FF type with lots of async logic, but we cannot in good conscience do it in yosys when there's no support in the toolchain for ensuring that whatever we emit is race-free / glitch-free, then remains so in P&R

11:29 <tnt> mwk: Ah, I see. Yeah, externalResetVector is pretty much tied to constant in all instanciations, I'm not sure if chisell can generate verilog params.

11:30 <tnt> Thanks for the explanation, makes more sense to me now. Somehow I had read the error as having async set and sync reset being an issue, not sure how I got that in my head.

11:31 <mwk> ah

11:31 <mwk> yeah, sync resets are emulated without complaint whenever not supported

11:32 <mwk> async resets are... argh

11:32 <tnt> Heh yeah. I use them on the ice40 because of the CE affecting the sync reset line on the ice40 causing longer path than needed if both CE and sync reset/set are used.

11:33 <mwk> let's just say I have already implemented some async reset emulation via simpler async reset FFs patterns, for "feature parity" with a certain cursed vendor synth tool

11:33 <mwk> but it cannot make something out of nothing