Хао, други!

Осенило тут вопросом - а можно ли использовать для ускорения фиттинговых вычислений CUDA? Честно говоря, не очень понятно почему Альтера (на ее примере, т.к. работаю только с ней) к этому не пришла. Мне кажется, фиттеровские алгоритмы идеально лягут на куду... Или это уже как-то реализовано и я такой непросвященный?

Давайте порассуждаем на эту тему.

Помогу начать.

Вот смотрите. По сути, ПЛИС - это очень большая и сложная сетка (граф, но не Дракула ). Возьмем некий сферический фиттер в вакууме. По сути, его задача - отобразить синтезированную ранее логику на эту сетку таким образом, чтобы результат удовлетворял заданным ограничениям.

Я не знаю достоверно как работает фиттер - могу лишь сидеть и фантазировать, но думаю что трассировку этой сетки он выполняет не путем тупого перебора всех возможных ее комбинаций, и не пытается уложить в сетку сразу всю логику сразу, а делает все по-частям. И я так понимаю, все нынешние фиттеры делают это последовательно - сначала одну кучку логики, потом другую, потом еще одну и т.д., после чего уже работают на уровне этих разведенных "кучек".

Так вот - что мешает фиттеру укладывать одновременно несколько кучек? На тот же GPU это бы легло очень продуктивно, мне кажется... А там и до сетевого кластерного фиттера недалеко. Правда, сегодня фиттеры до сих пор не могут нормально использовать даже несколько ядер внутри обычного ЦП (лично у меня альтеровский фиттер Processors Usage не поднимал еще ни разу выше 1.2 - и это при наличии 4-х ядер.)

Если дизайн поделить на партиции - CPU usage будет нормальный. Но проблема в том, что трассировка больших дизайнов требует значительно больше памяти, чем есть в современных графических ускорителях. У меня при трассировке под Stratix IV - 230 уходило шесть гигов где-то, при этом затраты времени были около часа (на четырех ядрах), что вовсе не приводит к мысли пробовать задействовать CUDA.

Насколько мне известно, графическая память гораздо быстрее обычной. Соответственно, что мешало бы выгружать в GPU небольшие (относительно) партиции, компилировать их, а уже само "сведение" партиций делать на центральном процессоре ПК? Эдакий "конвеер партиций".

Для CUDA подходят далеко не все задачи.
Из wiki: Ideal GPGPU applications have large data sets, high parallelism, and minimal dependency between data elements.
Кроме того, там упоминается понятие Arithmetic intensity. Грубо говоря - количество арифметических операции приходящихся на одно обращение к памяти. Оно желательно должно быть высоким.

Если короче - он может выполнять очень много обработок одновременно, но они должны быть независимы.
Данных должно быть много, но обращений к памяти - мало.
И кроме того, насколько я себе представляю, в GPU не предусмотрено ветвления алгоритма. А сделать fitter без ветвления....

В моем представлении это как раз очень плохо соотносится с задачами fitter'а.

Нежелание юзеров выделять такие партиции и невозможность делать это автоматически.

Мне кажется, для определения партиции можно использовать сами модули. Модуль - партиция. Ну либо несколько модулей, вложенных в один (а часто так и бывает) - тоже, по сути, партиция.
Кстати, лично я не особо доверяю инкрементальной компиляции, т.к. она, бывает, глючит - компилятор иногда не может что-то с чем-то свести и все времянки либо логика летят к черту )) Такое уже не раз было. Помогает снос incremental_db.

Ага. Прощай трансграничная оптимизация - здравствуй лишний объем и снижение Fmax.

Я просто предположил Обычно же стыки крупных модулей делают такими, чтобы они (модули) были друг от друга максимально отвязаны (например, это два модуля, работающих в двух разных тактовых доменах). Отсюда и возникла такая мысль.

Да, но вы правильно тут говорите - стыки крупных модулей. А их в проекте обычно немного: у меня в UltraSPARC-системе количество партиций до десятка кажется не дотягивало. Но чтобы система хорошо на CUDA легла - их должны быть многие десятки.

Потому что алгоритмы как размещения так и трассировки плохо распараллеливаются даже на процессорах общего назначения, а на CUDA и того хуже. А основная проблема - зависимости между потоками.

Что-то мне кажется, что основная проблема в коде программ САПР, а не в вычислительной сложности алгоритмов. Например, у меня конфигурационный файл для Virtex-6 bitgen-ом формируется 20 минут. Размещение и трассировка здесь уже выполнены, куда ему на DRC столько времени?

Как спросили на одном семинаре у Xilinx-немцев - когда ISE станет нормально работать? Когда выйдет Rodin, ответили. И то сомнительно.

Дело не в сложности алгоритмов, а в самих алгоритмах. Итерационные алгоритмы, например, плохо распараллеливаются.

Так будет точнее. Но есть ощущение (см. bitgen), что ISE медленно работает просто из-за плохого качества программного кода. Дрябленько сделано, развесисто написано, без оптимизации.

одна фирма - оффициальный CUDA Nvidia консультант год назад и с Альтерой и с Ксилинксом и с Латтисом этот вопрос обсуждали - в портфолио кудовской фирмы - под двадцать лет работы на массивно-параллельных платформах. Вопрос обсуждался на уровне деректоров по развитию. Решили забить, так как игра не стоит свеч - те кому надо - купят побыстрее проц и SSD, а остальные подождут.

Куда уж быстрее: у нас штеуд I7-2600K ещё и разогнанный на 10% компилит Xilinx VLX240T порядка 1-1.5 часа.
Это с Planahead'om. Без него вообще ISE крутил яйцами неопределённо долгое время (рабочий день раньше заканчивался).
Разве что за жидким азотом в магазин сходить.

Уже обсуждалось тут что работа файловой подсистемы не является узким горлышком в данном случае. Да и распараллеливание более или менее осуществимо (хотя не думая что данная задача для CUDA). Вроде затык был с повторяемостью результатов имплементации.

А полтора часа - это что, много для такого чипа? Один баг нашли - поставили перекомпилить - ищем пока другие независимые баги. Я уж не говорю что при таких объемах можно разные куски дизайна уже разным инженерам раздавать.


А без него такие кирпичи IMHO вообще не стоит и пытаться делать.