Re: area constraints

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