Forum Discussion
Altera_Forum
Honored Contributor
16 years agoVerilog process not implemented correctly in Quartus
Hi,
It seems as though the following synchronous process in Verilog is sometimes not implemented correctly by Quartus. Why? always @(posedge clk, negedge rst_n) if (!rst_n) begin hdr_frame_length_s[15:0] <= 1; end else if (!srst_n || sof) begin hdr_frame_length_s[15:0] <= 1; end else if (valid_in) begin hdr_frame_length_s <= hdr_frame_length_s + 1; end The code above worked as intended in at least one compilation. However in at least one other compilation, sof would not reset the register. There are two non-standard things here, first the register is reset to 1 not 0, and second the synchronous reset is a logical OR of two inputs. Why is this code problematic to Quartus? Thanks for you help, Avshalom.6 Replies
- Altera_Forum
Honored Contributor
--- Quote Start --- Hi, how the signals !srst_n and sof generated ? Outside the FPGA ? Kind regards GPK --- Quote End --- These are synchronous register outputs (synchronous to clk) - Altera_Forum
Honored Contributor
Thanks for all your replies, I appreciate it.
--- Quote Start --- What Quartus Version are you using ? --- Quote End --- 9.1 sp1 build 304 --- Quote Start --- if 1 compilation is working and 1 not, what about the others ? --- Quote End --- I have changed the coding to be more compliant with the recomended HDL coding guidelines, and it seems work properly for this compilation (then again it could be just a "lucky" compilation and the next one will fail again, as happened before). --- Quote Start --- one thing that i am not shure is, shouldn't you write always @(posedge clk or negedge rst_n) --- Quote End --- SystemVerilog --- Quote Start --- Did you specify the initial values for hdr_frame_length_s ? like reg [15:0] hdr_frame_length_s = 16'd1; or during initial begin hdr_frame_length_s = 16'd1; end // of initialiser block --- Quote End --- the code is synthesizable, register is initialized @ negedge rst_n --- Quote Start --- Do you get any warnings during compilation ? --- Quote End --- Not any that seem related - Altera_Forum
Honored Contributor
--- Quote Start --- Hi, It seems as though the following synchronous process in Verilog is sometimes not implemented correctly by Quartus. Why? always @(posedge clk, negedge rst_n) if (!rst_n) begin hdr_frame_length_s[15:0] <= 1; end else if (!srst_n || sof) begin hdr_frame_length_s[15:0] <= 1; end else if (valid_in) begin hdr_frame_length_s <= hdr_frame_length_s + 1; end The code above worked as intended in at least one compilation. However in at least one other compilation, sof would not reset the register. There are two non-standard things here, first the register is reset to 1 not 0, and second the synchronous reset is a logical OR of two inputs. Why is this code problematic to Quartus? Thanks for you help, Avshalom. --- Quote End --- Hi, how the signals !srst_n and sof generated ? Outside the FPGA ? Kind regards GPK - Altera_Forum
Honored Contributor
@ kaz
what do you mean with "sequential last statement overwrites" ??? still i am missing the last else hdr_frame_length_s <= hdr_frame_length_s; Okay that one is not realy needed, but an if has an else .. just to be sure - Altera_Forum
Honored Contributor
What Quartus Version are you using ?
if 1 compilation is working and 1 not, what about the others ? one thing that i am not shure is, shouldn't you write always @(posedge clk or negedge rst_n) Did you specify the initial values for hdr_frame_length_s ? like reg [15:0] hdr_frame_length_s = 16'd1; or during initial begin hdr_frame_length_s = 16'd1; end // of initialiser block Do you get any warnings during compilation ? Have a look at this Doc Recomended HDL coding guidelines. http://www.altera.com/literature/hb/qts/qts_qii51007.pdf?gsa_pos=4&wt.oss_r=1&wt.oss=hdl design guide (http://www.altera.com/literature/hb/qts/qts_qii51007.pdf?gsa_pos=4&wt.oss_r=1&wt.oss=hdl design guide) - Altera_Forum
Honored Contributor
It could be the priority logic(if else) and the fact that the sequential last statement overwrites that is causing the problem...