sazh 8 24 мая, 2010 Опубликовано 24 мая, 2010 · Жалоба Я еще помню, как к нам заходил дядечка, заманивал на Altera. Показывал PALASM и т.п. И таки сманил. Ага. На халяву потянуло. Intel * PLDshell Plus. - FLEXlogic FPGA Альтера. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 24 мая, 2010 Опубликовано 24 мая, 2010 · Жалоба :bb-offtopic: Не Козич? Он кажись в 90-е начинал продвигать Альтеру, по крайней мере его первого знал. Точно, он. Я уже и фамилию забыл... Да и Вами, возможно, я имел дело :) И с Вашим другом, Васильевым. Ага. На халяву потянуло. Intel * PLDshell Plus. - FLEXlogic FPGA Альтера. То ли Вы не умеете ясно выражать мысли, то ли я такой тупой... Что Вы хотели сказать? Ну хоть убей, ... :) Лучше не касаться скользкой темы "халява". upd. По-моему, в то время все программы были бесплатными :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Builder 1 24 мая, 2010 Опубликовано 24 мая, 2010 · Жалоба :bb-offtopic: Точно, он. Я уже и фамилию забыл... Да и Вами, возможно, я имел дело :) И с Вашим другом, Васильевым. Да, мир тесен. Висильева я конечно-же знаю :) А Вы меня что, знаете? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 24 мая, 2010 Опубликовано 24 мая, 2010 · Жалоба Да, мир тесен. Висильева я конечно-же знаю :) А Вы меня что, знаете? Если ваши имя и фамилия - И.П., тогда знаю. Кстати, именно Васильев научил меня AHDL, и на реальном проекте, и просто как учитель (приходил к нам, молодой и зеленый), а потом я решил, что и сам так смогу :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aprox 0 25 мая, 2010 Опубликовано 25 мая, 2010 · Жалоба Значительное сокращение времени разработки+минимизация ошибкок, вносимых самим разработчиком. Я все время пытаюсь донести до сознания почтенной публики, что "сокращение времени разработки+минимизация ошибкок" за счет использования сторонних симуляторов с совместимостью по языку 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 25 мая, 2010 Опубликовано 25 мая, 2010 · Жалоба ...И даже ТЗ часто приходиться корректировать на ходу... Вот-вот. Именно из-за Вашего подхода "без моделирования" Вам и приходится менять ТЗ на ходу. Так как "что выросло, то выросло". :) Надо, чтобы разработчик контролировал проект, а не наоборот. То, что убедить Вас в необходимости серьезной функциональной верификации не получится (хоть цели и не стояло), я думаю, все уже поняли. Но главное, чтобы начинающие разработчики из этой темы вынесли правильные выводы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 25 мая, 2010 Опубликовано 25 мая, 2010 · Жалоба Чтобы сделать правильные выводы, достаточно взглянуть на количество errata у производителей ПЛИС. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Des333 0 25 мая, 2010 Опубликовано 25 мая, 2010 · Жалоба Чтобы сделать правильные выводы, достаточно взглянуть на количество errata у производителей ПЛИС. Можно озвучить выводы? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 25 мая, 2010 Опубликовано 25 мая, 2010 · Жалоба Не хочу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Des333 0 25 мая, 2010 Опубликовано 25 мая, 2010 · Жалоба Не хочу. Все ясно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dinam 1 26 мая, 2010 Опубликовано 26 мая, 2010 · Жалоба Правильно ли я понял что вы хотели сказать что errata у ПЛИС почти нет по сравнению с МК и DSP? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
andrew_b 16 26 мая, 2010 Опубликовано 26 мая, 2010 · Жалоба Я все время пытаюсь донести до сознания почтенной публики, что "сокращение времени разработки+минимизация ошибкок" за счет использования сторонних симуляторов с совместимостью по языку Verilog- это миф. Миф, рожденный разработчиками этого стороннего ПО. На самом деле сторонние инструменты только множат сложности и ошибки, которые все равно потом придется исправлять в "железе". Я бы на вашем месте не стал бы говорить о том, чего вы не знаете. Вы пользовались сторонними симуляторами? Языки описания аппартуры стандартизованы. Поэтому все симуляторы должны работать так, как написано в стандарте яыка. Баги, конечно, присутствуют, куда же без них. Тут точно такая же ситуация, как и с языками программирования: язык Си, например, стандартизован, поэтому все компиляторы должны генерировать код, работающий в соответствии со стандартом языка. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Leka 0 26 мая, 2010 Опубликовано 26 мая, 2010 (изменено) · Жалоба Правильно ли я понял что вы хотели сказать что errata у ПЛИС почти нет по сравнению с МК и DSP? Не это, МК и DSP тоже ведь верифицируются разработчиками ("ПЛИС" - лишнее в моей фразе). А что errata хватает, хотя трудозатраты на верификацию в разы больше затрат на собственно разработку. Изменено 26 мая, 2010 пользователем Leka Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
xvr 12 26 мая, 2010 Опубликовано 26 мая, 2010 · Жалоба Пока все ответы Aprox идут в русле 'Пастернака не читал, но осуждаю' 'Давайте спорить до хрипоты, до драки о вкусе устриц, с теми кто их ел' (М.М. Жванетский) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aprox 0 26 мая, 2010 Опубликовано 26 мая, 2010 · Жалоба Вот-вот. Именно из-за Вашего подхода "без моделирования" Вам и приходится менять ТЗ на ходу. А у вас идеальный заказчик и может сразу выдать стабильное ТЗ? Так в жизни никогда не бывает. То, что убедить Вас в необходимости серьезной функциональной верификации не получится (хоть цели и не стояло), я думаю, все уже поняли. Но главное, чтобы начинающие разработчики из этой темы вынесли правильные выводы. Я буду счастлив, если начинающие разработчики поймут, что ТЗ всегда неточно. Это правило #1 всех прикладников. Из этого правила следует, - моделирование по неточному ТЗ есть пустая трата времени и сил. Я бы на вашем месте не стал бы говорить о том, чего вы не знаете. Вы пользовались сторонними симуляторами? Нет, для FPGA не пользуюсь. Потому, что в этой области слишком много "аппаратного", а полноценно симмулировать аппаратуру никто еще не умеет. Вернее, не успевают создать грамотную модель, как появляется новая аппаратура. Языки описания аппартуры стандартизованы. Поэтому все симуляторы должны работать так, как написано в стандарте яыка. Я зыки, может, и стандартизованы. В вот модель аппаратной начинки нет. Именно поэтому в области отладки приложений на микроконтроллерах и умерли симуляторы. Из-за невозможности моделировать периферию этих микроконтроллеров. Та же история ждет и FPGA, поскольку там пошли по пути наращивания аппаратно жесткой периферии: память, DSP-.блоки, процессоры связи, PLL. Интересно, как будут справляться ваши модели с нахлынувшим разнообразием аппаратуры. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться