cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
eml
Explorer
Explorer
287 Views
Registered: ‎03-31-2017

Data corruption in FIFO generator 13.2, SDP

Jump to solution

I have a very basic SDP FIFO, as follows:

  • Independent clocks, block RAM
  • 512 x 72
  • FWFT
  • async reset pin, enable reset sync, enable safety check
  • No extras (flags, word counts, DOUT reset, etc)
  • Implemented as 1 x RAMB36E1
  • Write clock 6.4ns, read clock 25.6ns (async, not locked)

This is showing data corruption: the first word out has 1 one-bit error, the second has 3 one-bit errors, the third has 2, and so on. AR #42571 covers the case of only the first read or write failing, so might not be relevant here.

I've checked the waveforms at the underlying RAMB36E1 (attached). The write diagram shows the first 3 writes, while the second diagram shows the first 3 reads.

The diagrams show that the 'base' 64 data bits are written and read correctly at the RAMB36E1, but the extension/parity bits are incorrect. I can't immediately correlate the data at the BRAM against the data I write to the FIFO, because the core scrambles the bits from the FIFO data bus to the BRAM data bus, but it does appear that the error is in the parity bits (there's 1 one-bit error in the first parity byte, 3 in the second, and 2 in the third, which is what I'm seeing in the 'real' FIFO data).

The resets are complicated. I keep the FIFO reset asserted until the read clock is stable, which is at 25ms. I then de-assert the FIFO reset near, but not at, the read or write clock rising edge. However, the core netlist applies completely different resets to the RAMB36E1 primitive. It asserts RSTRAMARSTRAM, and does some reads, at 4.6us. The read clock is stable at this time, but stops soon afterwards, and starts again much later.

Any ideas what might be going on? Thanks.


 

The core netlist instantiates the RAMB36E1 as follows:

  RAMB36E1 #(
    .DOA_REG(0),
    .DOB_REG(0),
    .EN_ECC_READ("FALSE"),
    .EN_ECC_WRITE("FALSE"),
    .INIT_A(36'h000000000),
    .INIT_B(36'h000000000),
    .INIT_FILE("NONE"),
    .IS_CLKARDCLK_INVERTED(1'b0),
    .IS_CLKBWRCLK_INVERTED(1'b0),
    .IS_ENARDEN_INVERTED(1'b0),
    .IS_ENBWREN_INVERTED(1'b0),
    .IS_RSTRAMARSTRAM_INVERTED(1'b0),
    .IS_RSTRAMB_INVERTED(1'b0),
    .IS_RSTREGARSTREG_INVERTED(1'b0),
    .IS_RSTREGB_INVERTED(1'b0),
    .RAM_EXTENSION_A("NONE"),
    .RAM_EXTENSION_B("NONE"),
    .RAM_MODE("SDP"),
    .RDADDR_COLLISION_HWCONFIG("DELAYED_WRITE"),
    .READ_WIDTH_A(72),
    .READ_WIDTH_B(0),
    .RSTREG_PRIORITY_A("REGCE"),
    .RSTREG_PRIORITY_B("REGCE"),
    .SIM_COLLISION_CHECK("ALL"),
    .SIM_DEVICE("7SERIES"),
    .SRVAL_A(36'h000000000),
    .SRVAL_B(36'h000000000),
    .WRITE_MODE_A("WRITE_FIRST"),
    .WRITE_MODE_B("WRITE_FIRST"),
    .WRITE_WIDTH_A(0),
    .WRITE_WIDTH_B(72)) 

 

Tags (2)
read.png
write.png
0 Kudos
1 Solution

Accepted Solutions
eml
Explorer
Explorer
180 Views
Registered: ‎03-31-2017

Ok, you'll be pleased to hear that I've fixed this for you. There's a bug in your Verilog FIFO simulation netlist when instantiating the model of the RAMB36E1 primitive, for non-ECC mode (ie. pretty much all FIFOs). You'll see from the previous messages that you instantiate the RAMB36E1 as

  RAMB36E1 #(
    .DOA_REG(0),
    .DOB_REG(0),
    .EN_ECC_READ("FALSE"),
    .EN_ECC_WRITE("FALSE"),

 

However, the VHDL RAMB36E1 model declares EN_ECC_READ and EN_ECC_WRITE as boolean, and not as string. This wouldn't work in pure VHDL, let alone Verilog instantiating VHDL. And why are you even instantiating the VHDL model anyway? The xci for this component has both the target and simulation languages set to Verilog.

You'll need to change the ramb36e1.vhd declarations to 'string' to make them consistent with the Verilog. But then, of course, the model will probably fail everywhere else you use it.

My fix is straightforward: I now have a Tcl script that modifies your FIFO netlist to fix it before it's compiled (which I also have to do with your Aurora netlist).

BTW, I've now been fixing Xilinx stuff for well over 20 years. In the early days you used to give me free software. Now, you don't give me free software, you don't have support, and you don't even bother responding to bug reports on the forums. You should probably bear in mind that there are other FPGA vendors.

View solution in original post

0 Kudos
3 Replies
eml
Explorer
Explorer
279 Views
Registered: ‎03-31-2017

The red cursors show the first write or the first read. The first 3 writes are to addresses 803F, 807F, and 80BF, and the data is (8 ext bits / 64 base bits):

2C / 016C BBFD F79F 7CF0

22 / 01E9 AFAD 9554 D34D

22 / 01E9 AFAD B5D5 D75D

The first three reads produce the same data, except that the extension bits are 2D, 08, and 21.

0 Kudos
eml
Explorer
Explorer
250 Views
Registered: ‎03-31-2017

I'm getting some of these messages soon after reset:

# EXECUTION:: WARNING: DRC Warning : SET/RESET (RSTRAM) is not supported in
ECC mode.

# EXECUTION:: Time: 32100 ps, Iteration: 3, Instance:
/top/EOA_WRAPPER1/U1/U3/U1/U0/inst_fifo_gen/\gconvfifo.rf \/\grf.rf
\/\gntv_or_sync_fifo.mem \/\gbm.gbmg.gbmga.ngecc.bmg
\/inst_blk_mem_gen/\gnbram.gnativebmg.native_blk_mem_gen \/\valid.cstr
\/\ramloop[0].ram.r \/\prim_noinit.ram
\/\DEVICE_7SERIES.NO_BMM_INFO.SDP.WIDE_PRIM36_NO_ECC.ram
\/SDP/WWB72/RAMB36E1_SDP_inst, Process: prcs_clk.w

This comes from the primitive model for the BRAM (RAMB36E1.vhd). I'm doing mixed VHDL/Verilog simulation, and the top-level FIFO netlist is Verilog, which is instantiating VHDL further down (way down) the hierarchy.

So, the RAMB primitive model appears to think I'm running in ECC mode, despite the fact that the top-level FIFO netlist explicitly instantiates the RAMB with ECC turned off. This is starting to look like a bug where I ask for a 72-bit-wide FIFO, and the tools instantiate a primitive which throws away the top 8 bits of the write data, and then reads out ECC data instead of those bits.

I've already spent a day on this and would appreciate some feedback.

0 Kudos
eml
Explorer
Explorer
181 Views
Registered: ‎03-31-2017

Ok, you'll be pleased to hear that I've fixed this for you. There's a bug in your Verilog FIFO simulation netlist when instantiating the model of the RAMB36E1 primitive, for non-ECC mode (ie. pretty much all FIFOs). You'll see from the previous messages that you instantiate the RAMB36E1 as

  RAMB36E1 #(
    .DOA_REG(0),
    .DOB_REG(0),
    .EN_ECC_READ("FALSE"),
    .EN_ECC_WRITE("FALSE"),

 

However, the VHDL RAMB36E1 model declares EN_ECC_READ and EN_ECC_WRITE as boolean, and not as string. This wouldn't work in pure VHDL, let alone Verilog instantiating VHDL. And why are you even instantiating the VHDL model anyway? The xci for this component has both the target and simulation languages set to Verilog.

You'll need to change the ramb36e1.vhd declarations to 'string' to make them consistent with the Verilog. But then, of course, the model will probably fail everywhere else you use it.

My fix is straightforward: I now have a Tcl script that modifies your FIFO netlist to fix it before it's compiled (which I also have to do with your Aurora netlist).

BTW, I've now been fixing Xilinx stuff for well over 20 years. In the early days you used to give me free software. Now, you don't give me free software, you don't have support, and you don't even bother responding to bug reports on the forums. You should probably bear in mind that there are other FPGA vendors.

View solution in original post

0 Kudos