How to Increase PAR Effort Level?

[--thatguy]

Hello,

I'm trying to piece together a main LVFPGA application from a number of distinct LVFPGA component projects.  Each of these smaller core functions is running in their own SCTL in the new master LVFPGA file.  The smaller functions all meet timing, however the master app doesn't. 

I'm using roughly half the chip so it seems to me that it shouldn't be that hard to place and route.

When my compile fails due to timing constraints it states the following:

WARNING: Par:62 - Your design did not meet timing.  The following are some suggestions to assist you to meet timing in your design.

 ... 

Increase the PAR Effort Level setting to "high"

Use the Xilinx "xplorer" script to try special combinations of options known to produce very good results.

See http://www.xilinx.com/ise/implementation/Xplorer.htm for details.

So my questions are:

1) How can I increase the PAR Effort Level?  Has NI provided a hook for setting this value and if so what is its current/default level?

2) Do we have user level access to the "xplorer" script?  If so, where is this located and can NI recommend certain settings that will work with the PXIe-5641R.

Thanks

[Jonathan_C]

Hi thatguy,

You can change the Overall Effort Level of the Xilinx compiler by using the -ol switch in a few of the Xilinx .opt configuration files. 

The –ol option sets the overall PAR effort level. The effort level specifies the level of effort PAR uses to place and route your design to completion and to achieve your timing constraints.

If you place and route a simple design at a complex level (high), the design is placed and routed properly, but the process takes more time than placing and routing at a simpler level (std). If you place and route a complex design at a simple level, the design may not route to completion or may route less completely (or with worse delay characteristics) than at a more complex level. This second case is what appears to be happening when you are compiling your code.

Increasing your overall level will enable harder timing goals to be possibly met, however it will increase your compile runtime.  To change the -ol switch, you will need to modify the files named balanced.opt in three locations:
 

1. C:\NIFPGA86\Xilinx\virtex\data\balanced.opt
2. C:\NIFPGA86\Xilinx\virtex5\data\balanced.opt
3. C:\NIFPGA86\Xilinx\xilinx\data\balanced.opt

 
In each of the three files, search for "-ol" without the quotes and then change the -ol switch to high ("-ol high").  The Overall Level may already be set to high in one or more of these three files.  By setting all three, you will ensure that the Xilinx compiler uses the high Overall PAR Effort Level.

It is important to know that this change will result in much longer compile times.  This is caused by the fact that the Xilinx compiler is using a different algorithm to Place And Route everything.  You will likely want to change the -ol switch back to "std" after compiling this code in order to speed up future, less complex designs.

If your code does not compile even after changing this setting, it most likely means that you will need to re-architect the code in a manner that will allow the PAR to complete successfully.  If the compile does fail, attach your code here and we can look through it to find any possible areas for optimization.

[philippe_w]

Actually, please note that for the targets supported by the NI-5640R driver, we override the default settings using custom versions of the .opt files.

The files in this folder override the files in the Xilinx directory:

"C:\Program Files\National Instruments\LabVIEW 8.6\Targets\NI\FPGA\NI-5640R\PXIe-5641R\FpgaFiles"

(and similar for the PCI version or other versions of LabVIEW)

You should only need to make the change to those files to change your compile settings.

Message Edited by philippe_w on 07-07-2009 02:33 PM

[--thatguy]

Ok, I just want to make sure I fully understand this.

I go to "C:\Program Files\National Instruments\LabVIEW 8.6\Targets\NI\FPGA\NI-5640R\PXIe-5641R\FpgaFiles" and change balanced.opt replacing the -ol statements. 

This will ensure that the three balanced.opt files located in "C:\NIFPGA86\Xilinx" folder get replaced.

If so, then I have two questions.

1. I run the compiler on a different machine than where I develop.  Is this going to change the balanced.opt files on the Client, the Server, or both?  Or do I have to manually do the change on the compile server?  A little background on how these opt files are used behinds the scenes when I click compile would help me out. 

2. There are -ol levels for the mapper and the PAR.  Is it in my best interest to go "high" for both or just the PAR? (ie Will improving the mapper improve the PAR?)

Thanks,

--ThatGuy

[--thatguy]

Sorry I'm having a hard time understanding my own question #1. 

It should have read: 

1. I run the compiler on its own server.  Do I need to make the changes on the client side or on the server side?

[philippe_w · Accepted solution]

The files in the Xilinx folder are never overwritten or replaced, those defaults are just not used if you provide your own .opt files to the compile sequence. For these two products, we provide the custom files I've mentioned. Those custom options are communicated to the server on every compile request as it must have everything needed to provide correct results regardless of whether compiling locally or remotely (or even on a remote compile server that doesn't have the target drivers installed).

As far as exactly what effort level settings you need, that is going to be design dependent. I'd suggest looking at the Xilinx documentation about their suggestions on how to set those options based on what kind of compile issues you are hitting. In general, I would probably try increasing them in the following order (probably with increasing compile times):

'map -timing -ol std' and 'par -ol std'

'map -timing -ol high' and 'par -ol std' 

'map -timing -ol high' and 'par -ol high'

[Or if you're just going to run it overnight and don't care about compile time, you could jump to high/high... and work backwards if you want to use the minimum effort that's actually needed.]

If these don't work for you (or if you want an alternate approach), then you'll need to revisit your design and your code to see if you can improve timing in the areas that are causing the failures.

Side-note:

Changing any files in the Xilinx directory does not apply to this situation. I do not know the behavior of changing those files, but it would be easy to deduce through experimentation (i.e. change the file locally, do a remote build, see if the changed options were used, ... if not, then restore the local file, change the remote file instead, rebuild, etc.). But again, this does not apply to these targets and the behavior would need to be verified on a file-by-file basis for a specific version of LabVIEW as this is an implementation detail that could change.