Implementation

[jlqsczw_2007]

http://www.xilinx.com/support/answers/23904.htm

AR# 23904 said ----

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.

But everytime I reimplement the design without changing any option in the GUI.

The final timing and P&R result  are somewhat different.

For example, at first I got 3.401ns,71% slice utilization,  next time maybe   3.258ns and 70% slice utilization.

Why ?

[bwade]

Compare two .map log files (or attach them) and determine where the checksum values for each phase diverge. With that information and your map command line options I should be able to tell you where the problem is. In any case you can open a webcase to report this as a bug.

[dh]

Is this true of all versions of the ISE tools?

I need to pick up an old V2Pro design that uses ISE 6.2.3 and want to make sure I can re-build it before modifying anything.

[bwade]

Yes the intention has always been to have the tools be deterministic. We fix non-deterministic cases as we find them. Right now we're investigating a case where the physical synthesis phase of map sometimes gives non-deterministic behavior. Other issues in the past have involved various placement phases. You can identify the point of divergence by examining the checksum values of the placement phases. If the checksum of the first placement phase is identical that confirms that everything upstream was the same. If the last placement phase is the same but the device utilization is different that points to physical synthesis since that is the only significant post-placement phase.

[rcingham]

There can be differences that are, to me at least, rather surprising. I am currently tidying-up a design before release. I commented-out a redundant BUFG (reported as "will be trimmed" by XST), and the resultant BIT file was very different from that before.
Virtex-4 and ISE 10.1, BTW.

Addendum:

Commenting out the apparently-redundant BUFG moves all the as-implented BUFGs down one, for reasons I don't understand. I might try fixing them with LOC constraints.

[shomms]

Hi,

I am in a similar situation- trying to figure out why the same source is producing slightly different results.  We use git for version control, and I am producing a fresh clone and trying to get the same results and it does not appear to work that way, much to my disappointment.  I'm glad I found this post, though, so I don't continue to try to figure out where the differences are coming from and rather just live with it, I guess.

My first few checksums are identical between builds, but they start to differ after Phase 10.8 Global Placement.  So, I believe this is telling me that the differences are occurring within Map... correct?  I was also surprised, however, that doing a diff on the .ngc files produced by XST show that they are different as well.

I'm running on the same machine (running Linux) and of course same tools.  However, cloning in git does cause different date codes on my files, so I wonder if that will show up in some of the resulting files somewhere (headers appended to the .bit file, etc.)...?

Any guidance here is appreciated!

Mike Shogren
Director of FPGA Development
Epiq Solutions

[bwade]

NGC files have date stamps in them so it is normal for them to fail a diff test. The identical checksums up until global placement are proof that the front end tools produced the same result but that you have run into a non-deterministic behavior bug in the placer. This is the most common area for such bugs. Please open a webcase to get this investigated if you are able to submit a test case.