From the LRM:
23.3.3.1 Port coercion A port that is declared as input (output) but used as an output (input) or inout may be coerced to inout. If not coerced to inout, a warning shall be issued.
The LRM doesn't make sense, shouldn't it be the opposite if coerced i.e simulator is changing rtl "under the hood" warning shall be issued. If not coerced to inout compilation should fail (as lint and synthesis) ?
test case :
related : What is the exact criteria for an inout port, when sometimes inout and output ports can be interchangeably used in Verilog?
From the LRM:
23.3.3.1 Port coercion A port that is declared as input (output) but used as an output (input) or inout may be coerced to inout. If not coerced to inout, a warning shall be issued.
The LRM doesn't make sense, shouldn't it be the opposite if coerced i.e simulator is changing rtl "under the hood" warning shall be issued. If not coerced to inout compilation should fail (as lint and synthesis) ?
test case : https://www.edaplayground/x/VdmF
related : What is the exact criteria for an inout port, when sometimes inout and output ports can be interchangeably used in Verilog?
Share Improve this question edited Feb 5 at 13:01 Meir asked Feb 4 at 13:44 MeirMeir 3072 gold badges4 silver badges15 bronze badges 1- Coercion is the expected behaviour, for historical reasons, so the text is correct. The warning (may) be issued if the port could have been coerced to avoid an "error", but wasn't. See my answer below. – EML Commented Feb 7 at 11:35
2 Answers
Reset to default 0The Verilog standard is incorrect and has been since IEEE 1364-1995. The problem is most simulation tools ignore port directions and no one has put in the effort to fix the LRM.
https://accellera.mantishub.io/view.php?id=1289
Port directions are advisory in Verilog, and always have been. The LRM rationalises this by saying that port directions may be "coerced" by the tool. So, the text you quote is correct, with the proviso that tools may or may not issue warnings.
This is down to an implementation issue in the original XL; it's not an LRM problem. Quoting an old VCS manual:
"In the previous generation of Verilog simulators, Verilog-XL, there was the port collapsing algorithm where Verilog-XL removed certain ports so that Verilog-XL could simulate faster and use less memory. In Verilog-XL you could still refer to a collapsed port but internally, inside Verilog-XL, the port did not exist.
VCS replaces Verilog-XL so VCS must mimic port collapsing so that an old but reusable design, now simulated with VCS, will have the same simulation results. For this reason the default behavior of VCS is to “coerce” all ports to inout ports so designs will simulate the same as when their ports were collapsed by Verilog-XL.
This port coercion can, for example, result in a value propagating up the design hierarchy out of a port you declared to be an input port and unexpectedly driving the signal connected to this input port. Port coercion, therefore, can cause debugging problems."
... and so on.