area constraints

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
Reply to
A.y
Loading thread data ...

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.

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.

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).

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

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
 Click to see the full signature
Reply to
Martin Euredjian

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.

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

Steve

Reply to
Steve Lass

hello,

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

The

thank you very much for all explanation but ..

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)!

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

was not aware of that.. thanks a lot :)

--ay

Reply to
A.y

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 ?

thank you very much ay

Reply to
A.y

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.

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.

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

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian
 Click to see the full signature
Reply to
Martin Euredjian

Absolutely.

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

Steve

Reply to
Steve Lass

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

Reply to
A.y

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.

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.

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
 Click to see the full signature
Reply to
Martin Euredjian

hello martin,

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

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 !

u r quite correct ..

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

The subject of RPM's is wide and deep. In order to maximize performance

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..

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 ..

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

Reply to
A.y

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.