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

В данной теме выше приводился пример того как синтезатор 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, пока не проверял.


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

Проверил(ram) возможные комбинации с регистровым и нерегистровым и пр. выходами/входами - хрумкает так , что за ушами трещит. Проблеммы могут возникнуть тогда, когда целевая архитектура не поддерживает чудо.(На пример в циклоне ram без регистра адреса/данных не получится).

А какой синтезатор? Какая ПЛИС?

Например, в том же Циклоне аппаратные блоки памяти, насколько знаю, имеют внутри себя входной регистр, его нельзя отключить. Поэтому нерегистровые входы при описании памяти тут не пройдут. Но это не вопрос, тут все понятно. Как уже сказал, оно (Синплифай каких-то 7.х версий) не хотел инферить блоковую память если она была описана без регистров на выходе. И это было четко документировано.

Synplify 8.5.1.
(Проверял на actel apa и altera cyclone)

Ок, отличная новость, в следующий раз обязательно попробую поюзать языковое описание - генерация модулей в мегавизарде, особенно, когда надо что-то подправить, честно говоря, достает. Спасибо.

я не был бы столь воодушевлен,
для хилых к сожалению симплифай не может:
корректно отображать DWC память,
пайплайнить на внутреннем тригере блоки ROM памяти (8.4 по крайней мере),
вставлять аппаратные фифо блоки (виртекс 4)
+ даже если описать память так:


все равно сибирается реально вот что



Что по сути и соответсвует модели блочной памяти хилых. при отключеном pipeline регистре,
поэтому те кто не знаком с этой фичей, потом откроет много удивительного

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

des00:
Это из разряда думаю одно, пишу другое .
Данная конструкция должна выглядить примерно так:


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

ЗЫ: Повторяюсь, что считаю наезды на синтезаторы необоснованными, они всего навсего выдают результат, который его просили сделать на основании данных, который у него имеются. А просить надо "учиться, учиться и еще раз учиться" С , не останавливаясь на достигнутом.

Больше всего в rtl на vhdl мне нравится возможность создания самоадаптирующихся модулей. Пример:

Код

entity myram is
    port(
    ...
    data    : std_logic_vector;
    ...
    );
...
type mem_type is array(...) of std_logic_vector(data'range);
...

Если подключить в прожект 3 таких модуля и на вход data подключять шины разной ширины, то подключится 3 разных блока памяти. Самое главное - ничего не надо делать для конфигурирования, оно само сконфигурируется. Слабо такое с lpm повторить без использования generate?

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

пр. ug070.pdf стр. 115 Figure 4-5: Block RAM Logic Diagram (One Port Shown)
более того если посмотреть на ds302.pdf стр. 33 Table 39: Block RAM Switching Characteristics
то можно прекрасно увидеть что Clock CLK to DOUT output (without output register) в 2.2 раза медленнее чем с пайплайн регистром, именно потому, что после защелкивания адреса в тригере, требуеться выборка данных в защелку, а в реальной схеме если на выходе памяти стоит например сумматор, то тактовая вообще проседает, кстати если не ошибаюсь у стратикса/стратикса2 те же самые проблемы, а именно отстутвие асинхронного чтения на блочной памяти.



Да все правильно, скажу даже более у меня получалось через генерики подключать pipeline регистры (работало только для RAM, для ROM игнорировалось) и инвертировать клоки, и даже синтезировать память описаную через переменные (чего нет в датшите на симплифай), но не получилось никак описать DWC память, несколько стробов записи собранных на 1 BRAM, также есть определенные проблемы повторяемости при реализации памяти в 9, 18, 36 бит (симлифай 7.х) и при мультипексировании потоков данных на памяти.

Я не утверждаю что этим нельзя пользоваться, но в ВХДЛ я решаю эти проблемы с помошью конфигураций (behavior/structure), так можно упростить симуляцию и не беспокоиться за синтез.

Стормозил. я имел в виду, что если нам нужен регистр на выходе или выходе, то его надо и описывать явно.



Может все же:

Иначе зыщелка получается.

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

Подозреваю что ваш сарказм вызван не внимательным прочтением постов, да и термин "нормально делать блочную память" у каждого свой, на досуге попробуйте заставить симплифай написать вот такую блочную память, БЕЗ использования CLB
2 порта:
1ый порт чения/записи 512х32 бита, 4 строба записи, по каждому на 8мь бит, выход через pipeline регистр, режим работы любой.
2ой порт чтения/записи 2048х8, выход через pipeline регистр, режим работы write_first.

2 vetal


ug070.pdf стр. 112

Read Operation
The read operation uses one clock edge. The read address is registered on the read port,
and the stored data is loaded into the output latches after the RAM access time.

тот же pdf стр. 115 Figure 4-5: Block RAM Logic Diagram (One Port Shown)

Из этого рисунка следует что адрес чтения/записи "хлопает" в регистре всегда, а операции чтения/записи определяеться сигналами we/ena что в моем коде заменено на we/re. И при чтении данные по стробу храняться в выходной защелке.

В своем примере я привел код, более близкий к реальному устройству bram памяти от хилых и указал, что в симплифае реально при сборке идет по-сути подмена первого кода, на второй. Но при этом нет никаких диагностических сообщений об этом (о расхождении желаемого и действительного) , кроме сообщения об обнаружении bram памяти.

Интересно зачем нужны одновременно Sinplify Pro + ISE ? Разве одного продукта недостаточно. Если вы используете оба, то как разделяете функции между ними.

В ActiveHDL понятно будет ввод и симуляция дизайна. А вот связка Sinplify Pro + ISE зачем нужна неясно.

не довелось пока работать с ISE , у меня Quartus ...

но тоже раньше задумывался об этом же - однако быстро понял, вот последний пример
http://electronix.ru/forum/index.php?showtopic=93048

где синтезис от Quartus работал , но одновременно делал проблемы...
Synplify Pro - четко дал понять где именно проблема и решилася она за 5 мин.
( а это только недобольшой хобби проект )

в итоге - многое от недостатков HDL/Verilog, вернее многих неоднозначностей которые могут получиться если их использовать
а других и лучших языков нет

вопросы еще более правильного и компактного синтеза - это я думаю еще бОлее широкая тема...

в Quartusе - переход на Synplify очень прозрачен - один чек бокс и выбор EDIF/VQM

XST не поддерживает SystemVerilog, и более корявый и глючный. Интеграция Sinplify в ISE стандартно предусмотрена, и делается элементарно.

Скрестим шпаги, мистер?
В чем корявость и глючночть?
Или Вы достигли такого уровня, что Вам не хватает синтезатора в ISE
и без некоторых преимуществ Synopsys как синтезатора Вам жизнь серая?
По пунктам, пожалуйста с исходниками...
Иначе Ваши мысли считаю трепом.

Я часто использую альтернативный способ описания асинхронного ресета. Традиционно делается так


Однако можно и так:

Во втором случае не требуется инициализировать по ресету все регистры, управляемые процессом, и вообще он более соответствует логике асинхронного ресета. Так вот XST во втором случае создаёт неправильный, нерабочий код, что в простых случаях легко можно видеть по RTL view. Создание кода, несоответствующего исходнику - это мегабаг для любого компилятора. Sinplify в подобном поведении никогда замечен не был.

И на тему корявости. Например, описываем процессор, у которого ALU с явно описанной системой мультиплексоров(а иначе невозможно получить нормальный дизайн) и предопределённой в соответствии с мультиплексорами системой кодов операций.

В таком случае Sinplify совершенно правильно отобразит младший бит opcode на младший бит alu_op. И второй бит opcode на третий из alu_op. А вот XST, не обращая внимания на расставленные 'X'(он воспринимает их, как нули), накрутит такой логики, что мама не горюй, что фактически не позволяет под ним использовать обобщённое описание декодера, без катастрофического падения perfomance.

Synplify идет на 2-4 года впереди ISE по расширению возможностей распознавания разных идиом.
Когда ISE не делал retiming, Synplify его уже делал - и повышал этим частоты в 1,1 - 1,7 раз.
И сейчас Synplify делает это лучше.
Опять же, в Synplify не проходит несоответствие разрядностей в выражениях - типичная ошибка, проходящая в ISE.
Кроме того, Synplify варнингами показывает, где написание текста корявое и требует исправления для красивости.
Наконец, Synplify рисует значительно красивее и компактнее картинки после синтеза - очень
квалифицированная иллюстрация, напр., для студентов.

Если делается IPCore, то его требуется проверить на синтез на всех популярных синтезаторах, включая Synplify.

Другое дело, Synplify рассчитан на все ПЛИС, а ISE - на свои собственные.
И поэтому ISE кое-какие синтезы удаются лучше, например, линии задержки на SRL16.

Я думаю, что создать "правильный" код по такому корявому исходнику - просто невозможно. Ваш код описывает не асинхронный ресет, а какую-то весьма странную нестабильную систему. Простой вопрос : что произойдёт если ресет и фронт тактового сигнала придут в один и тот же момент времени? Ваша схема ответа на этот вопрос не даёт. В нормальном описании побеждает ресет, на то он и асинхронный.
И это соответствует логике работы базового элемента FPGA. Так что синтезатор тут ни при чём, учите матчасть... Ну а то обстояетельство, что Sinplify переваривает даже такой корявый код, ни о каких преимуществах не говорит.

хммм, разве в стандарте на VHDL уже отменили требование по последовательное исполнение операторов в процессе ?

В таком случае (судя по описанию) получается что клок имеет приоритет над "якобы асинхронным" ресетом. Как это ляжет в железо? Да и ляжет ли вообще?
Code templates придумали неслучайно. Именно для того, чтобы не наступать на подобные грабли. Первое описание всеми синтезаторами трактуется одинаково, второе -
весьма странная конструкция, которая (по моему мнению) вообще не должна синтезироваться корректно.

это с каких это пор ? при последовательном исполнении операторов сверху вниз и при той модели присвоения сигналов, которая указанна в стандарте VHDL, сигнал сброса, в сабжевом коде, имеет более высокий приоритет, т.к. исполняется последним.

ЗЫ. в V, SV абсолютно тоже самое. В некоторых случаях это очень хороший способ описания логики, на форуме SM выкладывал как-то оччень интересные и красивые сорцы демонстрирующие это.

А красота то в чем?
В том что с ног на голову описание поставлено. (а потом для верности в rtl просмотрщик заглянуть, чтоб в правильности реализации по стандарту убедиться и ухмыляться, когда соратник в xst большую фигу наблюдает.)
И для этого еще дополнительно Synplify докупать?

найдите сорцы SM на эту тему и сами убедитесь.

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

А идиомы, рекомендуемые фирмой - это от ее убогости с 1 стороны
и для обучения новичков по методу "делай как я" с 2 стороны.

Можно и не докупать Synplify. Можно все задачи решить на Webpack'e.
Я в детстве увлекался вырезанием по дереву - и все ножичком, даже то, что можно токарным станком было.
Но как только добрался до токарного станка, стамесок, рубаночков - сразу пошло и качество, и скорость.
То же самое - с другими инструментами и в другой отрасли.

Synplify не нужен, чтобы писать хороший код. А с хорошим кодом достаточно XST.
Кроме того, основные проблемы в ISE с размещением, где ничто уже не поможет, кроме головы.

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




Почти всегда лучше - но так обидно бывает что на каких-то вроде мелочах обламывает вусмерть

Из последних "приколов" если например порты в VHDL объявит типа record то ISE создает имена отдельных портов соединяя имя record с именами полей в record а вот Synplify нет - будет тебе просто шина с именем как у record Хотя в SystemVerilog для interface тот же Synplify нормально имена создает - бардак какой то . На днях Synplify отказался модуль на Verilog вставлять в модуль на VHDL на его (Synplify ) взгляд какое-то несоответствие а какое - не сознается !!! Блин переписал все по новой - проверил каждый порт - в ISE, ActivHDL, Modelsim - все нормально а Synplify - "Unbound component aurora of instance u_aurora " падла!

Удачи! Rob.

Позволю себе привести описание уважаемого Oldring.
Хотелось бы узнать оценку сообщества (по стилю (красоте, читаемости) описания)
в контексте данного обсуждения (той или иной поддержки стандарта синтезаторами).

Приоритет имеет первый оператор, не последний. Сначала проверяется подходящее условие для него, а уж потом, если условие не выполняется, выполняются следующие операторы.

Написать сначала проверку фронта такта, а потом сброса... можно, и, наверное, все скомпилируется, в обход логики описания. А может быть, и нет... Не вижу ни одной причины нарушать приоритеты сигналов, заданные в железе ПЛИС.

Вот тут http://electronix.ru/forum/index.php?showt...st&p=764559 я когда-то "пошутил" с сигналами такта и сброса.

вы что издеваетесь? Напомню что речь идет про сабжевый код


Думаю что сами исправите свою ошибку %)

А если присваивания блокирующие? Посмотрите, что получается при компиляции следующего кода (я пользуюсь Quartus 9.1 SP2).

Можете переставить строки в блоке местами %.
ЗЫ. И _ff ему, Quartus'у, нипочем...
ЗЗЫ. Да и неблокирующие присваивания не помогают. Не получается у Quartus'а триггер, а получается - ...!
Похоже, издевка удалась, но не у меня.

Этот код вовсе не соответствует шаблону, который я приводил. Оператор "out = in;" тут выполняется не только по фронту clk, но и по фронту rst_n(при условии clk==1), чего допускать нельзя. Как написать полный аналог моего VHDL метода асинхронного сброса на Верилоге, я, честно говоря, даже не представляю. В Верилоге вроде нет функции проверки фронта сигнала, а без неё никак.

Похоже на то.
А des00 сказал "в V, SV абсолютно тоже самое".

У вас очень интересный способ аргументации.
Вместо того, что бы посмотреть стандарт на HDL, раздел касающийся присвоений сигналов и очередей исполнения. Убедится что в VHDL/V/SV любое присвоение сигнала, без задания временной задержки переопределяет все предыдущие присваивания.
Вы берете синтезатор(!!!!) как истину в последней инстанции, пишете код, который вступает в противоречие как с требованиям самого синтезатора, так и со стандартом на описание синтезируемых конструкций языка V (не знаю есть ли подобный документ для SV).

И предъявляете этот результат как однозначное опровержение того, что стандарты врут. Вам не кажется что вы, пытаясь доказать от противного, идете не по тому пути?

Если идти дальше, насчет вашего кода, то в симуляторе он ведет себя как триггер. А то что вас "напугало" в результатах синтеза, представляет собой классический двухтактный триггер, но без RS звена. И это будет работать, так как вы его описали, как триггер. А то что реализован не на аппаратных DFF, дык надо было стандартам следовать, код писать как рекомендуется.


Это сообществу решать


Если бы это было не так то ~40-50 % моих проектов в принципе бы не работали.

Я согласен, что был неправ в первом сообщении. И не доказываю свою правоту любым способом. Просто выясняю истину.
Переопределяет все предыдущие...? Разве блокирующее присваивание дожидается выхода из блока, а не задает сигнал каждый раз, когда выполняется? Посмотрю.
Но уже при проверке в реальном коде выяснилось, что для SV получается не тактируемый триггер, а latch. И временные диаграммы, что Quartus мне нарисовал, триггеру не соответствуют. Чего это у вас in скачет перед "нужными" тактами?

По-моему, вы тоже были неправы, когда сказали, что в V, SV то же самое, что и в VHDL. Зачем что-то решать и кому-то доказывать? Обычные дела. Главное, выяснилось, что в SV конструкция, предложенная Timmy, не работает. Такой результат дискуссии меня устраивает. Надеюсь, что и вас.

upd. Картинку из Квартуса добавил.

Уважаемые специалисты, нет ли у кого актуальной информации по порядку цен на одно лицензионное рабочее место на связку
Hdl Designer + Precision RTL + Model Sim SE ?

Обратитесь в Мегратек
Они официальные представители Ментора в России.

хмм, ну где то миллиона под 2 %)

А вдруг это учебное заведение?

Лучше все таки воспользоваться советом Stewart Little.
Да и моделсим не так дорог, в отличие от Questasim.