# Unexpected indeterminate outputs from verilog conditional operator

I have the following combinatorial assignment in a verilog module:

assign ififo_di = fetching_pc ? { 5'h02, 3'h7, 16'h8000 } : decoded_insn;


where ififo_di is an output, fetching_pc is a local register and decoded_insn is an input (which, in all my testing so far, is always set to 24'h000000).

And have a clock-triggered action that sets fetching_pc for a single cycle in specific circumstances. The same block also provides synchronous reset and sets up a monitor for debugging purposes:

always @(posedge clk)
begin
if (reset)
begin
// reset registers
$display ("ifetch reset");$monitor ("active: %b, task_loaded: %b, fetching_pc: %b, ififo_di: %b", active, task_loaded, fetching_pc, ififo_di);

active <= 0;
end
end


The test bench code that triggers these actions is:

@(posedge clk);
reset = 1;
@(posedge clk);
reset = 0;
@(posedge clk) #10;

@(posedge clk) #10;

// at this point the ififo_di output is checked and the test fails


At the time the next_task_ready input is set to 1, the reset input is 0, and the internal registers active and task_loaded are both verified as containing 0 (although task_loaded is changed to 1 in the same cycle -- but altering this so that this change doesn't take place gives identical results).

My expectation is that when this happens, ififo_di will change from 000000h to 178000h, however what really happens (testing in icarus verilog) is this:

ifetch reset
ifetch reset


Why would the output by changing the bits that need to change to x rather than to 1 as expected? I would understand if fetching_pc were x, but it's clearly being shown in the monitor output as 1, so what's going on here?

(updated: Eliminated some unnecessary code so that I can provide the entire always block as tested, thus showing all potentially-relevant content of the module.)

• And have a clock-triggered action that sets fetching_pc for a single cycle in specific circumstances - and this is something that needs to be shown here, as the issue is clearly there. – Eugene Sh. Oct 10 '18 at 21:11
• @EugeneSh. - updated – Jules Oct 10 '18 at 21:48
• As it is show - it should not "flicker". But I am still suspecting the stuff hiding behind the // ... – Eugene Sh. Oct 10 '18 at 21:50
• @EugeneSh. The flicker is caused by setting task_loaded to 1, which causes fetching_pc to return to 0, but I have also tested without this change and the issue persisted. – Jules Oct 11 '18 at 0:52
• To the downvoter - can you explain why you've downvoted so I can improve this question? – Jules Oct 11 '18 at 18:14

I found the answer, and it was from a surprising source -- the testbench code had an incorrectly defined connection for the ififo_di output:
wire ififo_di = 0;