Опит с разработка, управлявана от тестове (TDD) за проектиране на логика (чип) във Verilog или VHDL

Пиша код за FPGA, не за ASICS... но TDD все още е моят предпочитан подход. Харесва ми да имам пълен набор от тестове за целия функционален код, който пиша, и се опитвам (не винаги успешно) първо да напиша тестов код. Взирането в вълновите форми винаги се случва в даден момент, когато отстранявате грешки, но това не е добър начин за валидиране на вашия код (IMHO).

Като се има предвид трудността при извършване на правилни тестове в реалния хардуер (стимулирането на ъглови случаи е особено трудно) и факта, че VHDL-компилирането отнема секунди (срещу компилирането „към хардуер“, което отнема много минути (или дори часове)), не Не виждам как някой може да работи по друг начин!

Също така вграждам твърдения в RTL, докато го пиша, за да уловя неща, които знам, че никога не трябва да се случват. Очевидно това се възприема като малко „странно“, тъй като има схващане, че инженерите по проверка пишат твърдения, а RTL дизайнерите не. Но най-вече аз съм собственият си инженер по проверка, така че може би това е причината!

Използвам VUnit за тестова разработка с VHDL.

VUnit е библиотека на Python, която извиква VHDL компилатора и симулатора и чете резултатите от симулацията. Освен това предоставя няколко хубави VHDL библиотеки, които улесняват много писането на по-добри тестови тестове, като например комуникация библиотека, библиотека за регистриране и проверка на библиотека.

Има много възможности, тъй като се извиква от Python. Възможно е както генериране на тестови данни, така и проверка на изходните данни от теста в Python. Онзи ден видях този пример, където използваха Octave - копие на Matlab - за изобразяване на резултатите от теста.

VUnit изглежда много активен и няколко пъти успях да задам въпроси директно на разработчиците и получих помощ доста бързо.

Недостатъкът е, че е по-трудно да се отстраняват грешки при компилиране, тъй като има толкова много вариации на функция/процедура с едно и също име в библиотеките. Освен това някои неща се правят зад сцената чрез предварителна обработка на кода, което означава, че някои грешки може да се появят на неочаквани места.

Не знам много за дизайна на хардуера/чипа, но съм дълбоко в TDD, така че мога поне да обсъдя пригодността на процеса с вас.

Въпросът, който бих нарекъл най-уместен, е: Колко бързо вашите тестове могат да ви дадат обратна връзка за дизайн? Свързано с това: Колко бързо можете да добавите нови тестове? И колко добре вашите инструменти поддържат рефакторинг (промяна на структурата без промяна на поведението) на вашия дизайн?

Процесът на TDD зависи до голяма степен от „мекотата“ на софтуера – добрите автоматизирани тестове на единици се изпълняват за секунди (минути отвън) и насочват кратки изблици на фокусирано изграждане и рефакторинг. Вашите инструменти поддържат ли този вид работен процес - бързо циклично преминаване между писане и изпълнение на тестове и изграждане на тестваната система в кратки итерации?

Разширенията SystemVerilog към стандарта IEEE Verilog включват разнообразие от конструкции, които улесняват създаването на задълбочени тестови пакети за проверка на сложни цифрови логически дизайни. SystemVerilog е един от езиците за проверка на хардуера (HVL), който се използва за проверка на дизайна на ASIC чипове чрез симулация (за разлика от емулация или използване на FPGA).

Значителни предимства пред традиционния език за проектиране на хардуер (Verilog) са:

• ограничена рандомизация
• твърдения
• автоматично събиране на функционални данни и данни за покритие на твърдения

Ключът е да имате достъп до софтуер за симулация, който поддържа този скорошен (2005) стандарт. Не всички симулатори поддържат напълно по-разширените функции.

В допълнение към стандарта IEEE има библиотека с отворен код SystemVerilog от компоненти за проверка, достъпна от VMM Central (http://www.vmmcentral.com). Той осигурява разумна рамка за създаване на тестова среда.

SystemVerilog не е единствената HVL и VMM не е единствената библиотека. Но бих препоръчал и двете, ако имате достъп до подходящите инструменти. Открих, че това е ефективна методология за намиране на грешки в дизайна преди да стане силикон.

По отношение на инструментите за рефакторинг за хардуерни езици бих искал да ви насоча към нашия инструмент Sigasi HDT. Sigasi предоставя IDE с вграден VHDL анализатор и VHDL преработки.

Филип Фаес, Сигаси

ANVIL – Друг слой за взаимодействие на Verilog говори за това. Не съм пробвала.

Никога не съм опитвал активно TDD на RTL дизайн, но имах своите мисли по този въпрос.

Това, което мисля, че би било интересно, е да се изпробва този подход във връзка с твърдения. По принцип първо бихте записали под формата на твърдения какво предполагате/очаквате от вашия модул, напишете вашия RTL и по-късно можете да проверите тези твърдения с помощта на официални инструменти и/или симулация. За разлика от „нормалните“ тестови случаи (където вероятно ще трябва да напишете насочени такива) трябва да имате много по-добро покритие и твърденията/предположенията могат да бъдат полезни и по-късно (напр. на системно ниво).

Въпреки това не бих разчитал изцяло на твърдения, това може да стане много космато.

Може би можете да изразите мислите си и по този въпрос, тъй като го питате, предполагам, че носите някои идеи в главата си?

Какво е TDD за вас? Имате предвид, че целият ви код се упражнява от автоматични тестове по всяко време, или отивате по-далеч, като означавате, че тестовете се пишат преди кода и не се пише нов код, освен ако тестовете не успеят?

Който и подход да предпочитате, тестването на HDL код не се различава много от тестването на софтуера. Той има своите плюсове (много по-добро покритие и дълбочина на тестване) и минуси (труден за настройка и тромав спрямо софтуера).

Имам много добър опит с използването на Python и генерични HDL транзактори за прилагане на изчерпателни и автоматични тестове за синтезируеми HDL модули. Идеята е донякъде подобна на това, което Janick Bergeron представя в своите книги, но вместо SystemVerilog, Python се използва за (1) генерира VHDL код от тестови сценарии, написани на Python и (2) проверка на резултатите, написани от трансакторите за мониторинг, които приемат вълнови форми от дизайна по време на симулация.

Има много повече да се пише за тази техника, но не съм сигурен върху какво искате да се съсредоточите.