[sazh 8]

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

И таки сманил.

 

Ага. На халяву потянуло.

Intel * PLDshell Plus. - FLEXlogic FPGA Альтера.

[ViKo 1]

:bb-offtopic:

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

Точно, он. Я уже и фамилию забыл...

Да и Вами, возможно, я имел дело :) И с Вашим другом, Васильевым.

 

Ага. На халяву потянуло.

Intel * PLDshell Plus. - FLEXlogic FPGA Альтера.

То ли Вы не умеете ясно выражать мысли, то ли я такой тупой... Что Вы хотели сказать? Ну хоть убей, ... :)

Лучше не касаться скользкой темы "халява".

upd. По-моему, в то время все программы были бесплатными :)

[Builder 1]

:bb-offtopic:

Точно, он. Я уже и фамилию забыл...

Да и Вами, возможно, я имел дело :) И с Вашим другом, Васильевым.

Да, мир тесен. Висильева я конечно-же знаю :)

А Вы меня что, знаете?

[ViKo 1]

Да, мир тесен. Висильева я конечно-же знаю :)

А Вы меня что, знаете?

Если ваши имя и фамилия - И.П., тогда знаю.

Кстати, именно Васильев научил меня AHDL, и на реальном проекте, и просто как учитель (приходил к нам, молодой и зеленый), а потом я решил, что и сам так смогу :)

[aprox 0]

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

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

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

"Не верю" -(с) Станиславский.

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

У меня другие оценки. Отладка на "железе" - это 80% времени. Т.е. самое главное и самое отвественное мероприятие, когда вдруг всплывает все то, что никаким моделированием никогда не предусмотришь. И даже ТЗ часто приходиться корректировать на ходу. Ваше условие "если моделирование было сделано грамотно"- это чистая иллюзия. Хотя бы просто потому, что худо-бедно адекватная модель для тестирования требует усилий и времени в разы больше, чем непосредственно программирование приложения задачи. Посмотрите на разработчиков ПО, им уже давно понятно, что стопроцентно протестировать продукт и отловить все баги они не в состоянии. Поэтому выпускают полусырой вариант и доводку ведут силами пользователей.

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

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

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

Не убеждает. Точно такой же был случай и в нашем коллективе. Только приглашенный "спец" писал на Veriloge довольно сложную кору, якобы универсальную. А потом ходил к нам два месяца отлаживал написанное на реальном железе. Сходу, абстрактным моделированием ничего не получилось. Как видите, Verilog и в данном случае оказался ничем не лучше AHDL.

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

Нет, не проваливаются. Все предварительные исследования систем с обратной связью проводят интсрументами, специально для этого предназначенными, например MatLab. И Verilog совершенно от таких инструментов не требуется. Достаточно будет, если будут найдены численные значения ряда параметров и коэффициенты так полюбившихся фильтров. И все. Дальше пишите в Ква на чем хотите, лишь бы правильно было. При чем здесь Verilog? Кстати, вы так и не ответили- в сгенерированных исходниках фильтров будет указание для Ква использовать аппаратные DSP-блоки например Cyclone-III? Или придется вручную "констрейнить"? И сколько ошибок будет наляпано при таком констрейне?

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

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

А вот что касается умножения или памяти, то выделит по-любому, если они физически есть на ПЛИС.

"Не верю."- ©-Станиславский

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

"Размазать" может запросто, если большой процент использования LEs в FPGA и в проекте заданы более приоритетные по скорости узлы.

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

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

[Des333 0]

 ...И даже ТЗ часто приходиться корректировать на ходу...

 

Вот-вот. Именно из-за Вашего подхода "без моделирования" Вам и приходится менять ТЗ на ходу. 

 

Так как "что выросло, то выросло". :)  

 

Надо, чтобы разработчик контролировал проект, а не наоборот.

 

 

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

[Leka 1]

Чтобы сделать правильные выводы, достаточно взглянуть на количество errata у производителей ПЛИС.

[Des333 0]

Чтобы сделать правильные выводы, достаточно взглянуть на количество errata у производителей ПЛИС.

Можно озвучить выводы?

[Leka 1]

Не хочу.

[Des333 0]

Не хочу.

 

Все ясно.

[dinam 1]

Правильно ли я понял что вы хотели сказать что errata у ПЛИС почти нет по сравнению с МК и DSP?

[andrew_b 17]

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

Я бы на вашем месте не стал бы говорить о том, чего вы не знаете. Вы пользовались сторонними симуляторами?

 

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

[Leka 1]

Правильно ли я понял что вы хотели сказать что errata у ПЛИС почти нет по сравнению с МК и DSP?

Не это, МК и DSP тоже ведь верифицируются разработчиками ("ПЛИС" - лишнее в моей фразе). А что errata хватает, хотя трудозатраты на верификацию в разы больше затрат на собственно разработку.

Изменено 26 мая, 2010 пользователем Leka

[xvr 12]

Пока все ответы Aprox идут в русле 'Пастернака не читал, но осуждаю'

 

'Давайте спорить до хрипоты, до драки о вкусе устриц, с теми кто их ел' (М.М. Жванетский)

[aprox 0]

Вот-вот. Именно из-за Вашего подхода "без моделирования" Вам и приходится менять ТЗ на ходу. 

А у вас идеальный заказчик и может сразу выдать стабильное ТЗ? Так в жизни никогда не бывает.

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

Я буду счастлив, если начинающие разработчики поймут, что ТЗ всегда неточно. Это правило #1 всех прикладников. Из этого правила следует, - моделирование по неточному ТЗ есть пустая трата времени и сил.

 

 

Я бы на вашем месте не стал бы говорить о том, чего вы не знаете. Вы пользовались сторонними симуляторами?

Нет, для FPGA не пользуюсь. Потому, что в этой области слишком много "аппаратного", а полноценно симмулировать аппаратуру никто еще не умеет. Вернее, не успевают создать грамотную модель, как появляется новая аппаратура.

Языки описания аппартуры стандартизованы. Поэтому все симуляторы должны работать так, как написано в стандарте яыка.

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