Placement problem (floorplanner, UCF, RPM ) in Spartan-3.

I'm having difficulty making RPMs in the floorplanner (Webpack, 6.3i) as follows.

I can load a synthesised/translated design (.ngd) into the floorplanner, recreate its hierarchy (using "group by"), place it nicely, and save the design.

Took a while to realise that I had to have "write BEL" set in "Edit/Preferences" to preserve the location of LUTs, FFs, within an individual slice, but I got there...

"Write RPM as UCF" usually crashes. ("FATAL_ERROR:GuiUtilities:WinApp.C:657:$Revision This application has discovered an exceptional condition from which it cannot recover") Seems to be less likely if all I do is load a floorplan in and write it out, but still it crashes more often than not, for me. However it's not impossible to edit "LOC= Slice_XnYm" into RLOC properties, so carry on.

Back annotating the RLOCs into the .ngc file seems OK, (though searching support.xilinx.com for "ngcbuild" yields ... nothing!) ... anyway ngc2edif confirms it's doing roughly the right thing.

Now I'm getting a bit stuck.

I want to read the new design back into the floorplanner. Easy, you might think ... simply "translate" and read in the .ngd.

Except that the BEL information has disappeared, and LUTs, FFs and even carries are randomly swapped around within a slice! All those nice straight connections are randomly crossed, and the bus is wired as

0,1, 2,3, 5,4, 7,6, 9,8, 10,11 etc. If the MSB of a chain is the only one in a slice, odds are it's isolated with a gap between it and its fellows.

Place and route seems to work, and I can load the above mess and straighten it out by "constrain from placement" ... except that I need this RPM as a component at higher levels, which I also want to floorplan.

Am I missing something simple, or am I expecting too much of the floorplanner?

One curiosity ... I tried the old (XC4000!) style of constraint in the UCF, for some FFs (INST myFF RLOC="XnYm.FFX" ) and the floorplanner appeared to accept it. But of course the mapper didn't...

Any ideas?

- Brian

Reply to
Brian Drummond
Loading thread data ...

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.