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