area constraints

[A.y]

hi,
I have some elementary doubts regarding flooplanning ..
hoping a quick guidance here ..(not a hw)
In xilinx floorplanner or manualy (using ise 5.1)
1. Can i assign flexible area constraints to individual modules in a design..
i mean, can i say a module shud fit in this much area of some shape ..
without specifying absolute slice locations in area group ? .. and
2. can structures other than rectangle be specified ?
i guess i am missing something obvious ?
thanks a lot,
ay

 

[Martin Euredjian]

"A.y" wrote:

1. Can i assign flexible area constraints to individual modules in a
design..

Depends on your definitions of "flexible", but, yes, you can identify all
the logic for a given module and assign an area constraint to it.

i mean, can i say a module shud fit in this much area of some shape ..

You can't say that a module "should fit" a given area. What you say is
something like "don't put logic for this module outside of this area". The
area has to be large enough for the grouped logic. Easiest way to find out
is to use the Floorplanner to gather the logic you want to constrain. While
creating the area constraint graphically, it will tell you what percentage
of the selected logic fits within the rectangle you are defining.

without specifying absolute slice locations in area group ? .. and

Well, you do define an area within the chip. Not sure what you mean here.
If you want something that will maintain a given layout as you move it about
a chip you have to use RPMs. Even then, crossing certain boundaries gets
complicated (embedded multiplier columns).

2. can structures other than rectangle be specified ?

Sure, you can specify multiple rectangles to form other shapes.



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

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Steve Lass]

A.y wrote:

hi,
I have some elementary doubts regarding flooplanning ..
hoping a quick guidance here ..(not a hw)
In xilinx floorplanner or manualy (using ise 5.1)
1. Can i assign flexible area constraints to individual modules in a design..
i mean, can i say a module shud fit in this much area of some shape ..
without specifying absolute slice locations in area group ? .. and

You can specify that the module(s) should be grouped together, but you

can't specify the size and shape
unless you give it a location.

2. can structures other than rectangle be specified ?

You can put multiple rectangles together to form T, L, U, etc. shapes.

PACE is the easiest way to
create these area groups.

Steve

i guess i am missing something obvious ?
thanks a lot,
ay

 

[A.y]

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<wJLwb.54017$hW7.28499@newssvr25.news.prodigy.com>...

"A.y" wrote:

1. Can i assign flexible area constraints to individual modules in a
design..

Depends on your definitions of "flexible", but, yes, you can identify all
the logic for a given module and assign an area constraint to it.

i mean, can i say a module shud fit in this much area of some shape ..

You can't say that a module "should fit" a given area. What you say is
something like "don't put logic for this module outside of this area".

hello,

yes i guess these were the better words ..
but still, whether the tool really doesn't put the logic outside the
area ?

The

area has to be large enough for the grouped logic. Easiest way to find out
is to use the Floorplanner to gather the logic you want to constrain. While
creating the area constraint graphically, it will tell you what percentage
of the selected logic fits within the rectangle you are defining.

thank you very much for all explanation but ..

without specifying absolute slice locations in area group ? .. and
Well, you do define an area within the chip. Not sure what you mean here.

this was infact the "main" doubt that can i constrain the module
within a area ..
something like an rpm .. but not specify the coordinates of origin ..
and definitely
not the relative LOCS .. don't know how much it cud be better/worse
information to
the placement algorithm than other styles (rpm/area groups)!

If you want something that will maintain a given layout as you move it about
a chip you have to use RPMs. Even then, crossing certain boundaries gets
complicated (embedded multiplier columns).

i think rpms can cross such boundary.. not very sure .. my manually
created rpm crossed it!

2. can structures other than rectangle be specified ?

Sure, you can specify multiple rectangles to form other shapes.
was not aware of that.. thanks a lot

--ay

 

[A.y]

Steve Lass <lass@xilinx.com> wrote in message news:<bq017p$ha32@cliff.xsj.xilinx.com>...

A.y wrote:
In xilinx floorplanner or manualy (using ise 5.1)
1. Can i assign flexible area constraints to individual modules in a design..
i mean, can i say a module shud fit in this much area of some shape ..
without specifying absolute slice locations in area group ? .. and

You can specify that the module(s) should be grouped together, but you
can't specify the size and shape
unless you give it a location.

hello,
thank you very much for the reply.
could this have been be a useful facility ?
if yes will it be available in future releases ?

2. can structures other than rectangle be specified ?

You can put multiple rectangles together to form T, L, U, etc. shapes.
PACE is the easiest way to
create these area groups.

Steve

thank you very much
ay

 

[Martin Euredjian]

"A.y" wrote:

but still, whether the tool really doesn't put the logic outside the
area ?

Not sure I understand what you are asking here. If the area isn't large
enough to contain the logic you constrained within it the tools will fail
and issue an error.

this was infact the "main" doubt that can i constrain the module
within a area ..
something like an rpm .. but not specify the coordinates of origin ..
and definitely

An area constraint, as far as I know, can only be done as an absolute
location. That's one of the reasons a lot of people don't recommend you use
them. They don't move easily from chip to chip. RPM's can move. This is
particularly true if done intelligently and hierarchically from within HDL.
For example, if you downsize your design from an XC2V2000 (say on a generic
dev board) to an XC2V500. A lot of your area constraints won't make any
sense at all. Hierarchically placed RPM's however, should retain their
structure and might only require repositioning in order to port.

i think rpms can cross such boundary.. not very sure .. my manually
created rpm crossed it!

Cross it they will. Cross it the way you thought they would, they may not.
Look into RPM_GRID.


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

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[Steve Lass]

A.y wrote:

Steve Lass <lass@xilinx.com> wrote in message news:<bq017p$ha32@cliff.xsj.xilinx.com>...


A.y wrote:


In xilinx floorplanner or manualy (using ise 5.1)
1. Can i assign flexible area constraints to individual modules in a design..
i mean, can i say a module shud fit in this much area of some shape ..
without specifying absolute slice locations in area group ? .. and



You can specify that the module(s) should be grouped together, but you
can't specify the size and shape
unless you give it a location.



hello,
thank you very much for the reply.
could this have been be a useful facility ?

Absolutely.

if yes will it be available in future releases ?

Yes, but it might take a year or two to finish.

Steve

2. can structures other than rectangle be specified ?



You can put multiple rectangles together to form T, L, U, etc. shapes.
PACE is the easiest way to
create these area groups.

Steve



thank you very much
ay

 

[A.y]

thanks all for clearing my doubt..
in fact my design is consuming 99% slices (69% FFs and 67%LUT ) (is
this figure/ratio normal ?)
... in xc2v3k it's having 5-6 heirarchy levels .. and i am in dilemma
how to go about
floorplanning this design .. i don't know if i shud make rpms of each
module from the bottom ?
make everything rpm or keep some modules as rpm and make area groups
for higher levels ?
experimenting all things cud take a long time .. that's why a want to
have some advice
from the expert ..
in one line what is the general procedure to extract the best
performance(important)
as well as runtime from the tool in case of high density designs ?

regards
ay

 

[Martin Euredjian]

"A.y" wrote:

in one line what is the general procedure to extract the best
performance(important)
as well as runtime from the tool in case of high density designs ?

Hard to do this in one line!

Performance
---------------------------------------
First, what is "performance". For some designs it is about placing the
required functionality in the smallest and least expensive device. For
others it is purely about speed. And, of course, there's the middle ground,
where give and take is king.

I'll take "performance" to mean speed, MHz, clock rate.

In general terms, I think you start exploring "best performance" when
you've hit a limit somewhere. For example, if you are doing a design one a
VII running at 20MHz there's probably little need to waste any time doing
anything beyond specifying PERIOD for good measure. As the clock rates
increase and the complexity of the design grows you may hit spots where the
"insert a coin and pull the lever" path simply does not work.

Should you hit that wall, the first place to look is your HDL. There
are ways to describe circuits that simply don't translate into an
implementation that will run very fast at all. Search the NG and 'net for
HDL coding style references.

The prior step was about HDL coding styles that don't synthesise very
well, not about choosing a particular solution or circuit, if you will.
Once you get decent synthesis, if performance isn't sufficient the next
question is: Is the chosen way to solve the problem the best (from a
performance (speed) standpoint). For example, if you are trying to add a
couple dozen values, a pipelined adder will run substantially faster than a
parallel adder (at the expense of latency).

For a new design the above two steps would proably be swapped as you'd
want to zero-in on a good approach to solving a problem first and then make
sure that the HDL implements it efficiently. For an existing design that
needs fixing, you may have to take them in the sequence I presented.

If you did the above and still can't achieve the performance requirement
for your design you need to go in at a different level.

There are simple things you can do that might make a big difference, in
no particular order:

- Do you have any FF's that should be in the IOB's?
- Increase tool effort levels
- Over constrain the PERIOD specification
- Identify false paths and "TIG" them
- Multi-cycle paths
- Going far/wide/fast? Can you insert additional FF's in the path?
- Consider device-specific resources (example: use registered
multipliers)
- Can you fold combinatorial logic into fast embedded rom lut's?

Beyond this you have to get into RPM/Floorplanning mode. I think I can
say that RPM's are the better way to go. Area constraints can be
problematic and, in an evolving design, there can be a bit of a
chicken-and-egg scenario. Hierarchically built RPM's done in HDL, of
course, is the best approach from many standpoints.

The subject of RPM's is wide and deep. In order to maximize performance
you need to acquire a full understanding of the routing resources and how to
use them. Just 'cause the layout looks good on the screen it doesn't mean
that it will run the fastest. Many, many hours (days, months, years?) of
work are required in order to fully understand this topic.

<business hat on>
Depending on your design's constraints you might be better advised to
move up to a faster device rather than undertake layout at this level.
Purists might cringe, but I think that most will agree that sometimes it is
better to spend more money on a chip and get the design out the door than to
try to optimze a design to death just for the sake of superb engineering.
<business hat off>

There's also the idea of using FPGA's properly. Something that I see
come up frequently are wide, parallel and slow designs that consume lots of
chip resources (both logic and routing). The significance of this in terms
of design performance (speed) is that these highly parallel structures do
eat-up routing and do push and shove other modules within the chip. Routing
can be complicated by this approach to a level that it could compromise
performance. Many of these wide/parallel/slow designs can be changed to
serialized high speed designs to take advantage of the fact that FPGA's can
run so darn fast. Do that and save lots of resources for fast parallel
logic. It's amazing to me how many people never take advantage of this
wonderful trick that is basicly free. A FF can run at 5 MHz just as well as
200MHz, running it slow might just be a total waste.



Tool runtime (process optimization)
---------------------------------------
This is simpler ... and not. You have five choices:

1- Simulation
2- Simulation
3- Simulation
4- Modular design
5- Incremental design

The first three look very similar. There's a message here: Don't try
to use synthesis and hardware to verify logical design and algorithms. That
very time consuming. Simulation is orders of magnitude faster. Go to
hardware when you know that the design (or design's components) work in
simulation. A full simulation isn't required, sometimes you can use test
vectors to check modules in isolation of other parts of the design.

Modular design is more appropriately used within the context of a team.
Incremental design works for single-developer mode. The idea is simple:
limit time consuming processing to modules that have changed since the last
run. Performance improvement can be dramatic.

However --there's always one of those-- it is best to start a project in one
of these modes as opposed to trying to convert an existing project. There
are very specific inter-module (and other) requirements that must be taken
into account. Check the manuals for further detail here.


Hope this helps. Sorry that I couldn't fit it in one line. Not that I
tried.



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

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_" = "martineu"

 

[A.y]

hello martin,

accept thanks from my heart for devoting your precious time to write
this all.

Hard to do this in one line!

pl forgive my english, it was 'my' one line of question
I do understand it was very vague question .. but let me clear my
intentions ..
I can't say how good are my architectural decisions, hdl coding
style, synthesis strategy ..
and control over xilinx tools.. but i have spent a good time over
this design ..
but things boil down to my eagerness to do the "superb engineering"
... throw off the
business hat for the time being ..
may be i can do optimize and reduce the usage for my device ... but
u can assume that
i won't stop adding something more into it !

I'll take "performance" to mean speed, MHz, clock rate.

u r quite correct ..

- Do you have any FF's that should be in the IOB's?
- Increase tool effort levels
- Over constrain the PERIOD specification
- Identify false paths and "TIG" them
- Multi-cycle paths
- Going far/wide/fast? Can you insert additional FF's in the path?
- Consider device-specific resources (example: use registered
multipliers)
- Can you fold combinatorial logic into fast embedded rom lut's?

pretty good things ,, possibly known to me , and i am searching if
something
is possible.. i do have some spare mults and brams !

Beyond this you have to get into RPM/Floorplanning mode. I think I can
say that RPM's are the better way to go. Area constraints can be
problematic and, in an evolving design, there can be a bit of a
chicken-and-egg scenario. Hierarchically built RPM's done in HDL, of
course, is the best approach from many standpoints.
The subject of RPM's is wide and deep. In order to maximize

performance

you need to acquire a full understanding of the routing resources and how to
use them. Just 'cause the layout looks good on the screen it doesn't mean
that it will run the fastest. Many, many hours (days, months, years?) of
work are required in order to fully understand this topic.

yes, this_is_what my engineering senses want to explore more ...
i think i am a newbie in the rpm world .. would you suggest some good
reading for heirarchical
rpms ? and not only for now this will help me in future also..

There's also the idea of using FPGA's properly. Something that I see

yes some tricks i have learnt/been learning like using srls, cy logic,
mults, luts, brams
in xilinx in a better way.. thanks to techexclusive and this forum ..

Tool runtime (process optimization)
---------------------------------------
these all are excellent concepts but you pull your hair when you do

a very small thing and
the tool shouts with the errors and warnings .. then you open the
browser search for the
workaround .. if found understand it .. and try to do if it works ..
everything fine then !?
u basically shift ur figures of cpu usage from ngdbuild/map/par to
netscape/opera/iexplorer
(just kidding) but equally true .. we do learnt a lot from mistakes

thanks you very much for all your inputs.

regards
ay