The paths you are seeing are clearly the clock crossing paths within the FIFO (I recognize the names); to be sure you should give the detailed timing report of the top path, but I am pretty confident it will show that the path starts and ends on different clocks (one end on your read clock and one on the write clock).
These paths are proper clock crossing paths, and, as such, they need constraints to override the default timing analysis behavior of the tool.
One of the advantages to the IP mechanism in Vivado is that it doesn't only generate a netlist for you, it also generates all the constraints for the block. When the IP was generated, it also generated an .xdc file with the proper exceptions for these paths. You can see this by going into the IP pane in the sources window, and looking at all the files generated for the IP - there will be .xdc files there. These files become part of your project automatically when the IP block is created in your project or imported to your project.
Clearly, though, these files are not being used properly in your design. This means either
- you did something "odd" when you generated/imported the IP into your project or
- something went wrong when the IP constraints were applied to your design
Look through your messages to make sure that there weren't any warnings about a "set_max_delay" command - I think this might even show up as a critical warning. The constraint file for the core assumes your design is already constrained - specifically that both the read clock port and write clock port of the FIFO have a clock associated with them; that a create_clock or create_generated_clock, or an automatically generated clock is associated with the nets connected to the ports of the FIFO. If you don't have a clock defined for one of the ports, then the set_max_delay constraint in the FIFO's .xdc will fail (with a warning or critical warning). Even if you add the clock "later", the set_max_delay will still not be in place, which will cause these timing errors.
Avrum
