Xilinx ISE 不同机器的编译结果是否一样

1万 · 2012-8-6 18:55

看了一下Xilinx网站，根据其所述，对于同一软件版本，同一软件工程，同样的编译选项设置，编译出来的结果应该是一致的——不论你的操作系统，32还是64位，都应该一致，如果不一样，可能是软件的bug，需要Xilinx去解决。我现在就碰到这个问题。不过，正如Xilinx所说的，即使编译出来的结果不一样，但功能应该都是正确的（creates a different, but equally valid result）。对于同一台电脑来说，编译多少次应该结果都一样。

参考1：

10.1 MAP/PAR - Placement phases do not produce same results on different OS platforms
AR# 30404
Part SW-Place
Last Modified 2008-09-09 00:00:00.0
Status Active
Keywords lin32, lin64, win32, Linux Windows, checksum
Description
Keywords: lin32, lin64, win32, Linux Windows, checksum
My design meets timing when I run it on a Windows machine, but not on a Linux machine. Why?

Solution
This problem has been fixed in the latest 10.1 Service Pack available at:
http://www.xilinx.com/support/download/

The first service pack containing the fix is 10.1 Service Pack 1.

Designs should have the same results on different OS platforms (when all else is equal). If not, it is considered a bug and these issues are fixed as they are detected. Usually, the difference is a random effect that produces a different result much like using a different cost table to change the placement seed. In this case, a problem was identified that affected the results of I/O placement.

For a more general discussion of deterministic behavior in the ISE implementation tools, see (Xilinx Answer 23904).

1万 · 2012-8-6 18:55

参考2：

9.1i PAR - WinXP x64 machine produces different results
AR# 24382
Part SW-Place
Last Modified 2008-10-20 00:00:00.0
Status Active
Keywords timing, score, same
Description
Keywords: timing, score, same

I ran PAR on the same design files job on two different platforms (Linux 64 and WinXP x64), and I get different results. Why does this occur, and can I trust the results?

Solution
All platforms should produce the same results with the same input files, same software revision, and same options. When this does not occur in PAR, the difference is often due to a subtle difference in a software function that creates a different, but equally valid result, because of order of processing differences. For example, a sorting function can produce different results and, consequently, a different order of processing. This difference is similar to running PAR with different Cost Tables.

Xilinx has observed a case in which WinXP x64 produces different results compared to other platforms. This problem is currently being investigated with an expectation of being fixed in 9.1i SP1, which is scheduled for early 2007.

1万 · 2012-8-6 18:55

参考3：

10.1i MAP/PAR - Will the Xilinx implementation tools give the exact same results with the exact same source files, system, and software version?
AR# 23904
Part SW-MAP
Last Modified 2009-01-12 00:00:00.0
Status Active
Keywords Implementation, Translate, MAP, PAR
Description
Keywords: Implementation, Translate, MAP, PAR

Will Xilinx implementation tools give the exact same results with the exact same source files, constraints, system, software version, etc.?

Solution
Yes, the Xilinx implementation tools (and XST) are designed to be deterministic, meaning that given the same design, software environment and tool options, the tools will reach the same result. The platform used should not make a difference. The software user issues that can cause a difference in results are:

- Difference in source files
- Difference in tool revision
- Difference in tool options
- Difference in environment variable settings
- Difference in file date stamps (after copy/restore) affecting NGDBuild (use "-nt on" switch as work-around)

If all of these possible differences have been accounted for, differing results from two runs are considered a software defect and should be reported to Xilinx. These problems are fixed when they are detected.

Typical problem areas are the following:

Cross platform differences - For example, a sorting algorithm used might result in a different order of processing on two different platforms (Windows and Linux) resulting in a different final result. Both results are equally valid, and the relative quality of each result is subject to chance, much like choosing different cost table seeds for PAR.

MPPR results do not match Single pass results for the same cost table - This problem can result from the failure to properly reinitialize all variables between MPPR cost table runs. Again, the relative quality is subject to chance.

Typically, single pass runs on the same machine are deterministic. If differences are seen, the source of the difference can be traced to a specific application by comparing the log files for MAP (.mrp) and PAR (.par). Compare the MAP summary information for differences. The PAR placement pass checksum values (XILINX Answer 15611) can be used to identify whether a particular placement pass generated the same results, and if not, determine where the two runs diverged.

关于NGDBuild -nt on
-nt (Netlist Translation Type)
-nt {timestamp | on | off}

The -nt option determines how timestamps are treated by the Netlister Launcher when it is invoked by NGDBuild. A timestamp is information in a file that indicates the date and time the file was created. The timestamp option (which is the default if no -nt option is specified) has the Netlister Launcher perform the normal timestamp check and update NGO files according to their timestamps. The on option translates netlists regardless of timestamps (rebuilding all NGO files), and the off option does not rebuild an existing NGO file, regardless of its timestamp.

1万 · 2012-8-6 18:55

PS:
Xilinx工程中的后缀：
.syr 是Synthesis Report
.bld 是Translation Report
.map 是Map Report
.par 是Place and Route Report
.twr 是Static Timing Report
.bgn 是bitgen report