FDRE_1 can't be written out to fasm file

[jrsa]

terminate called after throwing an instance of 'nextpnr_xilinx::assertion_failure' what(): Assertion failure: unsupported FF type (/home/jrsa/src/nextpnr-xilinx/xilinx/fasm.cc:536)

The FF type in question turns out to be FDRE_1, after inspecting with gdb. It seems like the FDRE_1 is supported, from looking https://github.com/gatecat/nextpnr-xilinx/blob/xilinx-upstream/xilinx/pack.cc#L230 in the code.

[jrsa]

I thought for some reason that I could add FDRE_1 here to be handled the same way as FDRE. Looking here i get the impression that FDRE and FDRE_1 should be treated the same, except the _1 has the clock inverted. I did try if (type == "FDRE" || type == "FDRE_1") { but I suspect that I'm still missing something necessary to make the inverted clock work.
As I understand it, this FF config will be used when you have a always @(negedge clk) which is unusual, in my case it used in the VexRiscV JTAG TAP.

[jrsa]

I added some prints in fasm.cc and revealed that my inverted clock FF was placed in the same slice with other non-inverted ones:

Info: writing ffs in tile CLBLL_L_X2Y192 half 1
Info: IS_C_INVERTED 0
Info: IS_C_INVERTED 1

[jschj]

Is this a bug? Did you solve it? I am having exactly the same problem.

[jrsa]

@jschj I did not fix it, not enough knowledge about the internals of nextpnr to navigate it. I would be happy to work on it if I could be pointed in the right direction, perhaps by @gatecat. Are you trying to synthesize VexRiscV as well?

[jschj]

Yes, also with the JTAG thing.

[jschj]

@jrsa I think I found the problem and some dirty fix for now openXC7#21

[jrsa]

@jschj out of curiosity what version of yosys are you using

[jschj]

Yosys 0.37+15