[Des333 0]

Иными словами, вы говорите не про язык Verilog, а про некие сторонние инструменты, совместимые с Verilog. А я прошу указать преимущество именнно в языке, а не в сторнних инструментах поддержки.

Какой иностранный язык следует учить в первую очередь?

Если рассуждать согласно Вашей логике, то, что английский является международным языком - не является "преимуществом" языка.

Следовательно, если, к примеру, датский, настолько же прост/сложен в обучении, как и английский, то ответ на вопрос, какой из двух языков - датский или английский учить в первую очередь, будет с 50% вероятностью "датский".

 

Это я к чему?

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

 

А то, вон, Bluespec - всем хорошо, только синтезатор не найти. :)

 

 

 

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

Подождем, увидим-с.  :)

[dvladim 0]

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

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

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

Там где цена ошибки велика, там тестируется, моделируется, макетируется все что можно. Приведу еще один пример: я видел схему бесперебойника, где ключи инвертор управлялись с контроллера. Если оба ключа открыть, то они сгорят. Вот как в этом случае отлаживать без моделирования?

[aprox 0]

Если рассуждать согласно Вашей логике, то, что английский является международным языком - не является "преимуществом" языка.

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

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

Рыночный аргумент, а хотелось бы научно-технический.

 

 

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

Метастабильности лучше всего не допускать на стадии проектирования. Там, где никак не избежать разных клоков- следовать рекомендациям Altera, как делать защиту, или использовать мегафункции с такой защитой, например, двухпортовая память или fifo. Ничего моделировать с целью проверить уже не придется. Кроме того, испытания на железе в реальных условиях много надежнее выявляют маловероятные сбои из-за метастабильности потому, что число испытаний на прядки больше, нежели в модели.

Там где цена ошибки велика, там тестируется, моделируется, макетируется все что можно. Приведу еще один пример: я видел схему бесперебойника, где ключи инвертор управлялись с контроллера. Если оба ключа открыть, то они сгорят. Вот как в этом случае отлаживать без моделирования?

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

[bogaev_roman 0]

а про некие сторонние инструменты, совместимые с Verilog

Поддержка различными тулсами это и есть столь очевидное преимущество и

возможность

по сравнению с ahdl

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

Простите, а не Вы случаем "булаву" начинкой заправляет? А если по существу, то именно для сложных проектов такая возможность как раз очень редко и возникает. Я вот как-то не представляю себе возможности отладить передатчик на спутнике, например. :)

С симуляторами уже закончили играться в сфере микроконтроллеров

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

Например, в этом треде я представил тест-обертку на AHDL для модуля, написанного на VHDL. При этом, совершенно не понимая, что там написано на этом самом VHDL. Разве это не доказательство, что нет никаких преград для совместной работы в разноязычном коллективе

Ну Вы тестированием сложной системы на моделях все равно не занимаетесь поэтому данный пункт можно действительно опустить.

владеющих Verilog- они говорят, что примитивы и мегафункции надо обьявлять вручную. Буду рад ошибиться

В мегафункциях эти особенности архитектуры учитываются

Если правильно описать или указать, то ничего вручную объявлять не надо и квартус сам влепит после синтеза мегафункцию с особенностями.

И вообще, у меня такое впечатление, что я веду диспут с людьми другой профессии. Hе разработчиками конкретной аппаратуры, а скорей с программистами универсального IP. Естественно, что общего языка найти становиться невозможным.

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

[aprox 0]

Поддержка различными тулсами это и есть столь очевидное преимущество и по сравнению с ahdl

Рыночный аргумент, а хотелось бы научно-технический.

Простите, а не Вы случаем "булаву" начинкой заправляет? А если по существу, то именно для сложных проектов такая возможность как раз очень редко и возникает. Я вот как-то не представляю себе возможности отладить передатчик на спутнике, например. :)

Про Evaluation Board слышали?

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

Вы кажется писали, что все кривые отклика фильтра можно посмотреть заранее, на этапе MatLab? Поверьте, если в проект фильтра на FPGA заложили полученные на том этапе коэффициенты, то ничего уже дополнительно проверять в работе фильтра не потребуется. Ваш пример с фильтром не убеждает в необходимости моделировать проект целиком, а значит, и в жгучей необходимости сторонних симуляторов с совместимостью по языку Verilog.

 

Надежность проектирования и сопровождения изделий на FPGA достигается отнюдь не моделированием, а модульностью проектирования. При грамотном разбиении проекта на модули, каждый может быть проверен и отлажен простейшими средствами Quartus, без привлечения сторонних инструментов. Моделирование на этапе проверки уже не требуется, поскольку все равно окончательная доводка будет происходить на "железе" и только там.

Если правильно описать или указать, то ничего вручную объявлять не надо и квартус сам влепит после синтеза мегафункцию с особенностями.

Видите, надо оказывается правильно описать или указать, а сам Verilog не соображает. AHDL же соображает самостоятельно. Если декларировал переменную cnt[7..0]:dff. а секции логики написал cnt[]=cnt[]+1 , то автоматом синтезатор потащит мегафункцию lpm_counter без моего участия. А теперь возьмем ваш пример с моделированием фильтра в MatLab и генерацией исходника фильтра на Verilog. Будут ли в том исходнике признаки, по которым Qurtus догадается, что надо использовать мегафункции блоков умножения-сложения, например для Cyclone-III?

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

С этим не поспоришь. Разработчки софта дурить мозги умеют.

[ViKo 1]

Удовлетворите мое любопытство - какой язык предлагала использовать в разработках фирма Xilinx до VHDL и Verilog? Неужели AHDL? А другие производители?

[andrew_b 14]

Удовлетворите мое любопытство - какой язык предлагала использовать в разработках фирма Xilinx до VHDL и Verilog?

У Хilinx был пакет ViewLogic лет этак 15 назад. Это схемный ввод. Был и свой язык ABEL.

[CaPpuCcino 0]

какой язык предлагала использовать в разработках фирма Xilinx до VHDL и Verilog? Неужели AHDL? А другие производители?

мАлАдёж :)

[ViKo 1]

мАлАдёж :)

Это не про меня.

Я еще помню, как к нам заходил дядечка, заманивал на Altera. Показывал PALASM и т.п.

И таки сманил. И так как я сам решаю, что применять, пока обхожусь одной Altera.

Вот оно, преимущество универсальных языков: захотел Xilinx - слегка подредактируй код, и пользуйся.

[bogaev_roman 0]

Рыночный аргумент, а хотелось бы научно-технический.

Значительное сокращение времени разработки+минимизация ошибкок, вносимых самим разработчиком.

Вы же не будете спорить, что печать на компьютере лучше, нежели печать на печатной машине?

Про Evaluation Board слышали?

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

:bb-offtopic: Пару лет назад лично занимался разработкой некоей аппаратуры для военных, устройство требовалось вручную подключить к модулю который в глаза до этого не видел. Весь день сидишь и ждешь пока дойдет твоя очередь до разетки и на коленках проверяешь работоспособность. И ни о каком БОРДЕ речь идти вообще не может.

Второй пример: на нашу плату вешалась другая. Так вот эту плату делали "спецы" (из ростова вроде) и на базе альтера, только вот проблема была - проект на Ahdl. Парнишка каждый месяц в командировки приезжал для совместной отладки на "железе" в Москву. В итоге вроде как все и заработало, только вот после тестовой партии дальше отказались работать с ними, реализовав все у себя. В итоге - потратили полгода на совместную отладку, а потом все заново написали за 2 месяца и тут уже вопрос не только экономический, но и технический т.к. при изменении неких характеристих никому геморрой на полгода только из-за проблем отсутствия человеческого совместного моделирования не нужен.

Это Вы можете ethernet или fiber channel проверить так просто, ну или кодек какой по ГОСТу. Когда делаешь сложную систему связи, например, никакой боард не поможет без человеческого моделирования (ну или Вам самим этот боард сначало сделать надо).

Вы кажется писали, что все кривые отклика фильтра можно посмотреть заранее, на этапе MatLab? Поверьте, если в проект фильтра на FPGA заложили полученные на том этапе коэффициенты, то ничего уже дополнительно проверять в работе фильтра не потребуется. Ваш пример с фильтром не убеждает в необходимости моделировать проект целиком, а значит, и в жгучей необходимости сторонних симуляторов с совместимостью по языку Verilog.

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

Надежность проектирования и сопровождения изделий на FPGA достигается отнюдь не моделированием, а модульностью проектирования. При грамотном разбиении проекта на модули, каждый может быть проверен и отлажен простейшими средствами Quartus, без привлечения сторонних инструментов.

Ну да, конечно. Только вот Вы наверное никогда не слышали о системах с обратной связью :) Все Ваши доводы по поводу модульности и тестированием простешими средствами Ква проваливаются моментально если, например, взять снятие ПШС с подстрой по частоте.

cnt[]=cnt[]+1

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

А вот интересно, если я написал на ahdl именно cnt[]=cnt[]+1 с большой разрядностью, то может ли квартус "размазать" счетчик, не ставя рядом друг с другом используемые элементы(имеется ввиду, что обычно он делает все кучно, если выделяет мегафункцию)?

Вы так и не ответили на вопрос - каким образом ищите ошибки - визуально, сравнивая времянки?

Изменено 24 мая, 2010 пользователем bogaev_roman

[sazh 3]

cnt[]=cnt[]+1

Это один из немногих примеров где он не распознают мегафункцию.

 

Это один из примеров, где квартус однозначно опознает мегафункцию (в зависимости от семейства fpga) что на AHDL, что на verilog.

Все идентично.

[bogaev_roman 0]

to sazh

Это один из примеров, где квартус однозначно опознает мегафункцию (в зависимости от семейства fpga) что на AHDL, что на verilog.

Все идентично.

На верилог после синтеза записи в квартусе cnt<=cnt+1 будет отображаться сумматор на RTL Viewer, далее он будет соптимизирован.

[sazh 3]

to sazh

 

На верилог после синтеза записи в квартусе cnt<=cnt+1 будет отображаться сумматор на RTL Viewer, далее он будет соптимизирован.

 

На семействах 7000, 3000, ACEX эта запись порождает lpm_counter.

А об циклонах и т.д. наш оппонент не знает.

[bogaev_roman 0]

На семействах 7000, 3000, ACEX эта запись порождает lpm_counter.

А об циклонах и т.д. наш оппонент не знает.

Тогда извиняюсь, я со стратикс4 сейчас работаю, для него и писал про счетчик...

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

Изменено 24 мая, 2010 пользователем bogaev_roman

[Builder 0]

Я еще помню, как к нам заходил дядечка, заманивал на Altera. Показывал PALASM и т.п.

Не Козич? Он кажись в 90-е начинал продвигать Альтеру, по крайней мере его первого знал.