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

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).

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



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