wow.  Thanks a lot Jack!
Paul

On 01/30/2014 10:15 AM, Jack Hickish wrote:
I've toyed with Planahead a bit, and quickly found I was in way over my
head.  Could you recommend a good starting point for learning this tool?
I'm sure you've found the planahead user guide, which is a bit of a
documentation behemoth, but useful if you have a vague idea of what
setting you're trying to change and just want to find the right thing
to click.

There's a reasonable "quick" intro here --
http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/PlanAhead_Tutorial_Quick_Front-to-Back_Overview.pdf

And in general a bunch of tutorials:
http://www.xilinx.com/support/index.html/content/xilinx/en/supportNav/design_tools/planahead.html

A couple of potentially handy methodology guides are also available
for floorplanning:

http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_1/Floorplanning_Methodology_Guide.pdf

And planahead in general:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/PlanAhead_Methodology_Guide_11_1.pdf
(there's probably a more up to date version of this but i haven't
stumbled on it yet)

These are all much shorter than the full user guide, and might help
give a better overview of what's going on. Ryan Monroe also wrote a
summary of some work he did to optimize a ROACH2 design which he
posted on the maillist a while ago:
https://dl.dropboxusercontent.com/u/2832602/roach2_timing.zip

And there's a very brief overview on the wiki --
https://casper.berkeley.edu/wiki/Speed_Optimization_with_PlanAhead

I think some combination of these documents and experimentation is
probably as good a start as any. I'd recommend starting with the
planahead overview, and go from there [with the caveat that I count
myself only marginally proficient with planahead, so ymmv].

Good luck!

Jack


Cheers,
Jack

On 30 January 2014 11:57, Paul Marganian <pmarg...@nrao.edu> wrote:
Thanks Jack and John,
Yes, wtf was certainly the first TLA that came to mind :)

Well, I took my test model and changed the name of a subsystem, and after
compiling, the number of timing errors went from 153 to 151. Obviously
not a
significant change, but the mere fact that they changed at all lends me
to
believe that the algorithm's start seed has indeed been changed.

Is this seed at all exposed in any of the configuration files?  In other
words, is there a way to roll the dice and see if you can get a better
timing score by simply changing this seed and compiling again?

Thanks for your help,
Paul


On 01/29/2014 06:07 PM, Jack Hickish wrote:
I'm not sure what, if any, difference a subsystem will make to the
mapped design (I thought none), but I believe it's the case that
changing module names etc. can affect the place and route algorithm's
start seed. I seem to remember seeing this mentioned in a Xilinx doc
under the heading "I've saved my project under a different name, now
it won't meet timing, wtf?!"



On 29 January 2014 22:44, John Ford <jf...@nrao.edu> wrote:
On 01/29/2014 01:03 PM, Paul Marganian wrote:
Hi all,
Should such software (simulink) features as subsystems and and gotos
have any affect on the final circuit created when I build my bof
file?

I am compiling models on Roach I that use almost all of the available
Logic Slices (~97%).  That the subsequent build should contain timing
errors is not a surprise, but I recently noted a change in my timing
errors that puzzled me.

I have assumed up till now that certain types of features in my model
are superficial, and will not change how the bof file is built.  I
wanted to test this theory, and rebuilt my model after selecting part
of my model and turning it into a subsystem.  I was surprised to see
that this new build had very different timing errors then the
previous
one (from 18 errors to just 3).

Is it the subsystem that caused this change, or is another one of my
assumptions, that timing errors are deterministic and can be
reproduced with subsequent builds of identical models, false?
I've made a test of this, and indeed, I think my assumption is
correct:
I get the same timing errors after two subsequent builds.
Try saving the model and compiling it again, just changing a comment or
something else non-substantive.

John

thanks
Paul Marganian
NRAO, Green Bank




Reply via email to