[Sulim4n 0]

Добрый день уважаемые форумовчане.

 

Появилась материальная возможность приобрести новый компьютер для сборки ПЛИС.

 

Бюджет до 300 т.р. (более обсуждается)

 

В основном собираю Спартаны 6 (xc6slx150) и Артиксы (xc7a200t). В проектах кристаллы заполнены на 80-90 %, времени на синтез и сборку уходит порядка 1-4 часов. Хотелось бы, по возможности, сократить это время.

 

Хотел узнать ваши комментарии по поводу выбора нового железа. Особенно, есть ли смысл брать процессор с большим кэшом.

 

Если кто недавно обновлялся можете скинуть конфигурацию станции.

 

Сейчас используется 2 компа (i7-940, 16 Gb DDR3 и i-7 3820 32Gb DDR3) время сборки проекта примерно одно и тоже. Собираю либо ISE 14.6, либо Synplify 2014 + Vivado 2016.1. Использую параметры maxThreads, incrimental compile и т.п.

 

 

[Maverick_ 15]

Добрый день уважаемые форумовчане.

 

Появилась материальная возможность приобрести новый компьютер для сборки ПЛИС.

 

Бюджет до 300 т.р. (более обсуждается)

 

В основном собираю Спартаны 6 (xc6slx150) и Артиксы (xc7a200t). В проектах кристаллы заполнены на 80-90 %, времени на синтез и сборку уходит порядка 1-4 часов. Хотелось бы, по возможности, сократить это время.

 

Хотел узнать ваши комментарии по поводу выбора нового железа. Особенно, есть ли смысл брать процессор с большим кэшом.

 

Если кто недавно обновлялся можете скинуть конфигурацию станции.

 

Сейчас используется 2 компа (i7-940, 16 Gb DDR3 и i-7 3820 32Gb DDR3) время сборки проекта примерно одно и тоже. Собираю либо ISE 14.6, либо Synplify 2014 + Vivado 2016.1. Использую параметры maxThreads, incrimental compile и т.п.

рекомендую предусмотреть возможность увеличения оперативки хотя бы до 128 Gb и более (с расчетом на будущее) и изначально брать минимум с 64Gb.

Тактовая частота процессора желательна 3ГГц и выше - i7 или i5. Оперативная память на DDR4

[Alex77 4]

Добрый день уважаемые форумовчане.

 

Появилась материальная возможность приобрести новый компьютер для сборки ПЛИС.

 

Бюджет до 300 т.р. (более обсуждается)

 

В основном собираю Спартаны 6 (xc6slx150) и Артиксы (xc7a200t). В проектах кристаллы заполнены на 80-90 %, времени на синтез и сборку уходит порядка 1-4 часов. Хотелось бы, по возможности, сократить это время.

 

Хотел узнать ваши комментарии по поводу выбора нового железа. Особенно, есть ли смысл брать процессор с большим кэшом.

 

Если кто недавно обновлялся можете скинуть конфигурацию станции.

 

Сейчас используется 2 компа (i7-940, 16 Gb DDR3 и i-7 3820 32Gb DDR3) время сборки проекта примерно одно и тоже. Собираю либо ISE 14.6, либо Synplify 2014 + Vivado 2016.1. Использую параметры maxThreads, incrimental compile и т.п.

не однократно обсуждалось.

1 частота процессора и озу

2 объем озу (рекомендуемые типовые объёмы указаны на сайте xilinx)

и обязательно мышъ без хвоста. ;)

пс кеш помогает когда программа и данные помещаются полностью.

программа может и поместится а вот данные вряд ли.

[Sulim4n 0]

Maverick, спасибо за совет, но я думаю 64 или 128 Гб можно использовать только если сразу запускать сборку 6-12 проектов на одном компе. Я не видел что бы Vivado использовал больше 5 Гб на проект. Если это можно как-то настроить прошу поделиться информацией.

 

Alex77, я просмотрел существующие темы на форуме, но не нашел ответов на все вопросы. Xilinx рекомендуют для сборки Артиксов 3.5 Гб RAM, т.е конфигурации имеющихся компьютеров должно хватать с головой. При покупке новой станции хочется получить прирост скорости сборки по сравнению с имеющимися.

 

насколько я понял нет смысла смотреть в сторону 10-12 ядерных Xeon'ов, т.к. они проигрываю по максимальной частоте i5, i7. SSD тоже не ускорит сборку.

[_4afc_ 24]

IMHO кроме частоты проца ничего не влияет, поэтому взял бы i7-6700K на 4ГГц или что попроще разогнанное до 5ГГц.

SSD не влияло, если на нём был ISE и проект, возможно надо систему тоже на SSD для прироста...

Вообщем ситуация беспросветная. Собираю простенькие проекты для спартана 6.

 

[Beby 0]

Как было отмечено ранее, основное влияние (не менее 80%) оказывает частота процессора. Для Intel процессоров в большей степени необходимо учитывать нормальную максимальную частоту, нежели Turbo boost, т.к. по ряду причин CPU не может долго находиться в Turbo boost режиме.

 

На сегодняшний день, как отметил _4afc_, лучшим вариантом будет i7-6700K с 4 ГГц номинальной частоты и TDP 91W, в Turbo boost режиме получим 4.2 ГГц и более TDP 100W. Необходимо будет озаботиться и очень хорошей системой охлаждения такой системы, т.к. охлаждать надо будет не только CPU, но и расположенные вокруг него компоненты, в особенности систему питания и модули памяти. От адекватной работы системы охлаждения будет зависеть продолжительность работы системы на большой частоте, в противном случае система будет впадать в локальные кратковременные параличи. В нормальных материнских платах (которые смогут питать i7-6700K) запрос на «паралич» может посылать не только перегревшийся процессор, но и другие компоненты системы, например система питания.

 

Подробные характеристики i7-6700K см. тут

 

Касательно памяти и Intel CPU:

Сейчас 128 Гб ОЗУ можно вкрячить только к Xeon или Core Extream (тот же Xeon) процессорам.

Последние desktop Skylake потянут только 64 Гб.

 

Чтобы система не перегревалась и не деградировала необходимо брать ОЗУ только с номинальным напряжением питания (для DDR4 это 1.2В), в тоже время брать тормозную память тоже не хорошо. Официально i7-6700K поддерживает из DDR4 только 1866/2133.

 

Xeon и Core Extream можно брать только если есть необходимость одновременной компиляции нескольких проектов на одной машине, в противном случае никакого выигрыша не будет.

 

Также желательно разгрузить контроллер памяти, встроенный в процессор, от "левых" задач; например не использовать встроенную в Core i-3/5/7 видеокарту.

 

Возможно, при компиляции ISE'ом одного проекта будет некоторый прирост, если отключить Hyper Threading.

[Flood 12]

насколько я понял нет смысла смотреть в сторону 10-12 ядерных Xeon'ов, т.к. они проигрываю по максимальной частоте i5, i7. SSD тоже не ускорит сборку.

Никакого, главное - частота одного ядра. Хотя в Vivado ситуация несколько лучше, все равно стоит отдать приоритет частоте. i7-6700K на сегодня действительно оптимален, хотя вот-вот должен появиться i7-7700k.

Памяти - для начала хватит и 16ГБ, 32ГБ - уже с излишком.

SSD - очень и очень рекомендуется. Время компиляции он не уменьшит, но спасет нервы при старте компьютера, запуске ПО, копировании и архивировании проектов.

 

Компьютер после сборки стоит тщательно протестировать при помощи prime95 (стресс-тестом CPU + lots of RAM). У меня машина на основе i7-6700K + DDR4 валилась в prime95, пока я не заменил память. При этом мемтестом ничего поймать не удалось. Т.к. памяти используется много, а ECC отсутствует, можно было бы нарваться на неизвестных масштабов проблемы.

[Beby 0]

Памяти - для начала хватит и 16ГБ, 32ГБ - уже с излишком.

Для малых ПЛИС это верно, но если кто-либо планирует двигаться в сторону UltraScale или UltraScale+, 16 ГБ может вдруг стать недостаточно - проверено.

Однако, если не надо работать с монстровидными ПЛИС, то лучше использовать 16 ГБ хорошей памяти, т.к. её гораздо проще найти, чем 32 ГБ.

 

SSD - очень и очень рекомендуется. Время компиляции он не уменьшит, но спасет нервы при старте компьютера, запуске ПО, копировании и архивировании проектов.

Да SSD штука быстрая... но не всегда надёжная.

 

Если вопрос стоит в скорости работы Windows с NTFS разделами, то можно немного поколдовать на новой машине и проблем будет значительно меньше. Основной проблемой NTFS является MFT, хранящая служебную информацию о файлах. Чтобы Windows нормально работал, необходимо, чтобы MFT системного раздела был минимальный, следовательно, необходимо чтобы на этом разделе было как можно меньше файлов и директорий. Поэтому ставить монстровидные среды на системный раздал HDD (и SDD тоже) крайне черевато для нормальной работы Windows. Посему рекомендую для гадких программ завести отдельный(е) раздел(ы) диска(ов).

Для HDD не забыть проводить дефрагментацию этих отдельных разделов хорошими дефрагментаторами. Также крайне полезно периодически проводить сжатие MFT, в особенности после удаления файлов.

[LeFou_Treize 0]

MFT системного раздела был минимальный, следовательно, необходимо чтобы на этом разделе было как можно меньше файлов и директорий. Поэтому ставить монстровидные среды на системный раздал HDD (и SDD тоже) крайне черевато для нормальной работы Windows. Посему рекомендую для гадких программ завести отдельный(е) раздел(ы) диска(ов).

Для HDD не забыть проводить дефрагментацию этих отдельных разделов хорошими дефрагментаторами. Также крайне полезно периодически проводить сжатие MFT, в особенности после удаления файлов.

 

У вас есть ссылки на какие-нибудь исследования на эту тему, результаты тестов? Типа,

 

1 ставим с нуля винду, накатываем среду,

2 компилируем N раз проекты типа такого-то, создаем и удаляем К миллионов файлов -- нагружаем систему, иными словами,

3 смотрим деградацию полезной работы от запуска к запуску,

4 делаем дефрагментацию,

5 повторяем тестовые проекты, наблюдаем возврат производительности,

6 проводим такой цикл несколько раз, делаем вывод, что эффект стабилен.

 

Или это частные внесистемные наблюдения?

Изменено 7 сентября, 2016 пользователем LeFou_Treize

[Flood 12]

Для малых ПЛИС это верно, но если кто-либо планирует двигаться в сторону UltraScale или UltraScale+, 16 ГБ может вдруг стать недостаточно - проверено.

Однако, если не надо работать с монстровидными ПЛИС, то лучше использовать 16 ГБ хорошей памяти, т.к. её гораздо проще найти, чем 32 ГБ.

 

 

Да SSD штука быстрая... но не всегда надёжная.

 

Насчет памяти - в любом случае стоит брать модули не объемом не менее 8ГБ или 16ГБ, чтобы в случае необходимости можно было просто добить память до нужного объема.

Насчет SSD - не нужно колдовать с MFT и бить в бубен верхнего мира. Нужно просто ставить SSD и ни о чем не думать, кроме бэкапов. Абсолютно надежных накопителей не существует, а надежность SSD vs HDD - вопрос очень и очень спорный.

[Grizzly 0]

Насчет памяти - в любом случае стоит брать модули не объемом не менее 8ГБ или 16ГБ, чтобы в случае необходимости можно было просто добить память до нужного объема.

 

С "добиванием" до 4-х планок нужно быть весьма осторожным. У коллеги при 4-х планках мемтест раз в несколько часов обнаруживал ошибку, память была без ECC. На двух планках всё стабильно.

[Beby 0]

У вас есть ссылки на какие-нибудь исследования на эту тему, результаты тестов? Типа,

 

1 ставим с нуля винду, накатываем среду,

2 компилируем N раз проекты типа такого-то, создаем и удаляем К миллионов файлов -- нагружаем систему, иными словами,

3 смотрим деградацию полезной работы от запуска к запуску,

4 делаем дефрагментацию,

5 повторяем тестовые проекты, наблюдаем возврат производительности,

6 проводим такой цикл несколько раз, делаем вывод, что эффект стабилен.

 

Или это частные внесистемные наблюдения?

Это результаты моих "частных", но "системных" наблюдении, проводимых непрерывно на протяжении более 15 лет, на десятках разных машин, с заметно разными CAD'ами, от Windows 2000 до Windows 7. Большой статистики (3 года и более на более чем 30 машинах) для Win 8.1 и 10 у меня пока нет, но т.к. NTFS в плане MFT / утилит по обслуживанию MFT не улучшался, то надежд на заметное улучшение ситуации - нет, правда есть небольшие улучшения за счёт большего объёма памяти выделяемой под дисковый кэш.

Естественно есть ещё и наблюдения по разным FAT’ам, накопленные за более чем 20 лет, но, подозреваю, что они мало кому интересны.

 

Наверняка, кто-нибудь тоже проводил подобные наблюдения/исследования - но я пока не натыкался на их результаты.

Особо интересующиеся проблемами NTFS(MFT) могут ознакомиться с историей появления exFAT - может она наведёт на какие-то мысли... В принципе exFAT значительно проще (быстрее) NTFS, но это достоинство в значительной степени убивается драйверами Win-XP/7 (про Win 8.1 и 10 опять-таки умолчу, из-за временного отсутствия достаточной статистики).

 

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

 

Насчет SSD - не нужно колдовать с MFT и бить в бубен верхнего мира. Нужно просто ставить SSD и ни о чем не думать, кроме бэкапов. Абсолютно надежных накопителей не существует, а надежность SSD vs HDD - вопрос очень и очень спорный.

Таки соглашусь, SSD очень хорошо скрадывает проблемы NTFS. Соответственно, при использовании SSD можно и не колдовать над дисками. А без backup'ов стрёмно как на SSD, так и на HDD,.. но на SSD всё же по стремнее будет: были уже с ними проблемы.

 

Вопрос колдовать или не париться в большей степени стоит в денежной плоскости: цена денег в Москве и за 150-200км (не говоря уж про 1000км) от Москвы - существенно разная, поэтому работодатели существенно по разному смотрят на затраты на технику. И если могучие CPU/DDR достаточно легко обосновываются, то с остальными комплектующими бывают и накладки.

 

С "добиванием" до 4-х планок нужно быть весьма осторожным. У коллеги при 4-х планках мемтест раз в несколько часов обнаруживал ошибку, память была без ECC. На двух планках всё стабильно.

Есть такая проблема, замечал, что на ряде материнских плат (в т.ч. дорогих ASUS), при установке 4 модулей памяти, BIOS сам (тихонечко) приподымал питания памяти на 0.05В, а VTT, соответственно, на 0025В. И если его принудительно сводить к «норме» (т.е. значениям прописанным в SPD) начинались глюки.

[Tpeck 0]

Для HDD не забыть проводить дефрагментацию этих отдельных разделов хорошими дефрагментаторами.

А пример хорошего дефрагментатора можно в студию?

[Beby 0]

А пример хорошего дефрагментатора можно в студию?

Пока мне больше подходят NU 15, но есть и другие варианты - главное моё требование способность собрать дирректории, MFT и прочие служебные записи покучнее - чтобы всё это легче входило в кеш HDD/ОС. Отмечу однако, что NU 15 под разными ОС ведёт себя заметно по разному, и далеко не всегда дает адекватный результат (например, под Win7 по какой-то причине не определяется редко используемое файло, которое было бы неплохо свалить в конец раздела, а вот под XP такой проблемы нет...)

 

Можно и с O&O повозиться - порой тоже даёт не плохой результат, но почему-то часто стремится размазать директории по всему диску (поближе к файлам в них описанных), возможно, в новых версиях это исправили, или сделали возможным перенастроить.

 

Но повторюсь, дефрагментация - вторична, первично - состояние служебной информации (в т.ч. MFT).

 

P.S. Если кто порекомендует навороченный дефрагментатор, с функционалом, приближающимся к NU SpeedDisk 2002 (прекрасно работавший в Win98/Me с FAT'ами), то буду благодарен.

 

P.P.S. Для сжатия MFT пользую Paragon Partition Manager 12, за более чем 3 летний срок эксплуатации проблем не было ни разу.

[RobFPGA 27]

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

 

Все эти пляски с разгоном и "оптимизацией" MFT дадут ~10-20% скорости в лучшем (и не каждом) случае.

Поэтому у меня к компу основные критерий в плане приоритетов: надежность, память, частота CPU.

Вопрос о надежности SSD давно уже не актуален - сейчас это стандартное решение для компов >= среднего уровня;

 

Существенное ускорение сборки проекта (в разы!) дает правильная организация проекта и грамотное применение constains.

 

Удачи! Роб.