Утро доброе

Задумался я тут вот над каким вопросом.
Долго ли коротко ли, на VHDL-ли на Verilog-ли, проект написан и даже синтезировался, и даже прошился в ПЛИС и даже кажется работает как надо.

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

Какими средствами вы отлаживаете свои проекты?

Я для себя пока опробовал несколько путей

1) Простой проект. Отладка по аналогии с отладкой на уровне разработки. Пишется TestBench модуль, который может выдавать ряд простейших воздействий, затем модуль присовокупляется к проекту, запускается. Управление кнопками, просмотр реакции на осциллографе.
Плюсы подхода
- Каждый сигнал можно просмотреть хоть в цифровом, хоть в аналоговом виде, отловить все задержки.
Минус такого подхода
- Ограниченность вариантов входных воздействий
- На экране осциллографа больше 16 сигналов не разглядишь.

2) Отладка в цифре. Метод, который я сейчас пытаюсь применить к своему проекту. Большинство современных DevKit'ов имееют встроенный RS232 модуль или того лучше - преобразрователь USB->RS232, а на PC устанавливается драйвер виртуального КОМ-порта. Тогда физически RS232 нигде не появляется, ограничение на скорость повышаются до уровня USB, а мы имеем возможность работать с железкой через старый добрый UART.
Далее пишется, или скачивается с OpenCores, модуль RS232, дописывается модуль хранения и выдачи этих данных, а так же приема данных с ПЛИС.
Следующий этап - программная часть комплекса. Тут можно использовать объектно-ориентированный язык, на вроде С++ или среды DELPHI, можно попробовать писать из среды мат.моделирования Matlab,чем я сейчас как раз и занимаюсь.
Плюсы метода - объем входных последовательностей для тестирования ничем не ограничен, полностью управляется с PC, на нем же просмотр полученных результатов. Минусы если что можно компенсировать добавлением осциллографа.

А какие пути используете вы?
Многообещающе выглядит решение от компании Mathworks и Xilinx, по включению ПЛИС в качестве модуля в среды Simulink через JTAG с отслеживанием состояния всех ножек сразу.
Пробовали ли вы другие какие то интерфейсы? Можно ли включить ПЛИС в среду ModelSim и отслеживать состояния выходов так же, как при моделировании?

В общем предлагаю всем поделиться частью своего опыта

См Chipscope
http://www.xilinx.com/tools/cspro.htm

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

Я например, пытался организовать тестирование путем записи данных в распаяные на ките микросхемы FLASH через поставляемую производителем утилиту, а затем чтение данных напрямую в ПЛИС.
В итоге почти месяц непрерывного гемора и в сухом остатке только бесценный опыт.

Сначала как-то вот так
http://www.ovmworld.org/
http://www.doulos.com/content/training/ovm.php

Ну а потом, после заявлений прогеров "я вот написал прогу, а твой чип не работает" , конечно ChipScope/SignalTap

ИМХО, все зависит от конкретного проекта. В любом случае, основное средство для отлавливания ошибок - электронный осциллограф (для Xilinx, как уже писали - chipscop).
Иногда нет вообще возможности подрубиться к ногам плисины, пример: данные передаются на частоте 1ГГц, стандарт lvds.
Был проект - закачка изображения в zbt ram (из pc_power), далее передача с некоей скоростью его с одной плисины на другую и запись опять же в zbt_ram. Проверялось сначала путем сличения картинок визуально, затем было программно автоматизировано (на приемнике хранились исходные изображения).
Самый сложный проект для отладки, с которым приходилось работать - цифровой модем (при этом в ТЗ естественно и высокий уровень шума и доплер). Отладка - связка передатчик+приемник. На передатчике помимо основного проекта зашиты:
1. на передатчике - эмулятор канала AWGN и модуляция с возможностю изменения моделирующей частоты (задавались некие коэффициенты значения уровня шума и смещения тактовой посредством xmd и встроенного программного процессора).
2. на передатчике и приемнике - некий одинаковый генератор ПСП.
3. два счетчика на приемнике - для счета общего числа пакетов (в моем случае была преамбула), и счетчик на принятые пакеты.
4. Простейшая логика для подсчета вероятности и вывод ее текущего значения посредством xmd.
Так вот снималась эта вероятность в различных точках и строился график, график сравнивался с графиком матлабовской модели и графиком вероятности, рассчитанной в теоретии. Далее шло обоснование потерь в дБ (за счет ограничения разрядности в коэффициентах фильтров, к примеру).

bogaev_roman вот как раз к описанному вами я и хочу прийти. Отлаживаю декодер Витерби, строю графики. Имеется теоретический график, имеется модель повторяющая работу ПЛИС со всеми ограничениями. Заключительный этап - подавать на ПЛИС те же данные, что и в модель, смотреть на вероятность ошибки и ставить эксперементальные точки на график BER.

Модель в Modelsim-е (прошу прощения за тавтологию) с максимальным покрытием, учитывающим временные ресурсы и желание гражданина анализатора результатов изучать диаграммы и логи. 95% глюков отсеиваются на этом этапе. Оставшиеся 5% выползают при включении девайса и фиксируются осциллом и SignalTap-ом.

Вывод: компьютерное моделирование рулит.

В вашем случае:
1. Создается модель, полностью идентичная описанию(разрядность и все задержки, с учетом того, что simulink, по умолчанию по срезу работает)!!!
2. Ставится в параллель в simulink модель и HDL описание (не помню как блок называется для вставки HDL), эти модели имеют одинаковые входные воздействия, оба выхода поступают на блок сравнения и результат работы их должен быть одинаковым. Ставите моделирование на ночь, скажем, и убеждаетесь, что модели идентичные (и убрать все осциллографы, они систему вешают серьезно).
3. При необходимости можно вместо HDL модели RTL уровня, подсунуть gate level (читайте документацию, но это сильно вешает систему).
4. Есть возможность, как Вы уже описывали с помощью Mathworks и Xilinx реально отследить поведение в плис (я этим не занимался) либо самому написать ber тестер и генератор входных воздействий.
5. Отладка Ваша упрощается тем, что если произошел какой-то существенный сбой, то Ваш декодер накроется медным тазом и приведет скажем к возникновению групповых ошибок. Вот это условие и можете сформировать посредством простейшей логики, как останов работы (событие) chipscop и просмотреть все то, что было до этого события в системе, а дельше найти причину сбоя.
PS 1. Генератор шума и многие блоки simulink можно сгенерировать автоматически в HDL код (если соответствующая утилита поставлена), если модель полностью идентична описанию и Ваш проект влазит по временным ограничениям, то 99% что в ПЛИС все будет работать правильно.

bogaev_roman , Спасибо огромное за информацию. Да, такой путь был бы идеальным, мне его уже рекомендовали. Но проблема в том, что моя модель написана на языке Matlab и я не представляю даже, как собрать мой декодер в Симулинке.
Я собирал в Симулинке модели со встроенными декодерами, генераторами сигналов и канала. Но как описать сам декодер - автоматы управления, блоки памяти, поиска минимума, сумматоры, не представляю.

В Simulink можно просто кусок HDL кода вставить.

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

У меня к сожалению сейчас нет Matlab, но как я помню там разбираться особо не в чем. Есть блок, HDL-cosimulation (в EDA Simulator Link). Cтавите его в модель, настраиваете связь с Modelsim - и все. Исчерпывающее руководство по этому процессу можно найти по ссылке http://www.mathworks.com/products/eda-simulator/

Посмотрите этот документ.

От себя добавлю немного, хотя тоже самое http://embedders.org/content/sovmestnoe-mo...asim-i-simulink
Ключевое слово HDL Cosimulation, сам когда-то руководство целое писал, но затерялось где-то...

Есть ещё такая прекрасная вещь как DSP Builder (от Альтеры, наверное и у Ксайлинкса есть что то подобное), который на прямую связан с Квартусом. После того как начал ею пользоваться перешел на первоначальное моделирование в матлабе (симулинк), ибо гораздо быстрей формировать сигналы (к примеру ЛЧМ) и прочее с помощью возможностей симулинка, чем в моделсиме, где надо все на языке описывать. Ну на заключительном этапе конечно же в моделсиме отлаживаю.
Ну а помимо мат. моделирования, конечно же, Signal Tap использую.

Кстати по поводу отладки - никто не знает, где можно купить большой шаманский бубен? Очень универсальная вещь - и софт можно отлаживать, и схемы и даже компы чинить

PS. Если серьезно - то симулятор, симулятор и еще раз симулятор. И тестбенчи (много много раз)

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

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

Честно говоря, гораздо дешевле, но не обязательно быстрее, подумать как следует и сделать необходимые эмуляции протоколов в симуляторе.
Что-то упростить, где-то отладить по частям отдельные блоки.
Несколько лет уже не пользуюсь осциллографом, анализатором и средствами chipscope/signal tap. Только симуляторы.
У меня и квалификации-то нехватает грамотно подключать приборы на гигагерцах, чтобы "вскрытие не показало, что чукча умер от вскрытия".

Простите за оффтоп, но с недавних пор меня мучает один вопрос - как доказать корректность тестбенча, который ты сам разработал?

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

Хорошо, тогда как доказать корректность тестбенча, который кто-то разработал?

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

Пишется разборщик протокола (с проверками)
Не всех, а отвечающих протоколу.
Да, немало



Пример - есть девайс, подключаемый через Ethernet (формат пакетов свой). Был написан эмулятор PHY (по MII) + разбор/формирование Ethernet пакета (со стороны PHY) + обработчик протокола (на уровне пакетов). И к этому стеку был подсоединен генератор случайных команд (в протоколе). Так же со стороны отлаживаемого девайса были подсоединены эмуляторы внешних устройств (квадратурные энкодеры, DAC'и по SPI). Тест проверял правильность передачи на них данных (через стек).

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

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

Очень волнующая меня тема. Считаю, что для повышения качества теста имеет смысл применять принцип минимальной обработки информации.
Если есть возможность copy-paste табличку из datasheet прямо в VHDL или текстовый файл и его потом читать, то так и надо делать.
Программист не должен обрабатывать информацию, только переносить и документировать откуда что взялось. Написано 10+1+5-1, так и надо записать, не стоит писать 15, лучше указать откуда взялось каждое из чисел. Будет проще доказывать, "что верблюд не вы".

Еще есть риск, что весь мир дружно отступает от стандарта (длина преамбулы в ethernet 10BaseT).

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



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