RLOC weirdness

Do you specify your RLOCs in the .ucf? Source? If source, within the submodules? Where the submodules are instatiated? I'm wondering if your concept of sets meshes with the Xilinx concept. If they're all in the same source file for an implied set or in the UCF with the appropriate sets declared explicitly, you should have a good RLOC that shows up as a USER_RPM in FPGA Editor.

The mapper, after parsing the hierarchy remaps the row and column assignments in your RPM so that the lower left corner of the hierarchical RPM is x0y0. If the lower left corner of your RPM, after any trimming by map is in an odd column or odd row, it does exactly what you are experiencing here as a result of re-assigning the RLOCs so that the left bottom element is x0y0. Set up your RLOCs so that the bottom left corner, after any trimming, is x0y0, or at least is even for both x and y so that it doesn't try to put a column that had been for an odd column into an even column. The issue is that even if the placement is legal (i.e. there are no slice M parts going into a slice L as a result of the realignment), the even and even+1 columns are translated as being in one CLB (recalling that each CLB has 2 columns of slices), and then the mapper re-aligns the RLOC columns but does not rebuild the CLB.

In addition to the documented weirdnesses as described by Ray Andraka, the floorplanner certainly used to have problems with hierarchical RLOCs. I raised several Webcases regarding them, and was told either yes they are bugs; or yes they are bugs, scheduled to be fixed in ISE 7.1.

See (from circa Jan 2005, a thread called "ISE Toolflow : hardmacro, incremental or modular")

contains a demo using RLOC and RLOC_ORIGIN in which only one of eight RPMs was correctly placed in 6.1sp3 floorplanner. (Admittedly two of them had illegal placements for some of the reasons Ray mentioned)

There were at least two tool bugs then; I wonder if they were fixed buit came back, or if new ones have appeared in this area. I gave up then, and haven't had time (or an excuse) to try the test case on newer tools.

I'm going to try this test case on 7.1 today; I don't plan to install

8.x until the current project is complete.

At one time, they certainly did things they weren't supposed to. Either all these issues have been fixed, or you will have to find out how to work around the current crop of bugs.

- Brian

The floorplanner bugs are still there, which makes it hard to use as a placer. Instead, I have been placing the RPMs in a UCF and using floorplanner to view the placements. It has been this way for a while with Xilinx promising to fix it next release. I'm not holding my breath.

There is another reason the RPMs will do this that is related to the mapper. The mapper has a bug that does not account for the columns correctly when an RPM straddles a non-LUT column (DSP48, BRAM or BRAM/MULT18 column). The net result is it winds up causing the same problem I described in my earlier post even if you have the RPM constructed properly. It is a real problem for RPMs in a V4SX family part since it practically limits the size of your RPM to 4 slice columns.

I think I was bitten by both problems actually, but after making sure that my RPM was placed on a CLB boundary and away from any non-LUT columns the problems went away.

Thanks!

/Andreas