Not that I am aware. Another approach is to use a script instead of a makefile. The script can then create the project file so you do not to manually edit multiple files.
You can use TCL to drive the ISE tools. The ISE tools will generate example code for you. More information on using TCL can be found here, http://devbisme.webfactional.com/blogs/devbisme/2012/04/03/running-weeds
If you want a Python option for building Xilinx ISE projects, see Guenter Dannoritzer's Python scripts, which generate the underling tcl, but the OO interface in Python is better than generating tcl directly, http://www.myhdl.org/doku.php/projects:ise_py. I have made some updates to the scripts here, https://bitbucket.org/cfelton/examples/src/tip/tools
An example, you can quickly and as easily create an ISE project.
# set up pin configuration for the FPGA
fpga = Fpga(path=ppath)
fpga.setPin('clk', 'P124')
fpga.setPin('srst', 'P8')
fpga.setPin('led<0>', 'P92')
fpga.setPin('led<1>', 'P93')
fpga.setPin('led<2>', 'P95')
fpga.setPin('led<3>', 'P96')
fpga.setPin('led<4>', 'P97')
fpga.setPin('led<5>', 'P98')
fpga.setPin('led<6>', 'P99')
fpga.setPin('led<7>', 'P100')
fpga.setDevice('spartan3', 'xc3s400', 'tq144', '-5')
imp = Xilinx(ppath, 'stroby')
imp.setFpga(fpga)
imp.addHdl((vfile))
imp.createTcl()
imp.run()
Looking through your timing report, there is nothing that indicates a potential issue. Since you have a problem, this means that the scenarios that static timing analysis (STA) is checking are not covering the actual usage of your circuit.
Without any serious setup of STA, some common assumptions are that all inputs are valid by the time the clock rises, and that all states are known (meaning a logic 1 or 0). Immediately, the UUUUUUUU on bus3 looks very suspicious, and is a possible issue with initialization. In logic simulations, U implies that the line is either a 1 or 0, but a register driving it was not initialized properly. This could cause the simulator to give weird answers until all registers are loaded or reset. However, this problem manifests itself in later cycles after all registers have been initialized.
The other potential issue is bus1 starts in a high impedance state (ZZZZZZZZ). Considering that tri-state is not usually assumed in timing analysis, this is the most likely source of the timing discrepancy. Tri-state conditions must be carefully coded into your STA tool in order for them to be considered. This can be a very difficult task, and is prone to error (incorrect programming, missed cases, etc.). I believe that programming in tri-state delays would most likely give you an accurate STA result that should match your simulation.
However, tri-state is usually a bad choice for on-chip communication for both ASICs and FPGAs. This ambiguity of STA reliability, potential for bus contention, and the uncertainty of drive strength requirements make tri-state more likely to cause problems than fix them. The safer method is to use a multiplexor to select which source "talks" to the bus, or partition the design differently. I would only use tri-state when I know it will solve more issues than it can cause.
Best Answer
No. Only the vendor's tools produce .bit. But you can use many for simulation. You may just need a Xilinx library for it.