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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor jrrguzman
Visitor
2,696 Views
Registered: ‎02-27-2017

FWFT FIFO unexpected behavior

Jump to solution

Hi,

 

I'm working with a VC707 dev. board and Vivado 2016.4. I had to create a 16Mb (256-bit x 65536) FWFT for a video buffer and I've encountered the following problem: when reading from the FIFO, data does not seem to match the memory contents (or the data I've written previously), being a just a few bits which seem to be consistent for all the memory accesses I've performed. I've verified this by using Chipscope. It seems to be implementation dependent, since after running Vivado with slight changes in the design, the bits affected seem to change.

 

Is there any known issue with the timing for 7-series FPGAs and such big block memories?

 

Thanks in advance.

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
4,243 Views
Registered: ‎02-06-2012

Re: FWFT FIFO unexpected behavior

Jump to solution
The design meets timing with about 300 ps slack. The clocks at the FIFO ports have been constrained with an asynchronous clock group since they are not related.

 I think this is a problem. Asynchronous clock groups is a "constraint" which translates as set_false_path between clocks in both directions. This is very dangerous and I think it should be called "all hell breaks loose" instead.

set_clock_groups -async has the highest priority, which means it will also overwrite (disable) all internal IP constraints. Which means it will also overwrite the FIFO IP internal set_max_delay/set_bus_skew constraints.

 

In this situation you could get different results with each implementation and hit this issue even with smaller FIFO. But bigger FIFO user more memory blocks spread over FPGA, so it makes much more probable for this problem to surface.

0 Kudos
10 Replies
Moderator
Moderator
2,685 Views
Registered: ‎11-09-2015

Re: FWFT FIFO unexpected behavior

Jump to solution

Hi @jrrguzman,

 

Did you try in simulation?

Does you design meet timing?


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Visitor jrrguzman
Visitor
2,674 Views
Registered: ‎02-27-2017

Re: FWFT FIFO unexpected behavior

Jump to solution

Hi @florentw

 

The FIFO was generated with the IP generator from Vivado. It's been used within a module which has been tested and verified with a smaller FWFT FIFO (4KB), but same data width. The only things that have been changed are the counters but they are not used for flow control.

 

Here is the behavior I'm experiencing:

 

The first picture shows the write port of the FIFO and the first 256b data being written. The second picture shows the data being read from the same FIFO. Note that the data is not the same as the one being written (0x0300 is replaced by 0x0000). This effect is replicated throughout all the memory accesses.

 write.PNG

 

read.PNG

 

The design meets timing with about 300 ps slack. The clocks at the FIFO ports have been constrained with an asynchronous clock group since they are not related.

 

timing.PNG

0 Kudos
Moderator
Moderator
2,658 Views
Registered: ‎11-09-2015

Re: FWFT FIFO unexpected behavior

Jump to solution

Hi @jrrguzman,

 

You might want to look at AR#42571. It might be related to what you see. However, this is only for the first read or write while you are seeing it over all the memory accesses...

 

Regards,

 

Florent


Florent
Product Application Engineer - Xilinx Technical Support EMEA
**~ Don't forget to reply, give kudos, and accept as solution.~**
0 Kudos
Visitor jrrguzman
Visitor
2,653 Views
Registered: ‎02-27-2017

Re: FWFT FIFO unexpected behavior

Jump to solution

Hi @florentw

 

It happens for every READ access, mostly on those bits but sometimes others are affected.

 

WRITE/READ SEQUENCE (1st 6 transfers)

W0) 0f000e000d000c000b000a000900080007000600050004000300020001000000

R0) 0f000e000d000c000b000a000900080007000600050004000000020001000000

 

W1) 1f001e001d001c001b001a001900180017001600150014001300120011001000

R1) 1f001e001d001c001b001a001900180017001600150000000000000001001000

 

W2) 2f002e002d002c002b002a002900280027002600250024002300220021002000

R2) 2f002e002d002c002b002a002900280027002600250024000000220021002000

 

W3) 3f003e003d003c003b003a003900380037003600350034003300320031003000

R3) 3f003e003d003c003b003a003900380037003600350034000000320031003000

 

W4) 4f004e004d004c004b004a004900480047004600450044004300420041004000

R4) 4f004e004d004c004b004a004900480047004600450044000000400041004000

 

W5) 5f005e005d005c005b005a005900580057005600550054005300520051005000

R5) 5f005e005d005c005b005a005900580057005600550054000000400051005000

 

W6) 6f006e006d006c006b006a006900680067006600650064006300620061006000

R6) 6f006e006d006c006b006a006900680067006600650064000000620061006000

 

The sequence continues until ff00fe00fd00... and the loops back to the 0f000e000d00...

 

I'll try to reduce the memory size and see if I can reproduce the issue...but I don't think I can relate to the AR you are pointing.

 

Kind regards

0 Kudos
Highlighted
Adventurer
Adventurer
4,244 Views
Registered: ‎02-06-2012

Re: FWFT FIFO unexpected behavior

Jump to solution
The design meets timing with about 300 ps slack. The clocks at the FIFO ports have been constrained with an asynchronous clock group since they are not related.

 I think this is a problem. Asynchronous clock groups is a "constraint" which translates as set_false_path between clocks in both directions. This is very dangerous and I think it should be called "all hell breaks loose" instead.

set_clock_groups -async has the highest priority, which means it will also overwrite (disable) all internal IP constraints. Which means it will also overwrite the FIFO IP internal set_max_delay/set_bus_skew constraints.

 

In this situation you could get different results with each implementation and hit this issue even with smaller FIFO. But bigger FIFO user more memory blocks spread over FPGA, so it makes much more probable for this problem to surface.

0 Kudos
Visitor jrrguzman
Visitor
2,531 Views
Registered: ‎02-27-2017

Re: FWFT FIFO unexpected behavior

Jump to solution

@abyszuk

 

Your point is indeed very interesting. I'll be trying that out right away.

 

On the other hand, how should then constraint this path? If just leave it unconstrained I can't meet timing, so I would like to use the IP constraints while marking those networks as asynchronous clocks in my design.

 

Thanks in advance!

0 Kudos
Adventurer
Adventurer
2,489 Views
Registered: ‎02-06-2012

Re: FWFT FIFO unexpected behavior

Jump to solution
I'm afraid there's no other way than to manually constrain other CDC paths (wildcards in path/cell names help a lot!).
For starters, you can simply set_false_path on CDC paths - just remember to specify start/dest endpoints as speficic cells, not whole clocks.
Resulting XDC can become quite large, that's true. But this is the only way to get reliable design. My current project has 50+ set_false_path/set_max_delay constraints...
0 Kudos
Visitor jrrguzman
Visitor
2,446 Views
Registered: ‎02-27-2017

Re: FWFT FIFO unexpected behavior

Jump to solution

Hi @abyszuk

 

It seems that was the issue. Thanks!

0 Kudos
Visitor jrrguzman
Visitor
2,321 Views
Registered: ‎02-27-2017

Re: FWFT FIFO unexpected behavior

Jump to solution

Hi @abyszuk

 

After marking as false paths all the paths except for the ones that target the FIFO, the problem has shown up again. It was fine for some time but it seems it was a "lucky" implementation (or a few ones).

 

Any ideas?

 

Kind regards

0 Kudos
Newbie smartin666
Newbie
572 Views
Registered: ‎04-11-2018

Re: FWFT FIFO unexpected behavior

Jump to solution

Your last post indicates this issue wasn't solved by eliminating the set_clock_groups -async

How did you finally solve your issue?

 

I am experiencing similar intermittent read failures from a Kintex7 BlockRam FWFT Common Clock FIFO.

I have read AR #42571 and the failure scenario described doesn't apply.  All my control and resets are synchronously applied and my clock is free-running.

 

My issue comes and goes from compile to compile and only is detected intermittently on 1 or 2 out of a hundred or so systems.

But the issue is repeatable.  My failure seems to always occur on the 1st FIFO read following a FIFO reset ( like described by AR #42571) but seems to persist beyond the 1st read. 

 

Any new ideas?

0 Kudos