--- Quote Start ---
I'm running Quartus 17.0 build 595 lite edition on a windows 10 computer, quad core i7, 2.50 GHz, 16 GB RAM.
--- Quote End ---
Hi ... am seeing very similar things. Currently I'm using Quartus Prime Lite 16.0, 17.0 and 17.1 for various comparisons and benchmarks. I've been using Intel's "MyFirstFPGA" as a benchmark, with command-line launching on Ubuntu 16.04 server Linux.
git clone --quiet https://github.com/intel-iot-devkit/terasic-de10-nano-kit
cd terasic-de10-nano-kit/tutorials/MyFirstFPGA
./build_example.sh
On my normal computer this takes 6 minutes (!), so I'm using rent-by-the-hour servers at AWS. with best performance about a minute.
Following all with "Info: Version 17.0.0 Build 595 04/25/2017 SJ Lite Edition"
70.02 sec aws t2.large ( 8 Gbyte, 2 x Xeon CPU E5-2676 v3 @ 2.40GHz)
64.65 sec aws c4.2xlarge (16 Gbyte, 8 x Xeon CPU E5-2666 v3 @ 2.90GHz)
432.07 sec intel dn2800mt ( 4 Gbyte, 4 x Atom CPU N2800 @ 1.86GHz)
I found this thread at Reddit very good on the same topic, which suggests some interesting alterenatives to using Quartus all day
https://www.reddit.com/r/fpga/comments/7gsqro/quartus_turn_off_optimization/ Why does it take so long? Well, during solving of another problem I ran strace (
http://man7.org/linux/man-pages/man1/strace.1.html) on the generate portion of qsys and found 17,506,064 one-byte write system calls, to make the files
soc_system/synthesis/soc_system_hps_0_hps.svd[ and soc_system.regmap:
4651 open("/home/ubuntu/DE10_NANO_SoC_GHRD/F/synthesis/soc_system_hps_0_hps.svd", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 180
4651 write(180, "<", 1) = 1
4651 write(180, "?", 1) = 1
4651 write(180, "x", 1) = 1
4651 write(180, "m", 1) = 1
4651 write(180, "l", 1) = 1
4651 write(180, " ", 1) = 1
(17.5m more ...!)
I did some quick tests and running the writes together would save about 10 seconds in this one optimisation. I do hope it's not indicative of general code quality.
For what it's worth, I've found 16.0 much more responsive. It does feel like command line is much better for these long "batch" processes.
Kind regards,
Jonathan.
Honored Contributor
