Feature request: Support for dual-edge-triggered FFs

[ArcaneNibble]

Some devices such as Coolrunner-II can have dual-edge FFs internally.

[ArcaneNibble]

As an example of what I want to be able to process, this is my Verilog model of the FDDCP primitive on Coolrunner-II:

module FDDCP (C, PRE, CLR, D, Q);
    parameter INIT = 0;

    input C, PRE, CLR, D;
    output reg Q;

    initial begin
        Q <= INIT;
    end

    always @(posedge C, negedge C, posedge PRE, posedge CLR) begin
        if (CLR == 1)
            Q <= 0;
        else if (PRE == 1)
            Q <= 1;
        else
            Q <= D;
    end
endmodule

Right now, running proc on this causes yosys to instantly exit saying ERROR: Multiple edge sensitive events found for this signal! Since this gives an error in the proc step, it would be rather tricky to write a later pass to deal with this construct. This feature request would also involve adding a number of new cell types such as $ddff or $ddffsr.

Adding support for inferring dual-edge-triggered flip-flops can also allow yosys to eventually be able to infer DDR input/output cells, which are much more common compared to dual-edge-triggered flip-flops in the logic fabric.

Unfortunately, I don't know what should happen if a user tries to use dual-edge-triggered flip-flops on a target that does not support them. I think that techmapping should either fail with an error or replace these flip-flops with two single-edge-triggered flip-flops and the "XOR trick."

[getziadz]

I am also interested about this feature. Are there any updates?

[jleahy]

Dual edge triggered flip flops are generally on the way out, there was once a time where for ASICs it was considered a standard component of the library you had to provide (that nobody used). However these days most standard cell libraries do not come with these, meaning you are also unlikely to see them in any new FPGAs or CPLDs.

Similarly for DDR buffers I'm not sure people would expect to be able to infer these, the complexity with these kinds of interfaces is only growing. Typically you would expect to have controls for things such as delay tuning to implement modern memory interfaces.

It might be better to just use the XOR trick in your verilog, then add a yosys pass that pattern matches for this situation (two flip flops with same data input and same clock with opposite triggers that are xor'd together) and replaces it with the device specific primitive. Then there'd be no need to extend the core of yosys to handle this obscure case, it would just be another device-specific pass.

[whitequark]

AFAIK, the issue is only present in the Verilog frontend; RTLIL processes can express such FFs fine (one sync posedge and one sync negedge rule writing to the same register). I'm not sure about the proc pass.