Minimig verilog build with makefiles.

[freqmax]

I have created this automatic makefile system for Minimig verilog sources. The compilation should result in a working .bit file suitable for use directly on a sd-flash.

Requirements: Linux, or Linux api emulation (such as found in *BSD), might work with win32 enviroment. Tested with Xilinx ISE 8.1i
4m16s is the current synthesis, place & route "compile" time.

File to download:
http://filewebhosting.com/download.php?file=476Minimig1.tar.bz2
(tar + bzip2)

If you do try the Minimig verilog compile, please post: CPU type, CPU frequency, Memory size, Memory type, and Operating system you used. And how much total time that was needed to generate the *.bit file.

[freqmax]

An important note, please don't upgrade the sourcecode. I like to keep this package as a benchmark. And the makefile is GNU Make style (notice for the *bsd users out there).
I will eventually put together an autoboot CD that will run this test and check all computers in a shop (they seem easy to get along with).
I had some discussion earlier in regard to Synth/Place/Route speeds. And the consensus was that primarly L1 cache and memory speed is the main limiting factor. So AM2 socket mainboards may be of interest. Also >256M ram recommended :-D
The P&R process is romoured to slaughter any cacheing..

@Dennis: (or any other maybe)
Are the *.ut/*.xst option details alright?, I did this test in a hurry.

An off topic question, what rise and input capacitance is suitable for <100MHz oscilloscope probe ..?
I'm looking at one with 90 pF and suspect it's too much. But  maybe it's good enough.

@alexh:
Thanks for the benchmarks!

@Oliver:
It might run just fine without mods in win32 enviroment. It's the makefile, paths, and .exe suffix that might screw things up I suspect.

[freqmax]

What do you think about timing.., is there some incorrect file?
I had a comment that it did not meet timing. But appearently it does work. :-D
I suspect I might have accidently written some timeing constraint that isn't needed.

[freqmax]

@alexh:
I didn't find any timing constraints supplied by Dennis, but the *.ucf file was used. I have not tried the resulting *.bit file. I will worry of that 'bit' when I got a physical board to try it out on:-D

The speed difference might be because that "Intel Core2Duo x6600" have two cpus to work with. While "Intel Xeon" have just one (or x2=two cpu cores?). And Xeon is optimized for 64-bit operation. While not all software is compiled appropietly to benefit. Also maybe earlier versions of ISE that don't multithread might indicate differences not otherwise seen.
Xeon is mainly Intels attempt to beat AMD64, not to benefit customer.. Besides that it have a lot of protective stuff like ECC that might slow onchip propagation.
http://en.wikipedia.org/wiki/List_of_Intel_microprocessors#Pentium_II_and_III_Xeon

Check the L1 and L2 cache sizes for your cpus. They may certainly explain some.