Проверка на FPGA. Какво е това? 6

• 15.07.15 12:53 •
• x0n •
• • # 262693
• • Habrahabr
• 15 •
• 4448

- като Forbes, само по-добре.

По волята на съдбата, което правя за няколко години проверка на FPGA конфигурации. И от самото начало бях поразен от липсата на достатъчно информация по този въпрос.

Ако не всички, много хора тук не са чували за FPGA. Може би някои от тях дори работеше в тясно сътрудничество с тях, но мисля, че с проекти за проверка FPGA пред които са изправени много по-малко хора. Днес ще говорим за процеса на проверка.

Функционална проверка на FPGA - е процес на намиране и коригирането на грешки в конфигурацията на FPGA (фърмуера). Кажете защо проверката е така, защото на етапа на отстраняване на грешки FPGA "желязо" всичко може да бъде поправена. Възможно е, но много трудно.

Първо в "железни" грешки функция за търсене по-скоро труден и продължителен процес. Това води до забавяне при приключване на проекта. За доста сериозен отстраняване на грешки на проекта може да отнеме седмици или месеци. Проверката също така ви позволява да откриете и отстраните повечето от функционални грешки на етапа на модела.

Вие казвате, че опитен разработчик на FPGA не правят грешки или да ги направи много малко? Прави! И доста.

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

Проверката може да бъде разделена на следните етапи:

1. TK развитие;
2. Разработване на план за проверка;
3. ТОГАВА развитие;
4. тестване;

1. Разработване на задание за проверка

Както е добре известно - звук подход към развитието на TK се отървава от много проблеми през целия проект. Задание за проверка трябва да описва пълен и изчерпателен набор от функции и възможности да блокират да бъдат проверени. В идеалния случай задание за проверка, трябва да пиша проверка екип, ръководен група. Това е изключително важно, особено за малка опит на проверяващия, който ще се занимава с тестване. Съставът на техническото задание трябва да включва следните елементи:
• списък на всички блокове, които ще бъдат част от проекта и работата, която трябва да бъде проверена;
• списък на всички режими на работа, функции, характеристики на дизайна, които трябва да бъдат проверени;
• прехвърляне на функции и ДА клас, която е да се използва повторно в други проекти (например набор от функции за изчисляване на контролни суми или да работят с комуникационни интерфейси).

Естествено, задания трябва да започнат след получаване на цялата необходима информация за този проект.

2. Разработване на плана за верификация

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

План за проверка включва набор от тестове с подробно описание.

проверка план главен документ за отбор проверка FPGA. Всяка по-нататъшна работа ще се основава на този документ. Всички "zabugornye чудовища" системи в Synopsys и Cadence чип препоръчваме да се започне с плана за проверка преди това развитие. В действителност план проверка е по-подробна спецификация за проверка.

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

3. ЧЕ развитие

Ние трябва да помним, че развитието на FPGA конфигурация и развитие след това трябва да започне и да вървят паралелно. Тази процедура е оптимален по отношение на минималното време за разработване на проекти, тъй като процеса на проверка отнема повече от 70% от развитието време на проекта.

Въз основа на информацията от предишните стъпки, можете да създадете тестова среда (към). Прието е да се напише един език за програмиране, създаден специално за целите на проверка, тъй като те разполагат с всички необходими инструменти, за да го направят. Система Verilog е един от най-подходящите езици. Този език е доста сходен с C ++ с капсулиране, полиморфизъм, и наследяване.

При разработването на тестовата среда изисква силно препоръчително да не се забравя "reyuzabelnosti". Ако няма подходящи функции, напишете ги в светлината на евентуална бъдеща употреба. Ако има функция, а след това да я използват. Необходимо е да се организира нещо, така че всеки тест може да бъде променяна без възможност за увреждане на други тестове. Това ще предотврати проблеми в бъдеще, тъй като в хода на изпитванията, все още трябва да се въведат някои промени в кода е.

4. Тестване

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

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

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

Вие можете да помогнете и превежда няколко средства за развитие на сайта

И от самото начало бях поразен от липсата на достатъчно информация по този въпрос.
Не съм съгласен.

FPGA Firmware е софтуер (въпреки че може да се спори, но в този контекст сравнението е уместно), поради което неговата проверка е подобна проверка на друг софтуер. Тестване на софтуера е достатъчно на брой статии, книги и други методологии.

Въпреки това, на фърмуера е "необичайно" програма, и тя има нюансите на това как да го тестваме. И тук ние сме помогнали с книги като «SystemVerilog за проверка» и «Писане testbenches използващи SystemVerilog», както и сайтове като testbench.in, и на такива методики за проверка, като UVM, които изостриха от RTL.

Така че, по мое мнение, че информацията е в мрежата е :)

Струва ми се, полезен за обществото ще покаже своята Testbench (или част от него), като каза, че това как и защо го правите, защото реалния живот в голям сериозен проект е често в противоречие с съвети от книги и статии в Интернет)

Тук е моят Bobble. В съзнанието ми е било писано "информация на руски," а просто "информация" е написана. Разбира се в английската литература, обаче, липсва в сравнение с литература за тестване на "нормално" софтуер, информацията е много малко.

Първо ви цитирам определение:
Функционална проверка на FPGA - е процес на намиране и коригирането на грешки
И след това:
защото в процеса на проверка и отстраняване на проблеми
Нито едното, нито другото не е вярно.
Проверка - тя не се намери и да се елиминират грешките и доказателства за съответствие с функционирането на продукта в съответствие с техническото задание.

Проверка - потвърждение на съответствието на крайния продукт предварително зададени референтни стандарти. С прости думи - ние сме създали правилно даден продукт, както се изисква.
качеството на продукта, предмет на разглеждане.

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

защото в процеса на проверка и отстраняване на проблеми
Аз го коригира.
Функционална проверка на FPGA - е процес на намиране и коригирането на грешки
Тук бих искал да опише определението по-ясни думи, изрази същността.

Проверка - тя не се намери и да се елиминират грешките и доказателства за съответствие с функционирането на продукта в съответствие с техническото задание.
Тук думата "доказателство" е неподходяща, по мое мнение. Това означава, че аз като верификатор, предвид на продукта, и аз трябва да докаже, че продуктът работи правилно? Това няма да се правят. Проверяващият трябва да се провери, че TK продукт, ако продуктът не отговаря, тогава кажете на някой, който е правилен.

И от самото начало бях поразен от липсата на достатъчно информация по този въпрос.
Не съм съгласен.

FPGA Firmware е софтуер (въпреки че може да се спори, но в този контекст сравнението е уместно), поради което неговата проверка е подобна проверка на друг софтуер. Тестване на софтуера е достатъчно на брой статии, книги и други методологии.

Въпреки това, на фърмуера е "необичайно" програма, и тя има нюансите на това как да го тестваме. И тук ние сме помогнали с книги като «SystemVerilog за проверка» и «Писане testbenches използващи SystemVerilog», както и сайтове като testbench.in, и на такива методики за проверка, като UVM, които изостриха от RTL.

Така че, по мое мнение, че информацията е в мрежата е :)

Струва ми се, полезен за обществото ще покаже своята Testbench (или част от него), като каза, че това как и защо го правите, защото реалния живот в голям сериозен проект е често в противоречие с съвети от книги и статии в Интернет)

Тук е моят Bobble. В съзнанието ми е било писано "информация на руски," а просто "информация" е написана. Разбира се в английската литература, обаче, липсва в сравнение с литература за тестване на "нормално" софтуер, информацията е много малко.

Първо ви цитирам определение:
Функционална проверка на FPGA - е процес на намиране и коригирането на грешки
И след това:
защото в процеса на проверка и отстраняване на проблеми
Нито едното, нито другото не е вярно.
Проверка - тя не се намери и да се елиминират грешките и доказателства за съответствие с функционирането на продукта в съответствие с техническото задание.

Проверка - потвърждение на съответствието на крайния продукт предварително зададени референтни стандарти. С прости думи - ние сме създали правилно даден продукт, както се изисква.
качеството на продукта, предмет на разглеждане.

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

защото в процеса на проверка и отстраняване на проблеми
Аз го коригира.
Функционална проверка на FPGA - е процес на намиране и коригирането на грешки
Тук бих искал да опише определението по-ясни думи, изрази същността.

Проверка - тя не се намери и да се елиминират грешките и доказателства за съответствие с функционирането на продукта в съответствие с техническото задание.
Тук думата "доказателство" е неподходяща, по мое мнение. Това означава, че аз като верификатор, предвид на продукта, и аз трябва да докаже, че продуктът работи правилно? Това няма да се правят. Проверяващият трябва да се провери, че TK продукт, ако продуктът не отговаря, тогава кажете на някой, който е правилен.