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.

[Oliver]

OT If someone's trying to do this in Windows, you may like to have a look at Cygwin; Linux like environment for Windows.

[alexh]

In Windows I prefer to use the GUI. Doesnt take long.

[Dennis]

Posting the compile times would be usefull.
Usually computers are benchmarked by the fps they can produce in doom3 or how long they take to rotate a .jpg in photoshop. I would be interested in how fast they are when synthesizing Minimig code  :-D .
I recently moved from a P4 3GHz to an X2 5600+ and that made a huge difference (2-3 times faster) I will try to do some benchmarks tonight.

[alexh]

Dennis wrote:
Posting the compile times would be usefull.
I would be interested in how fast they are when synthesizing Minimig code  :-D .

Computer A :
Intel Core2Duo x6600 2.4GHz
4 Gig RAM,
RedHat EL Workstation 4 (2.6.9-42.ELsmp)
Xilinx tools v9.1 (64-bit)

128.00 seconds (Synthesis)
2 min 9 seconds (Place and Route)

Total time 4 min 45 seconds

(Could possibly been faster if I hadnt been using a network drive)

Computer B:
Intel Quad core Xeon 5160
16 Gig RAM,
RedHat EL Workstation 4 (2.6.9-5.ELsmp)
Xilinx tools v9.1 (64-bit)

112.00 seconds (Synthesis)
2 mins 4 seconds (Place and Route)

Total time 3 min 56 seconds

(Could have been faster but there were 2 other people using it at the same time, damn you TetraMax!).

[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.

[alexh]

This time with no one else on it and running from a local drive.

Computer B:
Intel Quad core Xeon 5160 3GHz
16 Gig RAM,
RedHat EL Workstation 4 (2.6.9-5.ELsmp)
Xilinx tools v9.1 (64-bit)

96.47 seconds (Synthesis)
1 mins 37 seconds (Place and Route)

Total time 3 min 20 seconds

[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.

[alexh]

I saw many warnings including that it didnt meet timing, but I didnt have time to analyse. I also saw lots of warnings about asynchronous RAMS and blockRAM usage.

Does this makefile use the timing constraints and pin file that came with MiniMig?

Did a bitfile compiled with this makefile ever get loaded onto a MiniMig and work?

[Oliver]

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

OK, cheers. I've not tried it.

Alexh wrote:
In Windows I prefer to use the GUI. Doesnt take long.

Thanks for the tip.

[alexh]

Computer C:
Intel Xeon 3.6 GHz (x2)
6 Gig RAM,
RedHat EL Workstation 4 (2.6.9-22.ELsmp)
Xilinx tools v9.1 (64-bit)

264.40 seconds (Synthesis)
3 mins 59 seconds (Place and Route)

Total time 8 min 32 seconds

Surprisingly slow compared to Computer A which cost half the price and has over 1GHz slower clock!

[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.

[alexh]

freqmax wrote:
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?).

Both have two CPU's but the tools only ever use 1.

freqmax wrote:
And Xeon is optimized for 64-bit operation. While not all software is compiled appropietly to benefit.

Both are 64-bit optimized and both were running the 64-bit version of the tools.

freqmax wrote:
Also maybe earlier versions of ISE that don't multithread might indicate differences not otherwise seen.

AFAIK all versions of ISE are single threaded. I dont know what the latest version is, I was using v9.1

freqmax wrote:
Xeon is mainly Intels attempt to beat AMD64, not to benefit customer..

I am not 100% familiar with the term AMD64, but Xeon chips are high end server / workstation chips. Their equivalent are AMD OPTERONS. Xeon chips pre-date Opteron's.

Regular Intel CPU's (not just Xeon) have been 64-bit for a very long time. At least 3-4 years.

My comment was more of a statement. I couldnt believe that todays cheap Intel CPU's are now more powerful than their most expensive workstation chips from only a year previous.

[HenryCase]

freqmax wrote:
Xeon is mainly Intels attempt to beat AMD64, not to benefit customer..

I am not 100% familiar with the term AMD64, but Xeon chips are high end server / workstation chips. Their equivalent are AMD OPTERONS. Xeon chips pre-date Opteron's.

I believe this confusion has arisen through a misunderstanding on the families of 64bit processors.

Alexh, as you rightly stated, the closest equivalent to an Intel Xeon is an AMD Opteron. Both chips come in 64bit flavours, both are designed with the server/mainframe market in mind.

What I believe freqmax is referring to is the AMD Athlon 64, which is the first 64bit processor aimed at the consumer market. This was launched back in 2003. The first 64bit CPU Intel designed for the consumer market was a version of the P4 which was launched after this time. I've heard in a couple of places that the 64bit architecture AMD designed was copied by Intel. In fact you can read about this here:
http://en.wikipedia.org/wiki/X86-64

Hope that helps.