Как отлаживаете свои проекты?, Сбор возможных вариантов Опции

[Muscat]

Утро доброе

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

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

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

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

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

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

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

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

[XVR]

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

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

[ADA007]

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

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

[XVR]

А если, к пирмеру, нужно отследить реакцию проекта на комбинацию входных цифровых данных по интерфейсу согласно протоколу

Пишется разборщик протокола (с проверками)

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

Не всех, а отвечающих протоколу.

- то на моделирование этого всего может уйти о-о-очень много времени!!!!

Да, немало

Как быть в такой ситуации?

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

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

[ADA007]

Не всех, а отвечающих протоколу.

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

Потом загрузили в реальную FPGA и выловили еще больше багов

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