UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

AR# 13270

4.1i Virtex-II PAR - PC memory usage in Virtex-II designs

Description

Keywords: memory, out, leak

Urgency: Standard

General Description:
A memory leak has been identified in the 4.1i timing algorithms that leads to larger than necessary memory usage. When MPPR is run, the memory loss accumulates until the PAR process fails with an "out of memory" error after several passes.

Solution

1

A fix available in 4.1i Service Pack 3 addresses the bulk of this issue; a further improvement available in the 4.2i software release (late February, 2002) will resolve a smaller-scale leak.

This problem is fixed in the latest 4.1i Service Pack, available at:
http://support.xilinx.com/support/techsup/sw_updates.
The first service pack containing the fix is 4.1i Service Pack 3.

2

In addition to the service pack fixes, the following is some general information about limiting memory utilization in PAR:

Current 32bit OS's, (Win2000, WinNT, WinXP) cannot address more than 2GB per process. Designs that try to address more than 2GB will fail with an out of memory error. This usually occurs during Initial Timing Analysis or during the routing stage of PAR. Below are some recommendations for minimising memory usage so that a design and fit under the 2 Gb limitation.

1. Examine timing constraints. Reducing the amount of path analysis in your design results in a corresponding reduction in memory usage and will also reduce runtime. Rather than defining many seperate constraints to analyse, create timegroups and apply a single constraint to the time group. Relax paths where appropriate, by overriding general PERIOD constraints with FROM(THRU)TO constraints for example.

Make use of TIG statements. Reducing the amount of paths that need to be analysed can reduce the memory usage and again reduce implementation times, i.e. by putting a TIG on the Reset line. However this needs to be done carefully. TIGing paths that are unconstrained will not affect memory or runtime but will remove paths from the unconstrained list. This is mainly for paths between unrelated clocks. TIGing paths are that are constrained (i.e. in a period) can negatively affect memory and runtime. A bunch of small TIGS will result in longer runtime and more memory usage than fewer large TIGS (larger coverage per TIG), so again it is important to think about how you create your timegroups

When creating timegrps for multi-cycle paths or tigs, it is best to group things using the clock signal or a clock enable signal. A timegrp should only have synchronous elements with the same clock. Don't put FFS with different clocks in the same timegrp.

Make the timegroups as complete as possible. For example if FFA, FFB, FFC all go to FFD then FFA, FFB and FFC should be in the source timegroup if they are all clocked by the same clock.

Reduce the effort level
Remove the extra effort, -xe 0

Running some basic tests on a random design the differences between using overall effort level 2 and 5 were minimal, 2% in this instance. When using effort levels of 5, the extra effort level is automatically used, -xe 1. By removing this I found my test design reduced memory usage by 6%, however I have seen reports of 20%. MPPR uses different Cost tables and may place, Route and time the design differently, small fluctuations in memory usage may be seen as well as the possibility of improving timing and runtime with different cost tables. Due to a placer error MPPR is not recommended right now, however running separate placer runs changing -t yourself is a workaround.


Separate the Place and Route process.

Running the Place and Route processes together can result in larger memory usage due to I think, the Placer not releasing all its memory use before the router begins.

Take a standard default PAR run running both place and route

par -w -ol 2 map.ncd <design>.ncd <design>.pcf

Running Place and route separately this becomes..........

par -w -pl 2 -r map.ncd <design>.ncd <design>.pcf
par -w -rl 2 -p <design>.ncd <design>.ncd <design>.pcf

where:

-pl is the placer effort
-r is do not run the router
-rl is the router effort
-p is do not run the placer

Use Solaris, I believe it is currently possible to address to 4GB of Memory

Use a guide file, if necessary use Solaris to create a guide file then use the guide file within your PC flow. A very small test design showed a 12% decrease in memory usage.

Re-evaluate the design to reduce logic, for example are there areas we can use different design techniques to reduce density and
AR# 13270
Date Created 08/29/2007
Last Updated 10/20/2008
Status Archive
Type General Article