Placement vs Map in 6.2i, sp3

I'm trying to do a modular design, building a core, placing it, creating an RPM then going on to a sibling or (finally) parent core, doing the same, etc.

I've noticed something very odd - it seems the P&R can place, route and statically-time a layout which the mapper can subsequently reject with 'Slice XXYY cannot do X,Y,Z at the same time' errors if it is fed the layout as a floorplan.

My main objective has been to see if it's best to lay out on a

32-clb-high array (with 32-bit carry chains only taking 16 CLB's, for example), or to do everything on a 16-CLB-high array and having much more depth to the datapath.

I got to the stage in the 16-CLB high layout where the maximum frequency dropped from 50 MHz down to 40 for a very thin wrapper around it. I wanted to test the same level of abstraction with a 32-CLB-high layout.

So, I was creating the RPM layout, and running translate/map/par (T/M/P) periodically to check things were still ok, and it got to the point where the automatic layout was pretty much getting there - there were still a few elements placed "outside" the rectangle when they could have been inside, but I was reasonably happy, given that I just wanted to see if it took the same hit as the 16-high CLB layout.

So, I did a 'copy from placement' into the editable area, and moved the

3 or 4 elements from their placed places to ones within my rectangle for the design. I then tried to T/M/P it, and got errors from areas of the design I hadn't touched.

I thought I must have clicked on something, so I did a 'copy from placement' and 'save' immediately, then ran another T/M/P. I still got errors - it seems that the output of the P&R doesn't work as input into another round of T/M/P ...

I also noticed that the RPM where the problem was had been split down the middle (surely the point of an RPM was that this didn't happen), and I suspect the mapper is complaining that the RPM it's picking up from the 'rpm_core' directory (in this case an add/sub module) doesn't match the addsub module geometry that was placed in the design on the last pass:

ERROR:Pack:679 - Unable to obey design constraints (LOC=SLICE_X18Y20) which require the combination of the following symbols into a single SLICE component: MUXCY symbol "as/Madd__n0002_inst_cy_0" (Output Signal = as/Madd__n0002_inst_cy_0) MUXCY symbol "as/Madd__n0002_inst_cy_1" (Output Signal = as/Madd__n0002_inst_cy_1) LUT symbol "as/Madd__n0002_inst_lut2_011" (Output Signal = as/Madd__n0002_inst_lut2_0) LUT symbol "as/Madd__n0002_inst_lut2_110" (Output Signal = as/Madd__n0002_inst_lut2_1) The following RPM logic must use the same site due to RLOC origin usage: LUT symbol "z11" (Output Signal = CHOICE404) There are more than two function generators. Please correct the design constraints accordingly.

I have 'Use RLOC constraints' set in the 'Map properties' dialogue, and 'Allow Logic Optimisation Across Hierarchy' is unset in the same dialogue box.

Am I barking up the right tree, here ? Is this a "well-known" circumstance, or have I missed something obvious ?

Thanks for any help :-)


Reply to
Loading thread data ...

Gaaah. For CLB, read 'slice'. It's late :-)


Reply to

Splitting up the carry chains is usually a bad idea. It takes quite a while to get the signal off the carry chain, and then you have to route it back to the bottom of the die. I'm sure you're much better off leaving the carry chain in a single column, and if not, you'd best pipeline the carry.

RPMs are getting a lot better, but there are still some problems. I find it's easier to write a Perl script to create a UCF for you using absolute LOCs. It's kind of a pain, but the tools have no problems with absolute LOCs. You can write a Perl function that will take a root coordinate and creat the LOCs for you. Of course you have to rerun this for different parts or die sizes. The area constraints do work very well. And the placer sometimes (but not always) yields better results than hand-placement.


Reply to
Kevin Neilson

Sorry, not being clear there, the reason I thought a 32-slice tall layout might be a problem is that I didn't want to split the carry chain (which is only 16 slices high).

Normally I'd pack the 32-bit datapath into 16 slices and propogate data horizontally across the chip, but the dual-port, 32bit, 32-way register files were taking 5 columns at 16 slices/column - 4 for the distributed RAM and 1 for a (hgh16/low16) mux because there's only 16 bits storage per lut. I have 2 of them to do 2-read,1-write per cycle, so was losing

10 columns just for the register file in the CPU.

Other components (shifter for example) were bulky as well, and I was getting close to using all the columns by the time the logic was in place. I wanted an instruction cache and a divider yet to ft in, so I thought I'd try a 32-slice high layout, alternating the per-bit LUTs of each datapath component and fitting 2 components (registers/logic/etc.) per column - that way the propogation is still horizontal in the main.

The issue with using 32 slices was carry chains - these fit into 16 slices, and I don't want to break them, so data will have a 'waist' as it routes horizontally across the chip, sort of like:

[]-[]\ /[] []-[]-[]-[] []-[]/ \[]

From my (limited) tests so far, it seems the cpu-16 (ie: fitted into 16 slice-high columns) can run at ~70MHz, but drops to ~50MHz when I wrap the first layer of the SOC around it. The cpu-32 layout starts life at ~56MHz, but only drops to ~53MHz when I wrap the same layer around it.

The reason for the speed drop is the same in both cases - routing the wrapper-layer around the RPM is problematic. There are LUTs in the wrapper that connect to LUTs in the cpu all over the shop :-( It seems the tall-and-thin (and presumably with more routing resource to use)

32-slice high variant is more graceful in its degradation, although the real test will come when I wrap the majority of the SOC around this core, with the associated databusses and address bus...

Your idea of using absolute LOCs sounds intriguing :-) Definitely bears some study to see how I could get it to work... I'm running in Linux now, so Perl/PHP seem so much more natural to use [grin]


Reply to

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.