Strangeness of synthesis when working with FPGA
The idea of writing this article arose during the synthesis of a single project in different development environments, as a result of which different results were obtained from each other. Since the initial module is quite voluminous, a smaller module test module was written to demonstrate the obtained results, but the synthesis of which caused the same warnings / errors. A 4-bit register with asynchronous reset was used as a test module, and Libero SoC 18.1, Quartus Prime 17.1, Vivado 2017.4.1 were chosen as development environments.
First, a variant is presented of the description of such a module in the Verilog language, the text of which is perceived correctly by the selected development environments:
module test1
(
input clk,
input arst,
input [3:0] data,
output reg [3:0] q
);
always @( posedge clk or negedge arst ) beginif ( ~ arst ) begin
q <= 4'h0 ;
endelsebegin
q <= data ;
endend
endmodule
As a result of the synthesis of this module, the following schemes were obtained:
- Libero SoC v11.8test1 Libero SoC

- Quartus Prime 17.1test1 Quartus Prime

- Vivado 2017.4.1test1 vivado

On all synthesized circuits for test1, D-triggers were used with either an inverse reset input (Quartus Prime) or an inverter added (VERIFIC_INV in the case of Libero SoC and LUT1 in the case of Vivado).
Will the synthesized scheme differ if I change the check of the asynchronous reset state? To do this, change the text of the test1 module to the description of the test2 module:
module test2
(
input clk,
input arst,
input [3:0] data,
output reg [3:0] q
);
always @(posedge clk or negedge arst) beginif (arst) begin
q<=data;
endelsebegin
q<=4'h0;
end
end
endmoduleIt can be assumed that the synthesis of the test2 module should not differ from the synthesis of the test1 module, since the logic of the description of both modules does not contradict each other. However, the synthesis of the test2 module led to the following results:
- Libero SoC v11.8
Synthesis of the scheme has been implemented, but the following warning message “Edge and condition mismatch (CG136)” appeared in the messages. This warning indicates a mismatch in the sensitivity list and check for a reset condition. However, the synthesized circuit does not differ from the test1 module.test2 Libero SoC
- Quartus Prime 17.1
Synthesis of the circuit did not materialize with the error:
"Error (10200): Verilog HDL Conditional Statement error at test2.v (10): construct. " The error text is similar to the warning given by Libero SoC. - Vivado 2017.4.1
Synthesis of the circuit was realized with the warning:
“[Synth 8-5788] Register q_reg in the module test. This may cause simulation mismatches. Consider rewriting code ["/home/vlasovdv0111/project_1/project_1.srcs/sources_1/new/test2.v":10]". As in the Libero SoC and Quartus Prime environments, a similar warning was issued. In addition, the warning was told about a possible discrepancy between the results of modeling and work in the "hardware", as a result, it was proposed to rewrite the module code.test2 vivado
After describing the modules test1 and test2, an idea appeared to check what would happen if the following code was synthesized:
module test3
(
input clk,
input arst,
input [3:0] data,
output reg [3:0] q
);
always @(posedge clk or negedge arst) beginif (arst) begin
q<=4'h0;
endelsebegin
q<=data;
endend
endmoduleThe description of such a register is not logical, since the reset of triggers in this case occurs when the reset line is in an inactive state.
The results of the synthesis were as follows:
- Libero SoC v11.8
Synthesis of the circuit did not materialize with an error: "Logic for q [3: 0] does not match a standard flip-flop (CL123)", thereby refusing to produce a synthesis circuit, citing the absence of the type of trigger required for the synthesis. - Quartus Prime 17.1
Synthesis of the circuit did not materialize with the following error: “Error (10200): Verilog HDL Conditional Statement error at test3.v (9): always construct. " The text of this error does not differ from the error text for the test2 module. - Vivado 2017.4.1
Synthesis of the circuit was realized without errors:test3 vivado
However, what will happen if we describe a module in which the sensitivity list does not contradict the verification of the reset condition, but at the same time the flip-flops are reset when the reset line is inactive, as in the case of the test3 module description. The description of such test4 module is as follows:
module test4
(
input clk,
input arst,
input [3:0] data,
output reg [3:0] q
);
always @( posedge clk or negedge arst ) beginif ( ~ arst ) begin
q <= data ;
endelsebegin
q <= 4'h0 ;
end
end
endmoduleDuring the synthesis, the following results were obtained:
- Libero SoC v11.8
Synthesis of the circuit was realized with a warning:
“The system has 4 controls and 4 sequential elements including q_1 [3]. Using this clock, it can be adversely affected by the design of the clock. (MT532). "test4 Libero SoC
- Quartus Prime 17.1
As a result of the synthesis of the scheme, warnings were received: All the above warnings correspond to the fact that latches were used instead of triggers.«Warning (13004): Presettable and clearable registers converted to equivalent circuits with latches. Registers power-up to an undefined state, and DEVCLRn places the registers in an undefined state.
Warning (13310): Register "q[0]~reg0" is converted into an equivalent circuit using register "q[0]~reg0_emulated" and latch "q[0]~1"
Warning (13310): Register "q[1]~reg0" is converted into an equivalent circuit using register "q[1]~reg0_emulated" and latch "q[1]~1"
Warning (13310): Register "q[2]~reg0" is converted into an equivalent circuit using register "q[2]~reg0_emulated" and latch "q[2]~1"
Warning (13310): Register "q[3]~reg0" is converted into an equivalent circuit using register "q[3]~reg0_emulated" and latch "q[3]~1"»test4 quartus prime
- Vivado 2017.4.1
Synthesis of the circuit was carried out with one warning:
“[Synth 8-5788] Register q_reg in module test. This may cause simulation mismatches. Consider rewriting code ["/home/vlasovdv0111/project_1/project_1.srcs/sources_1/new/test.v":11]". The text of this error completely repeats the text of the error for the test2 module.test4 vivado
Of all the experiments described, we can draw the following conclusions:
- Verilog is a universal language for describing hardware, the limitations of which are the capabilities of the development environments themselves;
- To properly describe the hardware, you need to know the syntax of the language, as well as analyze the lists of warnings and errors that occur at each stage of the project.