Если Вы писали вообще про схематик, то это уже избитая тема...

А вот если про схематик КА (что менее вероятно), то я думаю уже многие согласились, что в графическом описании КА больше преимуществ, чем недостатков.

Мое ИМХО я бы вообще всё писал на Verilog'e (комментить проще) + если проект большой - разделение на "глобальные" функциональными блоки. Но получается удобней (и продуктивней!) КА оформлять в графике.

Ну еслиб я мог написать "Уважаемый верилог поставь триггер", и он бы ставил, я б согласился
Как сказал уважаемый druzhin, выигрыш HDL состоит в том, что можно не отвлекать на то, как реализовывать на основе примитивов. Набросал поведение, а синтезатор сам пусть думает, как это воплотить в жизнь. Здесь и всатет вопрос, а то ли он делает, что имелось в виду.

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

Я имел в виду, всегда ли синтезаторы адекватно синтезируют HDL описание. А то может так ссинтезируют, что после разводки шедевра по кристаллу схема не будет работать и на 30 МГц, хотя планировалось 50.


Или затратят слишком много ресурсов.

Я примерно так и делаю :"Уважаемый вхдл поставь триггер" и он появляется.


Синтезаторы синтезируют на столько корректно, на сколько корректно описана схема.

Шутка: можно сходить к хирургу и выпрямить руки, тогда и rtl, прямой будет(всерьез не воспринимать)

От синтезатора мало что зависит. Все упирается в человека.

Если вы в квартусе(схема) поставите триггер на вход D подадите '1', на clk тактовую, а выход q податите на выход, то квартус просто посадит q на '1'.

Прям одной строчкой? Прям по русски? Фантастика!!!
Я не говорю о коде, который написан неправильно. Я говорю о коде, который синтезиться в принципе правильно, но при этом либо схема занимает слишком много ресурсов, либо с максимальной тактовой частотой проблемы.

В данной теме выше приводился пример того как синтезатор ISE при разводке схемы на кристале затратил на 20% больше ресурсов, чем синтезатор Sinplify. То есть синтезаторы все-таки делают какие-то ошибки, не оптимально что-то синтезируют. Вот я о чем говорю.

Очень интересно, а чем это отличается от рисования схем ? то, что вы попросили от синтезатора, то он и собрал, так как вы указали. И проблема максимальной тактовой это проблема в первую очередь разработчика, т.к. синтезировался его код.
Согласитесь что ждать от
pipa(31 downto 0) <= pipaA(31 downto 0) when (signed(pipaA) < signed(pipaB)) else pipab(31 downto 0);
500 МГЦ на virtex4 это просто смещно и виноват в этом не синтезатор, а человек, который вот это написал.


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

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

Уж ответили. Но я повторю - какой rtl, такой и результат.

Схема - структурное описание алгоритма.
RTL - описание алгоритма на уровне регистровых передач.
Разница - в подходе.

счастливые вы ребята

[quote name='druzhin' date='May 30 2006, 16:47' post='118516']
[/quote]Вы вообще-то делали БОЛЬШИЕ проекты? [/quote]

А Вы вообще-то топик читали? Какой схематик??
Я посмотрю на большой проект, который по объему наполовину будет состоять из объявлений instance-ов с десятками разных параметров ( - а если к проекту нужно вернуться через год?). В HDL Designer-е я даже ни разу не написал слово module, пишу только полезный КОД.

Фраза "Уважаемый верилог поставь триггер" переводится на Верилог следующим образом:

reg trigger;
always @(posedge clk) trigger <= ...;

Но я на другом хотел заострить внимание. При проектировании логики на HDL нужно уйти от понятий "триггер", "счетчик (простой, реверсивный, по модулю эн и т.д.)", "сдвиговый регистр" и т.д. Цель проектирования - получить работоспособный результат. И при вводе описания мне нужен-то (и всегда был нужен), скажем, не счетчик, как таковой, а некое устройство, которое будет выполнять функцию счета. Во времена рассыпухи таких устройств универсальных не было и делали это на триггерах, потом появилсь ИМС счетчиков, из которых лепили более сложные счетчики. Потом возникли ПЛИСы, где появилась возможность исползовать параметризованные блоки - например, lpm_counter, и казалось, что вот это и есть то, что надо - универсальный счетчик на все случаи жизни подходит, другого нечего и желать. И сам факт, что нужен-то не счетчик, а функция счета, как-то остался в стороне. А между тем, именно HDL'ные конструкции и дают возможность описывать именно функциональность. Например, мне нужно подсчитывать что-то, пишу (упрощено, почти псевдокод ):



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

Когда работал еще с AHDL'ем, использовал в полный рост библиотеку LPM, казалось, клевая вещь. Пересевши на Verilog, тоже пытался по привычке использовать LPM, испытал большое неудобство в использовании - все-таки способ инстанцирования объектов в AHDL, имхо, на порядок удобнее и читабельнее, чем в Верилоге. Но скоро понял, что занимаюсь ерундой, что нет никакой необходимости в этих модулях. В итоге, в проектах нет ни одного LPM модуля, в качестве готовых альтеровских модулей использую только блоки памяти, ФАПЧ и умножители - то, что является специализированными аппаратными устройствами ПЛИС.

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

Навеяло воспоминания Я также подпишусь под каждым словом этого абзаца

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

солидарен с dxp.

Все, кроме pll, можно без проблемм реализовать на языке. У altera целый раздел посвящен этому в "настольной книге".

хочу уточнить: что синтезаторы уже стали понимать поведенческое описания блоков памяти??? (для Altera?)

Или просто забыли дописать в посте "Все, кроме pll, блоков памяти и специализированых блоков ПЛИС" как у dxp

Это да, только вот эксперименты с той же памятью не принесли (мне) удовлетворения. Для того, чтобы синтезатор (Синплифай) правильно инферил память, надо соблюдать ряд требований. Например, оно хотело (версия 7.5 или 7.6, что-ли, в общем, какая-то из этих, с более новыми не проверял), чтобы выход памяти обязательно пропущен через регистр - это в доке было описано. Но ведь не всегда это надо, иногда достаточно взять просто с выхода памяти. Короче, по предсказуемости и устойчивости результата использование блока, сгенеренного в мегавизарде, оказалось лучше.

С умножителем похожая история вышла. Пока использовались умножения на константу, синтезатор генерил прекрасный код. Но при попытке использовать полноценный (переменную на переменную) умножитель, синтезатор нагенерил кучу предупреждение о том, что, дескать, такой-то регистр с офигенно длинным и запутанным именем - это он сам все это сгенерил, нечеловеческое название было, pruned because его выход не используется. Спрашивается, зачем об этом вопить? Сам сгенерил, сам удалил, малацца, хороший мальчик, возьми с полки конфетку, зачем об этом сообщать? И таких предупреждений оно выдало несколько сотен - умножитель-то немаленькая штучка. Потыкался, потыкался, не понял, что ему надо, сгенерил блок lpm_mult и удовлетворился.

В общем, нет никаких принципиальных противопоказаний к хорошей генерации и памяти, и умножителей, но на тот момент реализация мне не понравилась. Возможно, в будущем ситуация улучшится. М.б. она уже улучшилась в том же Синплифае 8.5, пока не проверял.


Понимать-то уже давно понимают. И даже иногда генерят то, что нужно. Но только для этого надо ряд условий соблюдать. В доке на синтезатор это, как правило, описано.