Xilinx 8.2 : Multippass P&R

I think you can monitor the des.par file created next to the des.dir directory. It gives you something like: Constraints file: ../map/rmpl_4.pcf.

Level/ Design Timing Number Run NCD Cost [ncd] Score Score Unrouted Time Status

---------- ------ -------- -------- -----

------------ H_S_2 * 215636 262882 0 31:23 Complete H_S_3 * 265943 228477 0 40:51 Complete ...

• : Design saved.

It seems to be updated after each run. I think I was using ISE 7.1 at the time. Once you find "design score" or "timing score" (see xilinx AN3749) equal to zero you can kill the par process and use the working one.

I also tried to run multipar with high placer effort (-pl high) but lower routing effort (-rl std) to find the best place result, then reroute (par -k) this with higher routing effort (-rl high).

I used this script to parse the .par file (hope it still works):

# This script returns the path to the "best" result from mppr. Lower Design score is better. # Only look at files which have a "*" (design saved) and NCD status complete. # $1 is the mppr.par file to parse, $2 is the ranking to use, default is 1 (i.e. best) # $1 also hints about the directory due to xilinx's naming convension. file=$1 result_dir=$(echo $file | sed -e "s/\.par/\.dir/")

if [ "$2" = "" ]; then rank=1 else rank=$2 fi

best_result=$(cat $file | grep "\\*" | grep "Complete" | sort -n -k3 | sed -ne "${rank}p" | sed -e "s/[ \t].*$//")

echo "${result_dir}/${best_result}.ncd"

#last line

I'm not sure if they fixed the bug in 8.2, but in older versions of ISE, the results for multipass place & route did not necessarily correspond to the single-pass results for the same cost table entry.

In any case if you're using a script to run place&route, why not let the script handle multipass using the -t command line argument to set the cost table entry on each pass. Also many times you get better results by using the timing option for map. In this case you'll find that multipass place&route doesn't help much because it starts from a more completely mapped design. A script could re-run map and place&route with a new cost table entry each pass, then look at the report file as mentioned to decide when to stop.

HTH, Gabor

Hi Gabor,

I'm afraid that your post goes beyond the level of my knowledge :-(

Can you please clarify what a "Cost Table Entry" is, and how do you select one.

Thanks,

Steven

Thanks. This is just the information I was after.

Steven

If you look in the Development System Reference Guide, it lists all of the command line options for "par" (place&route). The -t option sets the starting "Placer Cost Table". I'm not sure why they call it that (maybe someone from NeoCad can give a hint?) but it is essentially a seed for initial placement. This is the number that is incremented on each pass of multipass place and route. If you don't specify a number it defaults to 1. So in your case:

par -intstyle xflow -n $Num_Iterations -w -xe c -ol high -ub

is similar to

for $iteration = 1 to $Num_Iterations

par -intstyle xflow -t $iteration -w -xe c -ol high -ub

This runs one place and route pass per loop rather than letting par.exe determine the number of loops. Map, when timing mode is enabled, also allows you to specify the starting placer cost table. This is a newer feature than the 6.1i that I normally work with. I know it's in 9.1i anyway. If you use the GUI, look at the properties for Map and make sure you have advanced properties displayed. The first item is "Perform timing driven packing and placement". If you check this box the settings for effort level and starting placer cost table will be enabled. You'll need to look at the Development System Reference Guide to see how to do this from the command line, or you can run map from the GUI and see the command in the log file.

HTH, Gabor

You might also be able to improve your results by varying your timing constraints slightly instead of using a separate cost table. (I've recently played with a design which would meet timing with a cycle time constraint of 4.8 ns, fail at 4.9 ns and succeed again at 5.0 ns. )

/Andreas

MPPR may not be the best idea here; (a) because you have to "kill" it when done, and handle the resulting file renamings yourself, and (b) because when a PAR aborts with the famous "portability errors", it also kills MPPR instead of starting the next pass at PAR. So you find out next morning, MPPR stopped about ten minutes after you left the office. Unless PAR has become 100% reliable since 7.1...

Consider a shell script which launches PARs one at a time ( for bonus points, n at a time on a multi-core machine!), each with a separate cost table entry (-t nn).

The script will have to look at each .PAR file (once the PAR has completed) and search for "all constraints were met" or the appropriate phase.

- Brian

There actually is a TCL command interface available in the current ISE version. (I think it was added in ISE 8.2.) Some documentation is available in the $XILINX/doc/usenglish/books/docs/dev/dev.pdf file of your ISE installation. You can either use the TCL prompt in Project Navigator or use xtclsh directly it seems.

Is your experience regarding timing constraints for ASIC synthesis/backend tools the same as mine in regards to FPGA synthesis/backend tools?

I actually don't find the Xilinx command line tools that limiting if you have a decent framework to use. If you are interested I have a Makefile based flow for synthesizing an FPGA design available for download on my homepage which could serve as inspiration. Look for the PPC405 based design on

(No EDK is needed for this design.)

/Andreas

This is certainly something I do with ASIC synthesis tools (synopsys). It was quite easy using the TCL command interface, which I don't think is available using ISE (please correct eme if I am wrong).

One of the problems I am finding with the (admittedly free) Xilinx tools is poor command line and scripting capabilities. Real engineers don't use GUI's ;-)

Brian, Gabor

Thanks for pointing me in this direction. I will update my scripts to use a manual multi-pass P&R approach. It definitely provides a more flexible and (hopefully) controllable route.

Thanks for all the help.

Steven

Hi Andreas,

Thanks for the links - I'll have a look at it.

As for the ASIC synthesis tools,. my primary experience is with synopsys dc_shell, and varying the timing constraints slightly definitely improves the overall QOR. Unfortunately it's a bit of a black-art. e.g. If you missed timing by 5%, and then tightened the constraints by

5%, you would miss timing by 5% of the new constraints, so are meeting your original contraints.

Steven