IBUFDS output was X

[cyn_thia]

HI:

   I am using zynq device to do some developments.

   When I use  primitive IBUFDS, the output shows X when it should be "1",

    and I refered to the thread https://forums.xilinx.com/t5/Simulation-and-Verification/IBUFDS-showing-x-at-output/m-p/480942#M10176, but I only see the warning "[Vivado 12-3661] Failed to remove file:G:/xilinx-vivado/Vivado_prj/project_2/project_2.sim/sim_1/behav/bram_top_behav.wdb",I dont thinks it matters.

   Anyone kown why?

   The codes are as follwing:

IBUFDS data_pro_0 (
                                .I(data_p[0]),
				.IB(data_n[0]),
				.O(data_to_bram[0])
	         );
IBUFDS data_pro_1 (
				.I(data_p[1]),
				.IB(data_n[1]),
				 .O(data_to_bram[1])
);

   The waveforms are like followding:

Thanks for your help!

[muzaffer]

your netnames in the text are data_to_bram but the waveform shows data_ot ?

[cyn_thia]

HI:

   Thanks for your repley.

   The port name "data_to_bram" was the output port in my working module.

   The "data_ot" is the name of instantiate module port in my testbentch.

   Is there any reasons that cause that problem ? Thanks !

[gszakacs]

Can you post the test bench code?  It looks like you might have drive contention.  For example if the test bench itself is driving the bus low, then when the UUT drives high you would see an X.

[cyn_thia]

HI:

  My module and testbentch is in the attachment.

  I am a FPGA newbee,so sorry for my supid mistake first .

  Thanks for your help!

[gszakacs · Accepted solution]

In you test bench you have this line:

        assign data_ot = data_tp;

And then you have the instantiation of the device under test:

    data_to_bram du1(.clk(clk),
                    .rst_n(rst_n),
                    .data_p(data_p),
                    .data_n(data_n),
                    .data_to_bram(data_ot))    ;

            
    endmodule

So there are two drivers for the signal data_ot, one in the assignment to data_tp, and another by connection to the output of module du1.  data_tp is a reg initialized to zero, and never changes after that, so one driver is driving data_ot low.  Then your module tries to drive some bits high, thus conflicting with the continuous assignment to zero.  In simulation this gives you a value of X.  If you tried to synthesize the testbench code, it would give a multi-source error.  If you comment out the first assignment statement, you should not get the X values.

[cyn_thia]

Thanks for your theoretical explanation,it helps. Good day!