Why won't Quartus give me an error or warning for this obvious Verilog error during compilation?

[TAnde27]

Hi,

In my Verilog HDL projects, it seems Quartus provides no notification (errors, warnings, or messages in the compilation log) if I accidentally declare a port as an input but then assign it within the body of the code. A simple example:

module bitwise_negation #(parameter P_DATA_WIDTH=32) ( input [P_DATA_WIDTH-1:0] a, output [P_DATA_WIDTH-1:0] y );   assign y = ~a; endmodule   module bitwise_negation_wrapper #(parameter P_DATA_WIDTH=32) ( input [P_DATA_WIDTH-1:0]a, input [P_DATA_WIDTH-1:0]y // port direct is wrong, should be output );   bitwise_negation #(.P_DATA_WIDTH(32)) BN_0(.a(a),.y(y)); endmodule

Once I load the bitstream onto the board, the module simply doesn't function correctly. (Perhaps the port with the incorrect direction is initialized to 0, I'm not sure.) On two separate occasions, this has caused me a few hours of lost time, so I'd like to know: is there a way to make the compiler flag this sort of obvious problem with an error or warning?

Thanks!

[AnandRaj_S_Intel]

Hi Tyler,

Quartus can't report logical error.

Modules can be instantiated from within other modules.And can interface with input / output depending on Logic.

One question How to create a 2-bit counter?

Please refer module instantiation basic.

Example :Output of one DFF can be input to another.

module dff (clk, d, q); input clk, d; output q; reg q; always @(posedge clk) q = d; endmodule module top; reg data, clock; wire q_out, net_1; dff inst_1 (.d(data), .q(net_1), .clk(clock)); dff inst_2 (.clk(clock), .d(net_1), .q(q_out)); endmodule

Let me know if this has helped resolve the issue you are facing or if you need any further assistance.

Regards

Anand

[TAnde27]

Yes, but your example is quite different from the one I provided.

In my case, bitwise_negation_wrapper declares an *input* port y which is being internally driven by the instantiated module bitwise_negation. My question is why the compiler isn't complaining about a module driving it's own input port.

I recently read about "port coercion" in Verilog, and that may be what's going on here. Does anyone know if there is a way to have the compiler throw a warning for coerced ports?

[AnandRaj_S_Intel]

Hi Tyler,

Quartus can't report logical error.

Modules can be instantiated from within other modules.And can interface with input / output depending on Logic.

The output "y" of bitwise_negation module is connect to input "y" of bitwise_negation_wrapper module.

IT DOES NOT HAVE ANY SYNTAX ERROR.

Check your RTL viewer.

About my example.

I'm connecting q output of first FF using reg net_1 to d input of second FF.

Regards

Anand

[TAnde27]

Hi Anand,

After doing some research, I now see that the reason the Quartus compiler did not throw an error is because of a Verilog language "feature" called "port coercion". When I look at various FPGA forum discussions related to Verilog port coercion, folks seem to say, "yeah, this is kind of a goofy feature about Verilog, but that's just the way it is." See for instance, the paper here: https://sutherland-hdl.com/papers/2007-SNUG-SanJose_gotcha_again_paper.pdf, where the authors refer to port coercion as a Verilog "gotcha".

Quoting from section 2.7 of the link I reference, the authors say, "Port coercion can occur...if a module writes values to a port that is defined as input."

My example is doing this, but the example you provided does not coerce a port. That's the fundamental difference between your example and my example, and it is the basic issue I was inquiring about. I'd like to know if there is a compiler flag to make Quartus print a warning message like "WARNING: port y of module bit_negation_wrapper is being coerced from input to inout.", or otherwise, if there's something I can look at in the compilation report to tell me that port coercion has occurred.

The example I provide is a simplified version of an error that took me many hours to debug in a much larger project (+10,000 lines of HDL code). This sort of thing is not allowed in VHDL (the compiler would have thrown a syntax error), but is apparently OK in Verilog.

Thank you,

Tyler

[ak6dn · Accepted solution]

This is why such tools as 'VeriLint' were developed that try to check the semantics of what your code is doing vs pure syntax.

Your example has correct language syntax, but the semantics of what you are doing is not (necessarily) meaningful. It could be, or not.

You can't expect the QuartusII verilog parser to figure these things out. VHDL language is much more strict, Verilog is looser.