ERROR: Multiple edge sensitive events found for this signal!

[philiprbrenan]

Please tell me how to figure out which variable in my input verilog has multiple events being applied to it as indicated by this error message from gowin_synth?

Creating register for signal `\DFFP.\Q' using process `\DFFP.$proc$/home/runner/work/zeroLowLevel/zeroLowLevel/oss-cad-suite/lib/../share/yosys/gowin/cells_sim.v:289$1879'.
  created $adff cell `$procdff$12652' with positive edge clock and positive level reset.

ERROR: Multiple edge sensitive events found for this signal!

[whitequark]

By any chance, did you connect the same net to the clock and the reset of a process? I.e. always @(posedge clk, posedge rst) ...; assign {clk, rst} = {x, x};

[philiprbrenan]

I have squeezed my code down to this:

module fpga(input  wire clock);    
  integer ip;            
  always @(posedge clock, negedge clock) begin                                  
    ip = 0;
  end
endmodule

I still get the same error message as is visible in this github action at line 388:

https://github.com/philiprbrenan/zeroLowLevel/actions/runs/5546330416/jobs/10126462221

If I remove the negedge the problem disappears. But I would, naively, like to work with both edges if possible?

[whitequark]

If I remove the negedge the problem disappears. But I would, naively, like to work with both edges if possible?

This is not possible to implement in most FPGA families and even where it is possible the synthesis support is as far as I know nonexistent.

[philiprbrenan]

Might it be worthwhile alerting users to this difficulty?

[whitequark]

This is considered well known among digital logic designers, although depending on your background it may not be so obvious. Where in the docs would you look for answers?

[philiprbrenan]

My idea, such as it is, was that perhaps gowin_synth or read_verilog could detect this eventuality and write a helpful informational note if a posedge/negedge combination of the same signal were detected thus saving time for both end users and Yosys maintainers. While I am sure that this is well known principle to digital logic designers in general it might not be well known to every-one else, some of whom might wish to use Yosys as a pathway into this interesting field. No doubt there are many other such principles, well known to the principals, less well known to the programming hoi poloi which if noted in a similar manner might help make the difficult transition from programming conventional cpus to fpgas a little smoother?

[whitequark]

I've discussed this with Claire before and as far as I'm aware it is an explicit non-goal to have this kind of functionality in read_verilog, i.e. Yosys assumes that the input is valid synthesizable Verilog and any error reporting on it not being such is best-effort. In my opinion this is a mistake but I don't want to touch read_verilog and there are very few who do.

[philiprbrenan]

The code in question was fully validated by iverilog and passed numerous execution tests. Hence the principle of "No mixing of positive and negative edges" being so self evident that it does even require stating is surprising in this context. As read_verilog is doing something that is surprising to users of iverilog , I think it would be worth detecting and noting this difference in capabilities between the two in read_verilog so that yosys users and maintainers do not have to revisit this issue in the future with programmers migrating from iverilog to yosys who might, naively, expect the two to accept identical code. This approach would have the beneficial effect of making it easier for programmers to make the difficult transition from conventional CPUs to FPGAs which must, surely, be one of the goals of this interesting project?

[whitequark]

The code in question was fully validated by iverilog and passed numerous execution tests.

Verilog simulators such as Icarus Verilog accept the full Verilog language. By far, the most of the Verilog language is not synthesizable, i.e. does not correspond to any valid logic that you can put in an FPGA or an ASIC. This is a serious flaw in the Verilog language that is widely known in the industry but papered over by (often company-proprietary) tools due to extreme inertia.

A simulator such as Verilator accepts only the synthesizable subset of the Verilog language (which is what you need here), and would reject your code. Yosys recommends (it's somewhere in the manual iirc) that you run all of your code through Verilator, in lint or simulation mode, to catch any such non-synthesizable code.

This approach would have the beneficial effect of making it easier for programmers to make the difficult transition from conventional CPUs to FPGAs which must, surely, be one of the goals of this interesting project?

Yosys is the first practically useful open source synthesis tool. That was the initial goal of the project, and why I became a maintainer of it. To my knowledge, making it easier for programmers to transition from CPUs to FPGAs was never a specific goal of the Yosys project or most of its members, though others might correct me if I'm wrong. There are so many people using and promoting Yosys because there is chiefly no alternative if you want to use FPGAs without using proprietary tools.