ISE6.1i RPM's, Multipliers and grids

[Martin Euredjian]

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"

 

[John_H]

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:N9uib.745$S06.6@newssvr27.news.prodigy.com...

<large snip>

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,
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
( http://www.xilinx.com/bvdocs/appnotes/xapp416.pdf )
which helped me get my RPM_GRID working for the BlockRAMs. The same info
should apply directly to the multipliers.

- John_H

 

[Martin Euredjian]

"John_H" wrote:

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.

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"

 

[John_H]

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:UjNib.930$wL5.424@newssvr27.news.prodigy.com...

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?

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

 

[Martin Euredjian]

"John_H" wrote:

Did I miss something and all your macros broke when you included only one
RPM_GRID macro?

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_@pacbell.net
where
"0_0_0_0_" = "martineu"