[hdl_student 0]

On 12/7/2018 at 5:23 PM, JustaK said:

65Гб

Судя по объему, видимо, собираете на серверном железе. Если оставить за скобками партиции, то большинство алгоритмов Fitter-а однопоточные, поэтому тут важна производительность на одно ядро, а не число ядер. Поэтому для работы в Quartus более подходит "игровой" ПК с быстрым процессором на высокой частоте, нежели сервер с большим числом более медленных ядер. Это актуально для сред Xilinx, Altera, а также для симуляции в Modelsim.

 

Quartus Handbook: Reducing Compilation Time (https://www.intel.cn/content/dam/altera-www/global/zh_CN/pdfs/literature/hb/qts/qts_qii52022.pdf):

Quote

 

You can reduce the compilation time by up to 10% on systems with two processing cores and by up to

20% on systems with four cores. With certain design flows in which timing analysis runs alone, multiple

processors can reduce the time required for timing analysis by an average of 10% when using two

processors. This reduction can reach an average of 15% when using four processors.

 

 

https://forums.xilinx.com/t5/Simulation-and-Verification/Benchmark-gt-which-CPU-i7-or-Xeon/td-p/359461

 

Для сравнения можно взять бенчмарки процессоров по одному потоку: https://www.cpubenchmark.net/singleThread.html

При сравнении можно оценивать Clock Speed в режиме "Turbo".

[DocNo 0]

Quartus никогда не загружает процессор на 100%. Тут действителько важна максимальная частота ядра, а не их количество. Например свой i7 3770K разгонял с 3,5ГГц до 4,9ГГц скорость компиляции была почти в 2 раза быстрее.
Старый Quartus 9.1sp2 самый быстрый, но Stratix V GX там нет. 
Для Stratix V GX можно попробывать поставить (10.1, Service Pack 1) или (13.0, Service Pack 1).
Я ставил разные версии с 9-й по 17-ю и проверял скорость компиляции. Сделал вывод - чем новее версия, тем медленнее компиляция.
Проект на Cyclone V компилируется полностью в Quartus 15.1 за ~8 минут, а в Quartus 13.0sp1 за ~5 минут.
Ещё можно ускорить процесс запуская только нужные этапы через TCL-script:
execute_module -tool map
execute_module -tool fit
execute_module -tool asm
Ещё команды для TCL: "asm, cdb, drc, eda, fit, map, syn, pow, sta, stp, sim, si, cpf, ipg"

[Doka 1]

On 12/16/2018 at 3:43 PM, hdl_student said:

поэтому тут важна производительность на одно ядро, а не число ядер. Поэтому для работы в Quartus более подходит "игровой" ПК с быстрым процессором на высокой частоте, нежели сервер с большим числом более медленных ядер

золотые слова. тоже достаточно быстро к этому пришли. к тому же сейчас топовые десктопные процессоры имеют 6..8 ядер (что полезно при распараллеливании на некоторых стадиях)

-----------------------------

 

 

по поводу ускорения опциями, про которые еще не было упомянуто в теме: не скажу за квартус, но наверняка как и в вивадо там есть стратегии реализации, как-то:

• RuntimeOptimized
• AreaOptimized
• SpeedOptimized
• AlternateRoutability
• AreaMapLargeShiftRegToBRAM
• AreaMultThresholdDSP
• FewerCarryChains

для дебаг-итераций (чтобы попробовать тот или иной фикс в железе) имеет смысл отключать оптимизации по скорости/площади.

[Juzujka 0]

On 12/16/2018 at 3:43 PM, hdl_student said:

тут важна производительность на одно ядро, а не число ядер

Это ограничение Quartus Lite. Использует только одно ядро. Выдаёт предупреждение об этом каждый раз при запуске синтеза.

[Zoltrix 4]

Скорость компиляции в основном определяется производительностью процессора. Всем остальным железом в меньшей степени. Жаль ещё не додумались компилировать используя видеокарту, реально было поднять скорость в 10-20 раз.

[Grizzly 0]

5 часов назад, Zoltrix сказал:

используя видеокарту

Много задач в один поток исполняется.

[Zoltrix 4]

Если в 1 поток - то видеокарта тут не помощник.

[Kluwer 0]

Свою толику добавлю. 2-3 часа для серъёзного проекта для 5го "Стратикса" - это совсем не катастрофа. У нас был проект для 4го "Стратикса", к-рый по 6 часов собирался! Правда, было это уже почти 8 лет назад и компы тогда по-ленивей были.

А так, да:

1) более мощный комп (лучше нормальный, а не ноут: ноуты при перегреве часто понижают частоту проца никак об этом не сообщая), важнее число ядер, нежели частота. Мощную КУДовую видеокарту с поддержкой "openCL" тоже не помешает и ssd-диск; во время работы сборщика старатся ему не мешать: повырубать весь навесной софт, желательно даже отрубить сеть. Ну и уж точно на том же компе не стоит смотреть одновременно порнуху в HD-качестве :)

2) настройки проекта (ставить "нормальные усилия"; если не нужно по клокам "тапку в пол", то ставить оптимизацию "баланс" и т.д.);

3) таймквесты старатся использовать в максимально щадящем режиме. Не нужно, например, фильтру, работающему на 200МГц выставлять требования в 300МГц (знаю таких любителей: "а чё? В даташите сказано, что и на 450 должон работать!");

3) разбиение проекта (создать партишины, поставить всем "пост-фит" и т.д), иногда осмысленен "лоджик-лок" (хотя и не люблю этот инструмент-костыль); также часто имеет смысл

4) кодчекинг. Если есть процессор в системе, или на борту плисины, то всё что можно - пихать в него. Во всяких мегафункциях давать сборщику по-меньше самодеятельности (минимум опций в положении "авто"). Если DSP-мегафункции сразу включать "распихивать по DSP-блокам". Не лениться проверять весь код на наличие всяких глупостей, типа немерянных коммутаторов и прочего мусора.

[Flip-fl0p 4]

Цитата

важнее число ядер, нежели частота.

Хм... А точно ли так ? При сборке проекта я смотрел на загрузку ядер, там почти никогда нет нагрузки на все ядра. Максимум 1-2 ядра нагружены.

[krux 8]

меньшее время сборки дизайна как правило дают более правильные (и более точные) констрейнты.

к примеру проект для ep4sgx230 до моего вмешательства собирвался от 3 до 4 часов, при это возможны были вылеты с непредсказуемой вероятностью. после переписывания констрейнтов сборка стала осуществляться за 40...50 минут с предсказуемо успешным результатом сборки.

[Doka 1]

krux

можете уточнить в чём конкретно состояло вмешательство?

констрейнтов много и все они разные.......

[Alex77 4]

В 14.01.2019 в 13:23, Kluwer сказал:

 

1) более мощный комп (лучше нормальный, а не ноут: ноуты при перегреве часто понижают частоту проца никак об этом не сообщая), важнее число ядер, нежели частота. Мощную КУДовую видеокарту с поддержкой "openCL" тоже не помешает и ssd-диск; во время работы сборщика старатся ему не мешать: повырубать весь навесной софт, желательно даже отрубить сеть. Ну и уж точно на том же компе не стоит смотреть одновременно порнуху в HD-качестве :)

С каких таких бухты барахты потребовалось "Мощную КУДовую видеокарту с поддержкой "openCL" ? Ни как для попутного майнинга ? и ядер надо побольше что до кучи HD смотреть, чтоб не скучно было...

Изменено 15 января, 2019 пользователем Alex77

[krux 8]

9 hours ago, Doka said:

krux

можете уточнить в чём конкретно состояло вмешательство?

констрейнтов много и все они разные.......

В данном случае - более точные описания что происходит при пересечении клоковых доменов.

либо связи нет (не было описано) вообще где должно быть false-path.

либо идёт multicycle с конкретными количествами тактовых с каждой из сторон. (но не описано)

либо описания не было вообще и ~20000 цепей анализировались по всем возможным launch-hold во всем проекте.

[RobFPGA 27]

Приветствую!

Вот мое IMHO ускорения по степени важности  

1. Грамотный дизайн! 

2. Грамотный дизайн! 

3. Грамотный дизайн! 

4. Аккуратные timing constraint -  требуемый минимум по частоте,  group asynchronous если нет зависимостей по тактовой,  false-path там где времена не важны, multi_cycle/max_delay там где можно|нужно.  

5. Ранний анализ узких мест, тестовые P&R отдельных модулей.

6. Аrea constraint для фиксации частей дизайна на кристалле,  partitions.

7. Комп с избытком памяти и оптимизацией по скорости подсистемы память - проц (но не в ущерб надежности)

8. Само собой - CPU >=4 ядра, ssd

10 Все остальные плюшки (3 монитора,  кресло с массажем, кофе-машина, симпатичная офис менеджер с печенками, ...  )

Удачи! Rob.

[krux 8]

RobFPGA