Mystery routing in Xilinx FPGA - unconnected connected block of FIFO?

[daqq]

Hi guys,

So, I've been poking and prodding FPGAs, and I just like to look at the synthesis/implementation results and the actual routing - it's aesthetically pleasing

When I was checking up on it I noticed a little block completely isolated from everything else. See attachement. Basically, two LUTs are connected from nowhere to nowhere... when I click on them to find out more it seems that they are a part of/related to a FIFO... most of which is somewhere else entirely. I can't find any mention of them in the constraints, DRC or anywhere - that said, I'm new to this kind of thing, so I may have overlooked something completely obvious.

Also, they are placed in the same area every time. I'm not sure if they are placed in the exact same spot, but it's possible.

This is not a problem - the device works well, but it's a bit of a mystery. Do you have any hints as to where to start looking for clues on why they are there? The device is an Artix 7 FPGA from Xilinx, the toolset is Vivado, newest version, the FIFO in question is a Xilinx IP block with two unrelated clocks.

Best regards,

David

[AndyC_772]

I'm not familiar with Xilinx, but I have looked into how FIFOs are implemented in Altera FPGAs.

The main issue when crossing clock domains is ensuring that pointers can be written in one domain and read in the other, without ambiguity or error, regardless of the actual timing relationship between one domain and the other.

Pointers are therefore converted to Gray codes, which have the property that only a single bit changes between one value and the next. Therefore, if a pointer is read in one domain at the same time as it's being updated from the other, it's guaranteed that the value read will correspond to either the old value or the new one. Repeated sampling with a short pipeline is used to guard against metastability.

Maybe your unidentified logic is converting pointers to Gray codes, or is involved in metastability protection?

[daqq]

Maybe your unidentified logic is converting pointers to Gray codes, or is involved in metastability protection?

Well, as is shown in the routing (and upon further inspection in the schematic), the connection is from nowhere to nowhere - it's completely disconnected from the rest of the system, just two LUTs connected to the ground.

[RoGeorge]

...Also, they are placed in the same area every time. I'm not sure if they are placed in the exact same spot, but it's possible.

They might be placed in the exactly same place, but not guaranteed.
AFAIK Vivado uses some annealing algorithm (based on randomness) to optimize place and route, so if the design remains unchanged, compiling it twice will generate two bitstreams that are not identical.

[Someone]

...Also, they are placed in the same area every time. I'm not sure if they are placed in the exact same spot, but it's possible.

They might be placed in the exactly same place, but not guaranteed.
AFAIK Vivado uses some annealing algorithm (based on randomness) to optimize place and route, so if the design remains unchanged, compiling it twice will generate two bitstreams that are not identical.

If you build the same design again without changing it, even on another computer on another day under the same version of the tool you get the exact same result every time. Anything else would be infuriating to debug.

[Rasz]

why they are there?

Vivado, Xilinx IP

[RoGeorge]

...Also, they are placed in the same area every time. I'm not sure if they are placed in the exact same spot, but it's possible.

They might be placed in the exactly same place, but not guaranteed.
AFAIK Vivado uses some annealing algorithm (based on randomness) to optimize place and route, so if the design remains unchanged, compiling it twice will generate two bitstreams that are not identical.

If you build the same design again without changing it, even on another computer on another day under the same version of the tool you get the exact same result every time. Anything else would be infuriating to debug.

Thank you for pointing that, and sorry for any misleading info.
I remember about the random annealing from a presentation a few years ago, when Xilinx switched from ISE to Vivado, but never tested if the place and route results are repeatable or not.

[asmi]

I just want to add that in Vivado you can manually "pin" blocks to specific location if automatic placement is not suitable to you for whatever reason.

[Someone]

...Also, they are placed in the same area every time. I'm not sure if they are placed in the exact same spot, but it's possible.

They might be placed in the exactly same place, but not guaranteed.
AFAIK Vivado uses some annealing algorithm (based on randomness) to optimize place and route, so if the design remains unchanged, compiling it twice will generate two bitstreams that are not identical.

If you build the same design again without changing it, even on another computer on another day under the same version of the tool you get the exact same result every time. Anything else would be infuriating to debug.

Thank you for pointing that, and sorry for any misleading info.
I remember about the random annealing from a presentation a few years ago, when Xilinx switched from ISE to Vivado, but never tested if the place and route results are repeatable or not.

You may have misunderstood or come to the wrong conclusion, both the tools do use iterative/annealing approaches and due to the random generators used in the process you can get very different results if you can change the initial seed. However every stage of the tools are designed to reproduce the same results exactly, each tiny detail needs to be the same but you will then get the identical result no matter how many times it runs. Its possible to change small or irrelevant items and end up with a big difference somewhere else (unrelated) in the design.