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
    fetching_pc <= !reset & next_task_ready;
    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;
     task_loaded <= 0;
    end
end

The test bench code that triggers these actions is:

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

next_task_channel = 3;
next_task_thread = 0;
next_task_ready = 1;

@(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
active: 0, task_loaded: 0, fetching_pc: 0, ififo_di: 000000000000000000000000
ifetch reset
active: 0, task_loaded: 0, fetching_pc: 0, ififo_di: 000000000000000000000000
active: 0, task_loaded: 0, fetching_pc: 1, ififo_di: 000x0xxxx000000000000000

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.)

  • 1
    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 at 21:11
  • @EugeneSh. - updated – Jules Oct 10 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 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 at 0:52
  • To the downvoter - can you explain why you've downvoted so I can improve this question? – Jules Oct 11 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;

The 1s produced were being merged with the zeros hardwired as the output and generating an indeterminate result; I would naturally have expected this to be an error condition, but it seems it isn't.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.