UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Reply

FIFO returns partial garbage

Highlighted
Observer
Posts: 45
Registered: ‎08-29-2017

FIFO returns partial garbage

I was using a 16-bit wide 64 depth FIFO and added another 16-bits to it by concatenating some wires. Essentially, I added a delay of 16 bits to the data in for the FIFO:

 

wire[31:0] fifo_data_in = {address, data, end_transaction, delay};

 

wire[31:0] fifo_data_out;
wire[6:0] fifo_address = fifo_data_out[31:25];
wire[7:0] fifo_data = fifo_data_out[24:17];
wire fifo_end_transaction = fifo_data_out[16:16];
wire[15:0] fifo_delay = fifo_data_out[15:0];

 

 

reg fifo_read_enable;

wire fifo_full;
wire fifo_empty;

wire fifo_write_enable;

i2c_fifo fifo (
    .srst(reset | clear),
    .clk(clock),
    .wr_en(fifo_write_enable),
    .rd_en(fifo_read_enable),
    .din(fifo_data_in),
    .dout(fifo_data_out),
    .full(fifo_full),
    .empty(fifo_empty)
);

 

This was working fine, then suddenly after doing some other work, it started returning garbage XXs for bits [15:0] during simulation. The other elements are set fine and reflect what was placed into the FIFO. The First Word Fall Through flag is checked for this FIFO, and these values are what appears on dout only after the empty flag drops to 0.

So after double-checking that I was putting valid data in, I changed the read width from 32 to 64, and it started working again.

I only enable the read for one clock cycle, I have:


if (fifo_read_enable)
    fifo_read_enable <= FALSE;

 

at the top of an always @(posedge clock)block.

If I change the FIFO width back to 32, which is the correct value since I'm writing 32-bit into the FIFO, then I get garbage again. When I switch the read width back to 64, it works again.

Any idea what might be causing this?

Adventurer
Posts: 96
Registered: ‎02-01-2013

Re: FIFO returns partial garbage


inflector wrote:

I was using a 16-bit wide 64 depth FIFO and added another 16-bits to it by concatenating some wires.

--What does that mean--how do you 'add' to a FIFO?  Do you mean you added some stuff to a simple simulation of just a FIFO?

 

Essentially, I added a delay of 16 bits to the data in for the FIFO:

I don't see any 'delay', below; all I see in this snippet are non-blocking assignments to wires.

 

wire[31:0] fifo_data_in = {address, data, end_transaction, delay};

--Unknown, as to what the widths of the constituent buses above are.  But "fifo_data_in" will be the input to your FIFO.

 

wire[31:0] fifo_data_out;
wire[6:0] fifo_address = fifo_data_out[31:25];
wire[7:0] fifo_data = fifo_data_out[24:17];
wire fifo_end_transaction = fifo_data_out[16:16];
wire[15:0] fifo_delay = fifo_data_out[15:0];

--The output of the FIFO (fifo_data_out) is re-distributed (re-named) to some other buses... 

 

reg fifo_read_enable;

wire fifo_full;
wire fifo_empty;

wire fifo_write_enable;

 

i2c_fifo fifo (
    .srst(reset | clear),
    .clk(clock),
    .wr_en(fifo_write_enable),
    .rd_en(fifo_read_enable),
    .din(fifo_data_in),
    .dout(fifo_data_out),
    .full(fifo_full),
    .empty(fifo_empty)
);

--It would help to see the .VEO for this FIFO, to know how wide the ports are.

 

This was working fine, then suddenly after doing some other work, it started returning garbage XXs for bits [15:0] during simulation. The other elements are set fine and reflect what was placed into the FIFO. The First Word Fall Through flag is checked for this FIFO, and these values are what appears on dout only after the empty flag drops to 0.

-- Are you resetting the FIFO at the beginning of sim?  The logic driving "reset" and "clear" is not shown.

So after double-checking that I was putting valid data in, I changed the read width from 32 to 64, and it started working again.

--No idea what that means--how do you change the "read width"?  Did you re-build the FIFO to have a 32-bit input/write port and a 64-bit output/read port?

I only enable the read for one clock cycle, I have:


if (fifo_read_enable)
    fifo_read_enable <= FALSE;

 

at the top of an always @(posedge clock)block.

If I change the FIFO width back to 32, which is the correct value since I'm writing 32-bit into the FIFO, then I get garbage again. When I switch the read width back to 64, it works again.

--Lost me again...

Any idea what might be causing this?

--XX's are due to an unknown value.  Either you're inserting an unknown value into the system after reset, or you're failing to properly reset the system at the beginning of the sim.  Since the problem is with the lower 16 bits, check how you're assigning a value to "delay"--the lower portion of "fifo_data_in".


-Joe G.

 

Adventurer
Posts: 96
Registered: ‎02-01-2013

Re: FIFO returns partial garbage

Sorry: I meant "continuous assignments to wires", above.
Observer
Posts: 45
Registered: ‎08-29-2017

Re: FIFO returns partial garbage

how do you 'add' to a FIFO? 

 

It was 16 bits wide, I opened the IP wizard and changed it to be 32-bits wide.

 

I don't see any 'delay', below; all I see in this snippet are non-blocking assignments to wires.

 

wire[15:0] fifo_delay is the part I added. Which required increasing the bit width of the FIFO to 32 from 16.

Are you resetting the FIFO at the beginning of sim? 

 

Yes, that part I double checked, all registers are properly initialized and the reset is passed into the FIFO. I'm raising reset to HIGH on the start of the sim, and that's been working fine all along.

Did you re-build the FIFO to have a 32-bit input/write port and a 64-bit output/read port?

 

Yes, that's what did, and after I did that it worked. I opened the IP file in Vivado and edited the width to 64-bits and it worked again, edited back to 32 and it stopped working.

 

Since the problem is with the lower 16 bits, check how you're assigning a value to "delay"--the lower portion of "fifo_data_in".

 

I noticed the XXXs and checked that delay is indeed set in the simulation when adding to the FIFO. I used $display to verify that the values are set before rd_enable is raised for the FIFO. The FIFO is returning them, they are not present in my code before writing to the FIFO, and they show up on the read of the FIFO as soon as the empty flag clears.

 

 

Adventurer
Posts: 96
Registered: ‎02-01-2013

Re: FIFO returns partial garbage

Ok.  I get it now: You were simming a 16-bit-wide FIFO, and everything was groovey.  You widened the FIFO to accommodate an additional 16-bit field (called "delay"), and then "after doing some other work", unknown values (XX's) started showing up on the lower 16 bits of the FIFO output.

 

What was the "other work"?  Is the new "delay" field of the FIFO input valid at the same time as the rest of the FIFO input fields--during the FIFO writes?

 

When exactly does the unknown (XX) show up?  How many write/read cycles occur before you get XX's?  Can you add a screenshot of the timing diagram showing the problem?  It seems to me that if you ACK a FWFT-FIFO read with a READ_ENA strobe, the next value in the FIFO memory is going to show up at the FIFO output.  If that value hasn't been written yet, you could get an unknown value.  I'm not why it'd only be on the lower 16 bits, though.  (Still don't know the target family for the FIFO, or its exact configuration parameters.)

 

-Joe G.

 

Observer
Posts: 45
Registered: ‎08-29-2017

Re: FIFO returns partial garbage

This problem seemed to disappear when I created a new project and added the files and regenerated the FIFO again. I think it was likely some file corruption.

I wasn't doing work in the FPGA, what I meant by other work, was editing some Verilog in another section of the design. The FPGA was simply idling waiting for the FIFO to have items in it and then sending them across an i2c bus to a display. So the sequence didn't allow for anything else corrupting the FIFO outputs. At least none that I could see possible. And now it went away...

I normally hate those kind of problems but I've had many times when Vivado has acted flaky crashed, hung during simulation, or sythesis, etc. And in my experience, these sorts of things can cause data structure corruption with resulting file corruption. I'll post again here if I see it again.

Thanks for the assistance.