1. Home
  2. Field-Programmable Gate Arrays
  3. ISE6.1i RPM's, Multipliers and grids

ISE6.1i RPM's, Multipliers and grids

So...if you try to create anything other than the trivial sample RPM's floating about you very quickly discover that your logic can jump all over the place. This is particularly true of non-slice resources.

So... you read a little blurb about RPM_GRID. Which isn't documented very well at all.

So... you try it.

And... all sorts of things begin to break.

Naturally, after burning many hours, questions arise:

If you use RPM_GRID at a given hierarchical level, must every RPM'd submodule instantiated in the lower hierarchies of the module in question also use RPM_GRID?

Can you mix RPM_GRID and non-RPM_GRID coordinates within a module?

A recommendation I found states that RPM_GRID might be better for heterogeneous RPM's that include such things as multipliers and that non-RPM_GRID is more appropriate for RPM's that are limited to slice logic. True?

If you wanted to RPM something like this:

[LUT][FF] [LUT][FF] [LUT] [MULT] [LUT][FF] [LUT][FF] [LUT] [LUT][FF] [LUT][FF] [LUT] [LUT][FF] [LUT][FF] [LUT]

Before RPM_GRID you might set the RLOC's something like this: (simplified notation just to put the idea across)

X0Y3 X1Y3 X2Y3 X0Y0 X0Y2 X1Y2 X2Y2 X0Y1 X1Y1 X2Y1 X0Y0 X1Y0 X2Y0

Now, if you instantiate this RPM several times most primitives will do OK, but it seems that the multiplier RLOC is distorted because the tools apply the same math as they do to other components. So, everything stops and you have to figure it out.

How does one deal with this without resorting to RPM_GRID, which does not seem ready for prime time (see Floorplanner message).

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"
Reply to
Martin Euredjian
Loading thread data ...

you

Martin, Perhaps it's Floorplanner's ability to deal with RPM_GRIDs that's not ready for prime time? I had great success with my manual UCF approach to get my registers placed relative to the BlockRAMs. The RPM_GRID attribute is effectively assigned per-macro. You can't have one macro with a mix of RPM_GRID and standard XY resource gridding.

I didn't touch Floorplanner to get my grid locations. I went straight to FPGA Editor to get the grid locations; you can find those by clicking on a slice or a multiplier and the RPM_GRID XnYm location is displayed with the other information for that resource.

If you want to have macros relative to multipliers or BlockRAMs, you really have to resort to RPM_GRID or absolute LOCs. I don't like LOCs for anything outside of I/O related logic.

Check out the XIlinx application note XAPP416 (

formatting link
) which helped me get my RPM_GRID working for the BlockRAMs. The same info should apply directly to the multipliers.

- John_H

Reply to
John_H

I read XAPP416. Here's one problem:

Page 3. "The RLOC_ORIGIN attribute for an RPM Grid macro must be specified in terms of RPM Grid coordinates."

If you are right in that you cannot mix RPM_GRID with standard grid nomenclature, then, does that mean that you must convert all of your old RPM's to use RPM_GRID? A top module might contain RPM's built out of other RPM's. How do you deal with that?

TOP ----- A ---- B (RPM_GRID used internally to B) \ \---- C standard grid \ \--- D standard grid \ \--E (RPM_GRID based)

With regards to the Floorplanner. I understand that the only way to get RPM_GRID coordinates at the moment seems to be FPGA Editor. Floorplanner is a nice way to quickly look at a design and examine how things are layed out. However, if you use RPM_GRID, immediately upon loading a design it pops-up a window that says that it does not support the RPM_GRID system. My question is: What does this mean? Does this mean that it won't let you grab logic and make one? Or that it won't display one correctly? What happens to all the components that use the RPM_GRID? Are they shown properly? The message all by itself, if you think about it is meaningless without further information.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"
Reply to
Martin Euredjian

other

No, no, no, no.... You cannot mix the regular RPMs and RPM grids *within one macro* but should be able to mix the two with complete freedom (in your UCF, not necessarily the floorplanner).

If you check the constraints guide for the RPM_GRID.... Dang. It's not there. Okay, if you read the comment in XAPP416, it mentions that

"In addition to the RLOC constraints, one symbol in the macro must have the following constraint applied: RPM_GRID = GRID"

The diction makes this a *per macro* constraint. I never intended to imply that everything must be RPM_GRIDed across your design. Old macros should drop in and work. If you want to add a multiplier to an existing RPM, then things aren't pretty but this shouldn't be a problem most people have to deal with.

Did I miss something and all your macros broke when you included only one RPM_GRID macro? Mix and match. Go crazy.

- John_H

Reply to
John_H

I think they did. I say "I think" because this was several layers back (and days) in a troubleshooting session and I don't remember. I'm reasonably certain that this is what happened:

1- Existing macro with regular grid consisting of several RPMs instantiated at the macro's top level. 2- The macro was built with the lower-left component at X0Y0 (SRL) 3- Had problems with multipliers 4- Decided to use RPM_GRID for the multiplier 5- The macro broke (wouldn't implement) 6- Converted all sub-macros to RPM_GRID 7- Had other problems 8- Went back to a non RPM_GRID implementation and used timing attributes to pull the multiplier into the right location. 9- Moved on

I have to say that Xilinx has been very supportive. We are looking into a number of the things I've run into over the last couple of weeks. While no vendor can and will offer perfection, the difference might very well be in the way the user base is supported.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian

To send private email:

0_0_0_0 snipped-for-privacy@pacbell.net where "0_0_0_0_" = "martineu"
Reply to
Martin Euredjian

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.