Перспективы синтеза С++ в ПЛИС (иногда надо же сабж менять !)

Tue, 22 Nov 2005 03:16:44 +0300 Michael Tulupov wrote to Harry Zhurov:

MT>>> То есть мы будем описывать не Hardware, как сейчас, а алгоритм.

HZ>> А ты и сейчас не хардвару рисуешь, а задаешь описание поведенчески - HZ>> пишешь процесс, который по событию производит какие-то действия. А HZ>> конкретное железо уже после синтезатор рожает. MT> Всё-таки сейчас я по HDL коду почти всегда могу сказать, как этот MT> конкретный кусок кода будет выглядеть в железе. MT> Или по крайней мере перечислить реально возможные варианты.

Так это и есть хорошо! Если ты не можешь сказать, во что выльется то или иное описание после реализации его в железе некой тулзой, то полезность оной тулзы устремляется к нулю.

HZ>> Если проводить параллель с программированием, то это звучало бы так: HZ>> пишешь в тексте программы, дескать, отфильтровать сигнал в HZ>> полосе F, с неравномерностью D, шириной переходной полосы f и т.д. И HZ>> пусть компилятор родит соответствующий код. :) MT> А в чём проблема ? Matlab/Simulink в зубы :-) Будет тебе из него сишный MT> код.Как раз на таком высоком уровне проблем нет. MT> В схематике соединяем готовые библиотечные блоки. В данном случае берём MT> библиотечный фильтр.

Ага, а когда ты этот сишный текст подсунешь компилятору из VDSP или CCS, то скорость работы этого фильтра тебе вряд ли понравится. Полезность Симулинка с его приблудой для синтеза цифровых фильтров ограничивается возможностью генерации коэффициентов фильтра для выбранного типа и характеристик. Реализацию на DSP приходится (и это правильно) писать руками и на ассемблере. Конечно, существуют случаи, когда быстродействия хватает с запасом в два порядка, можно себе позволить не тратить время на возню с асмом. Только это не наш случай. :)

MT> Hо касательно железа я имел в виду всё-таки не совсем то. MT> Хочется уровень выше голой цифры в виде сумматоров, шин и триггеров, MT> но шире и универсальнее, чем библиотека готовых блоков. MT> SystemC (синтезируемая часть) сейчас на уровне голой цифры.

Все это есть. На бесконечных ресурсах все это будет прекрасно работать. Но вот в реальности, как ты знаешь, такого не бывает, ресурсы ограничены. Всегда есть куда потратить излишек - или на дополнительные возможности, или на уменьшение цены и проч.

MT> Мне же хотелось бы автоматического перевода _последовательного_ MT> (программного) алгоритма в _параллельный_ (аппаратный).

Описание на SystemC отнюдь не такое последовательное, как в простой программе. Вернее оно - да, последовательное, но не в бОльшей мере, чем последовательность операторов в VHDL'ном процессе или Verilog'ом блоке. По сути до некоторой степени описание на SystemC можно представить как программу, работающую под управлением ОС - есть параллельно выполняемые процессы, есть средства синхронизации между процессами. На компе, кстати, оно так и работает - ядро SystemC как раз берет на себе функции по организации параллельности, а процессы - это треды ОС. И синхронизация производится с помощью вещей типа WaitEvent, NotifyEvent (за точность названий не ручаюсь, давно уже смотрел все это) и подобных.

MT> И мнится мне, что в принципе это возможно. MT> AFAIK любой современный компилятор уже имеет средства MT> например для разворачивания цикла for (если цикл удовлетворяет MT> определённым требованиям) в параллельную конструкцию, MT> эффективно выполняемую с помощью SIMD блоков процессора MT> (MMX,SSE или там AltiVec).

MT> Вот и хотелось бы продолжить и углубить сей момент. MT> Чтоб к примеру тот же for, написанный в программе, MT> развернулся прямо в некий SIMD блок в ПЛИС :-)

Это все есть. И давно. И на существующих HDL. Вот в этом же треде я приводил фрагмент кода (который Квартус отказался компилять, а Синплифай на ура) - арбитр контроллера памяти. Там как раз все описано в виде цикла. А в ПЛИСе оно реализовано в виде схемы, которая реализует описанную функциональность аппаратно. За один такт системного клока. И все такие вещи ессно есть и в SystemC, и в HandelC. Тут никакой революции нету.

MT> При арифметических операциях ставим или MT> аппаратный блок (сумматор/умножитель/etc), MT> или, если операций много, но занимают они мало места MT> в программе, несколько библиотечных АЛУ с блоками MT> управления.

Арифметика прекрасно синтезируется. Практически любым современным синтезатором.

MT> При вызове a=fft(b) просто ставим готовый аппаратный MT> блок БПФ из некой стандартной библиотеки, автоматически MT> настраивая его параметры по типам и кол-ву аргументов и MT> результатов (типа Xilinx CoreGenerator, но в пакетном MT> режиме).

Хе. А вот тут уже вопросы начинаются. Вот этот вызов - он что, за один такт должен выполняться? Или за сколько? Можно и за такт, если этот так порядка миллисекунд. Только вряд ли это кого-то устроит. Как тут быть? Ведь надо же взаимоувязать его работу с другими частями устройства. И по потреблению ресурсов, и по быстродействию. Т.е. опять надо руками и головой тут поработать.

MT> При обьявлении в программе массива ставим модули памяти MT> нужной глубины и разрядности.

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

MT> В зависимости от числа операторов программы, лазающих MT> по этому массиву, делаем её много- или однопортовой. MT> Или ставим несколько банков. Если памяти надо очень MT> много, спрашиваем юзера, а не подключить ли внешнюю MT> SDRAM.

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

MT> Hу и так далее. Я ещё много могу придумать. MT> Как вширь (автоматически перерабатывать в железо MT> разные операторы и типовые алгоритмы), так и вглубь MT> (как эти аппаратные блоки автоматически потом увязать MT> вместе).

MT> Тем более что неоднократно приходилось по имеющимуся MT> алгоритму в виде программы на С делать железо. MT> И закономерности в этом процессе есть.

MT> Правда, основная такова - при наличии рядом товарища, MT> писавшего программу и знающего предметную область, MT> дело значительно упрощается :-).

Это понятно, что можешь придумать. Достаточно. Как видишь, во всех случаях на автомате оно не получится. И то, что имеется рост ресурсов кремния при той же цене не сильно меняет дело - ресурсы растут, но и задачи тоже растут.

Основная тенденция к упрощению использования и умощнению инструментария - это перекладывание на "железные" плечи компилятора большой по объему рутинной работы и поддержка компилятором специальных средств для декомпозиции большой задачи - разбивку ее на ряд более мелких и, как следствие, простых. Вот эти-то вещи и дает SystemC по сравнению с существующими HDL. Именно эти, а не пресловутую возможность посадить любого программера за хардверный дизайн. А то, что ты описывал - это вообще проектирование и алгоритмический синтез, это области, где ЭВМ с человеком соревноваться не может. Во всяком случае пока.

MT> А если в С++ ещё добавить некие средства явного MT> параллелизма - вообще будет замечательно. MT> Тем более что такие расширения для Си вроде есть. MT> Вот и юзать их в синтезе.

Так SystemC как раз их и включает. SystemC - С++ со специальной библиотекой, включающей кроме прочего, ядро, поддерживающее параллельное выполнение процессов, и методология использования этого хозяйства.

HZ>> Это задача глубокого (для ЭВМ) алгоритмического синтеза, HZ>> с такими задачами пока что человек справляется HZ>> несоизмеримо лучше. MT> Тем не менее сишные компиляторы уже научились MT> делать распараллеливание. Хорошо ли, плохо ли - MT> но прогресс налицо.

Это все низкоуровневые оптимизации. Это задача сама по себе значительно более простая, нежели проектирование. И даже тут им еще есть над чем поработать.

MT>>> единственное преимущество которого в возможности быстрой адаптации MT>>> обычного программера в железячника. HZ>> Тоже нет. Для того, чтобы чел мог эффективно работать, ему придется HZ>> разобраться в потрохах. MT> Вот и я о чём. В системСи смысл на данный момент - моделирование.

Основной - да, - моделирование сложных систем. А синтезом - подождем приличных синтезаторов. Там видно будет, стОит ли овчинка выделки.

HZ>> Реальное же преимущество SystemC в том, что на нем проще описывать HZ>> _сложные_ устройства. MT> _Модели_ сложных устройств - но не _реальные_ устройства. MT> Hо тут его поджимают MATLAB/Simulink и SystemView.

А ты в них можешь моделировать свое VHDL описание? Кроме того, при моделировании в том же Матлабе возникают проблемы, к примеру, с моделированием поведения, скажем, fixed-point арифметики. Сам Матлаб это нативно не поддерживает, у него все в даблах, а егонный тублокс как-то мне не показался. Уж лучше это прямо на С++ и писать. И ловить переполнения и прочие эффекты.

MT> Вот я и не понимаю ниши, в которую предназначен SystemC сейчас. MT> Очень сложные системы имхо проще моделить в мышизме. MT> Синтезируемые вещи отлично пишутся на HDL.

Сегодня есть смысл на стыке синтезируемого и несинтезируемого сложного окружения.

MT> Уже есть некоторые средства перехода от мышизма прямо к HDL MT> (Xilinx System Generator и аналогичная штука у Альтеры).

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

MT> СистемСи имхо остаётся ууузенькая ниша между мышизмом MT> и HDL.

Не такая уж и узенькая. Тестбенчи можно свободно писать на SystemC, при этом нет необходимости во всяких PLI.

MT> Причём средств перехода к HDL пока толком нет.

Как это нет??!! Уже упомянутый DC. Есть и другие - от Celoxica. Я бы попробовал, да времени нету на это.

HZ>> Синплифай, к примеру, уже кое-что начал поддерживать. MT> С какой версии ?

Начиная с версий 8.хх. Пока там оно больше на уровне синтаксиса. Но процесс пошел, подождем.