Verilog - instantiation input port not connected in top level design but design is working?

I want to convert a verilog design into vhdl but i found a verilog module which I see no way to convert it, because the design itself makes no sense to me. The module entity is the following code snippet:

module fifo_mst_dpath (

// inputs
input                fifoRstn,
input                fifoClk,
input                latch_clk,
input [31:0]         tc_data,
input [3:0]          tc_be,
input                tc_rxf_n,
input                tc_txe_n,
input                snd_cmd,
input [3:0]          bus_cmd,
input [31:0]         tx_data,
input [3:0]          tx_be,
input [2:0]          ep_num,

// outputs
output reg [31:0]   tp_data,
output reg [3:0]    tp_be,
output reg          rx_rxf_n,
output reg          rx_txe_n,
output reg [31:0]   rx_data,
output reg [3:0]    rx_be
);


The input latch_clk drives the following logic:

 always @(latch_clk or tc_data)
if (~latch_clk)
rx_data <= tc_data;

always @(latch_clk or tc_be)
if (~latch_clk)
rx_be <= tc_be;

always @(latch_clk or tc_rxf_n)
if (~latch_clk)
rx_rxf_n <= tc_rxf_n;

always @(latch_clk or tc_txe_n)
if (~latch_clk)
rx_txe_n <= tc_txe_n;

endmodule


The problem is now, that the top-level design instantiates fifo_mst_dpath without connecting the input port latch_clk:

  fifo_mst_dpath i_fifo_mst_dpath (
// inputs
.fifoRstn(tm_rstn),
.fifoClk(fifoClk),
.tc_data(tc_data),
.tc_be(tc_be),
.tc_txe_n(tc_txe_n),
.tc_rxf_n(tc_rxf_n),
.snd_cmd(snd_cmd),
.bus_cmd(bus_cmd),
.tx_data(tx_data),
.tx_be(all_m_wr_be),
.ep_num(t_ep_num),
// outputs
.tp_data(tp_data),
.tp_be(tp_be),
.rx_txe_n(rx_txe_n),
.rx_rxf_n(rx_rxf_n),
.rx_data(rx_data),
.rx_be(rx_be)
);


Simulating the desing with this configuration (missing latch_clk) will always result in rx_be = "XXXX", rx_data = "XXXXXXX" and so on. But these signals are used in the design for other logic and the design itself when synthesized will work. Can you help me understanding this issue? Am I missing something? How can this be converted to vhdl? Thank you.

Two things:

1. Are you sure that this original Verilog module design is finished, and expected to work properly?
2. If input of the module is not connected, it may be tied to specific logical level by the compiler, and all circuits related to it are removed during optimization.

Simulation expects you to define all the input signals; thus if there's any 'X' in the equation resulting signal will be 'X'. Try forcing this latch_clk as 0, and watch the result.

Update:

I looked at all messages. But please tell me what will the code (latch_clk or tc_data) in the sensitivity list do? Can I not type (latch_clk, tc_data) . Is the OR in this case really nessecary?

If they change their state, circuit is "activated". Why OR is there, and why latch_clk takes place please ask developer of the code. As I said if compiler sees some signal defaulted to some value, compiler just removes this signal substituting a constant instead, thus you get 0 or tc_data (with 0 never triggering), thus it is just optimized to tc_data, and if(~latch_clk) being if(~0) or if(1) thus having it always true.

• It is finished an it works perfectly. It is an 32 bit FIFO Master interface which should be connected to an USB 3.0 Interface. – hendrik2k1 Jan 25 '18 at 17:04
• When Verilog design gets compiled, look through all the messages compiler/fitter and other entities produce, and search for latch_clk text. You may see something like that signal is not connected, and it is defaulted to 0. – Anonymous Jan 25 '18 at 17:06
• When forcing latch_clk to 0 it will work, that is of course the expected function of the code but I wonder what is the reason to put this so complicated. – hendrik2k1 Jan 25 '18 at 17:06
• You have got it. As soon as tc_data changes its value, rx_data is being updated with it. – Anonymous Jan 25 '18 at 17:16
• FYI: the or in the sensitivity was required for separating signals in Verilog-1995. Since Verilog-2001, or or , can be uses as the signal separator. Verilog-2001 also added a wildcard sensitivity list @* or @(*) which is preferred for combinational and latching logic. – Greg Jan 25 '18 at 20:55