Тема 5.2 Тестування Verilog-моделей
Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.
Пропонована архітектура тестової системи показана на мал. 5.3
Тестова система складається із двох потоків:
• потоку симулятора Verilog - основного потоку;
• потоку тестової системи CTesК - підлеглого потоку.
На початку симуляції за допомогою виклику спеціальної функції із симулятора Verilog в окремому потоці запускається тестова система CTesК, що у циклі надає тестові впливи на Verilog-модель, що тестується, приймає реакції на них і оцінює правильність цих реакцій.
Мал. 5.3 Пропонована архітектура тестової системи.
Verilog-оточення містить екземпляр Verilog-моделі, що тестується. Воно здійснює ініціалізацію екземпляра моделі, запускає через VPI-модуль в окремому потоці тестову систему CTesК, від якої в циклі приймає тестові впливи і якої передає реакції моделі на них. Прийом тестових впливів і передача реакцій здійснюються через VPI-медіатор.
VPI-модуль зв'язує Verilog-оточення з тестовою системою CTesК. Він реалізує функцію запуску тестової системи CTesК і містить як складена частина VPI-медіатор.
VPI-медіатор зв'язує екземпляр Verilog-моделі, що тестується, з медіатором тестової системи CTesК. Він реалізує прийом тестових впливів від тестової системи CTesК і посилку реакцій моделі на них, а також здійснює синхронізацію станів екземпляра моделі й специфікаційної моделі даних тестової системи CTesК.
При виклику $startScenario з Verilog-оточення VPI-модуль запускає в окремому потоці тестову систему CTesК (генератор, оракул, медіатор). Далі в циклі здійснюються виклики $applyAction, для прийому чергового тестового впливу, і $checkAction, для передачі реакції на нього.
Примітка. VPI (Verilog Procedural Interface) або PLI (Programming Language Interface) 2.0 — стандартний інтерфейс, призначений для виклику з Verilog-модулів функцій, написаних мовою програмування C і інших мовах програмування.
Генератор через оракул передає медіатору черговий тестовий вплив Action, що перетворить його в посилку повідомлення ApplyAction VPI-модулю й переходить у стан очікування реакції на нього WaitForCheck.
VPI-модуль при виклику $applyAction переходить у стан очікування чергового тестового впливу WaitForAction і виходить із нього при одержанні повідомлення ApplyAction від медіатора тестової системи CTesК. Після цього він викликом SetSignals змінює потрібним образом вхідні сигнали екземпляра тестируемой Verilog-моделі й передає керування Verilog-оточенню, повертаючи статус OK.
При виклику $checkAction VPI-модуль, використовуючи GetSignals, одержує значення вихідних сигналів і синхронізує стану екземпляра Verilog-моделі й специфікації тестової системи CTes. Після цього він посилає повідомлення ApplyCheck медіатору.
При прийманні повідомлення ApplyCheck медіатор виходить зі стану WaitForCheck і передає керування оракулові, що перевіряє правильність реакції екземпляра Verilog-моделі, що тестується, на тестовий вплив.
Цикл завершується при одержанні VPI-модулем у стані очікування тестового впливу WaitForAction повідомлення Finish про завершення тесту від тестової системи CTesК.
Мал. 5.4 Послідовність взаємодії основних компонентів тестової системи.
Розробка тесту
Розглядається процес розробки тесту для Verilog-моделей апаратного забезпечення за допомогою інструмента CTesК. Для ілюстрації процесу будемо використати приклад лічильника (див. попередню тему).
Процес розробки тесту складається з наступних кроків:
1. Розробка специфікації пристрою.
2. Розробка модуля взаємодії потоків.
3. Розробка медіатора.
4. Розробка тестового сценарію.
5. Розробка Verilog-оточення.
6. Розробка VPI-модуля.
Розробка модуля взаємодії потоків
Модуль взаємодії потоків реалізує функції синхронізації потоку симулятора Verilog і потоку тестової системи CTesК. Ці функції використаються медіатором і VPI-модулем, тому модуль взаємодії потоків рекомендується розробляти перед розробкою медіатора або VPI-модуля.
Модуль взаємодії потоків повинен реалізовувати наступні функції:
• wait_for_check — функція очікування реакції на тестовий вплив. Викликається в медіаторі;
• wait_for_apply — функція очікування тестового впливу. Викликається в VPI-медіаторі, повертає ідентифікатор тестового впливу;
• apply_check — функція передачі реакції на тестовий вплив. Викликається в VPI-медіаторі;
• apply_finish — функція посилки повідомлення об завершення тесту. Викликається тестовою системою CTes;
• apply_<вплив> — функції посилки тестових впливів. Викликаються в медіаторі.
Також у модулі взаємодії потоків можна визначити функції:
• start_scenario — функція запуску тестової системи CTes. Викликається в VPI-медіаторі, створює необхідні для взаємодії потоків ресурси, установлює ім'я UniTesK-траси, запускає в окремому потоці тестову систему CTesК;
• end_scenario — функція завершення роботи тестової системи CTesК. Викликається в VPI-медіаторі при одержанні повідомлення про завершення тесту, звільняє створені ресурси.
Розробка медіатора
В інструменті CTesК медіатор реалізується c допомогою медіаторних функцій, кожна з яких зв'язує специфікаційну функцію із групою тестових впливів на цільову систему. Код медіаторної функції складається із блоку впливу (блоку call), у якому здійснюється тестовий вплив, і блоку синхронізації (блоку state), у якому здійснюється синхронізація стану специфікаційної моделі даних зі станом цільової системи.
Розробку медіатора для Verilog-моделі можна здійснити автоматично за наступною схемою:
• для кожної специфікаційної функції пишеться медіаторна функція наступного виду:
o блок call ≡ {apply_<вплив>(<параметри>);};
o блок state ≡ {wait_for_check();}.
Медіаторна функція для специфікаційної функції inc_posedge_spec буде виглядати в такий спосіб:
// медіаторна функція для inc_posedge_spec
mediator inc_posedge_media for
specification void inc_posedge_spec(Model *model)
updates cnt = model->cnt,
inc = model->inc
{
// посилаємо тестовий вплив
call { apply_inc_posedge(model); }
// очікуємо реакції
state { wait_for_check(); }
}
Розробка Verilog-оточення
Verilog-оточення являє собою модуль верхнього рівня мовою Verilog HDL і розробляється за наступною схемою:
• для кожного входу Verilog-моделі, що тестується, всередині Verilog-оточення визначається однотипний регістр;
• визначається екземпляр Verilog-моделі, що тестується, target, як аргументи якого виступають визначені раніше регістрами;
• визначається блок initial, всередині якого:
o встановлюється ім'я VCD-файлу й сигнали, що в нього трасуються;
o викликається системне завдання $startScenario, що запускає тестову систему CTesК;
o у циклі за допомогою системної функції $applyAction приймаються тестові впливи від тестової системи CTes і за допомогою системного завдання $checkAction посилають реакції на них.
Verilog-оточення використає системні завдання $startScenario, $checkAction і системну функцію $applyAction, які повинні бути реалізовані в VPI-модулі. Видно, що розробку Verilog-оточення можна повністю автоматизувати.
Розробка VPI-модуля
VPI-модуль розробляється мовою програмування C з використанням інтерфейсу VPI. Він повинен реалізовувати наступні системні функції й завдання:
• $startScenario — викликає функцію start_scenario модуля взаємодії потоків;
• $applyAction — викликає функцію wait_for_action модуля взаємодії потоків і залежно від значення, що повертає, робить необхідні зміни вхідних сигналів Verilog-моделі, що тестується;
• $checkAction — здійснює синхронізацію станів екземпляра Verilog-моделі й специфікації тестової системи CTes, після цього викликає функцію apply_check модуля взаємодії потоків;
Системна функція $applyAction і системне завдання $checkAction утворять VPI-медіатор. Розробку частини VPI-модуля, пов'язану із запуском тестової системи CTesК, можна повністю автоматизувати.
Нижче приводиться зведена таблиця розроблювальних модулів, у якій зазначені потік виконання модуля, язик розробки й можливість автоматизації розробки.
У таблиці показано, що розробку модуля взаємодії потоків, медіатора й Verilog-оточення можна автоматизувати повністю, розробку VPI-модуля - частково.
Тестування SystemC-моделей
Тестова система CTesК виконується в симуляторі System, вона подає на SystemC-модель, що тестується, тестові впливи, приймає реакції на них і оцінює правильність цих реакцій. Взаємодія тестової системи CTesК і SystemC-моделі, що тестується, здійснюється через C-медіатор.
C-медіатор являє собою реалізацію програмного інтерфейсу мовою програмування C, призначеного для доступу до екземпляра SystemC-моделі, що тестується. C-медіатор використається медіатором тестової системи CTesК для подачі тестових впливів і прийому реакцій.
Модуль запуску тестової системи призначений для запуску тестової системи CTesК в симуляторі System.
Розробка тесту
Розглянемо процес розробки тесту для SystemC-моделей апаратного забезпечення за допомогою інструмента CTesК. Для ілюстрації процесу будемо використати приклад лічильника.
Процес розробки тесту складається з наступних кроків:
1. Розробка C-медіатора.
2. Розробка специфікації системи.
3. Розробка медіатора.
4. Розробка тестового сценарію.
5. Розробка модуля запуску тестової системи.
Розробка C-медіатора
Оскільки інструмент CTesК призначений для розробки тестів для програмних інтерфейсів мовою програмування С, то з компонентів тестової системи CTesК не можна прямо звертатися до SystemC-моделі. Всі звертання до моделі, що тестується, повинні здійснюватися через спеціально розроблений С-медіатор, що надає інтерфейс для подачі тестових впливів і одержання реакцій моделі на них.
Нижче приводиться інтерфейс С-медіатора для SystemC-моделі лічильника.
#ifdef __cplusplus
extern "C" {
#endif // #ifdef __cplusplus
// интерфейсные функції, що здійснюють
// тестові впливи
// на екземпляр SystemC-моделі лічильника
void count_inc_posedge(void);
void count_rst_posedge(void);
void count_inc_negedge(void);
void count_rst_negedge(void);
// интерфейсные функції, що одержують інформацію
// про стан екземпляра SystemC-моделі лічильника
int count_inc(void);
int count_rst(void);
int count_cnt(void);
#ifdef __cplusplus
} #endif // #ifdef __cplusplus
У функціях, що реалізують тестові впливи, повинно здійснюватися припинення модельного процесу тестової системи для того, щоб симулятор System міг активізувати процес тестування моделі, що займається обробкою поданого впливу.
Розробка медіатора
Після того, як створений C-медіатор, розробка медіатора здійснюється за наступною схемою:
• розробляється функція синхронізації станів map_state_up, що здійснює синхронізацію стану спецификационной моделі даних тестової системи CTesК зі станом екземпляра SystemC-моделі, що тестується;
• для кожної специфікаційної функції пишеться медіаторна функція наступного виду:
o у блоці call здійснюється виклик відповідної интерфейсной функції C-медіатора;
o у блоці state здійснюється виклик функції map_state_up.
Розробка модуля запуску тестової системи
Розробка модуля запуску тестової системи здійснюється за наступною схемою:
• розробляється функцію запуску тестової системи CTesК;
• розробляється SystemC-модуль для виклику тестової системи CTes в окремому модельному процесі.
Нижче приводиться функція count_start, що запускає тестовий сценарій count_scenario.
// функція запуску тестового сценарію
void count_start(const char *trace)
{
addTraceToFile(trace);
count_scenario(0, NULL);
}
Нижче приводиться SystemC-модуль для виклику тестової системи CTesК в окремому модельному процесі.
// модуль запуску тестової системи
SC_MODULE(count_testbench)
{ public:
// визначаємо окремий модельний процес
SC_CTOR(count_testbench) { SC_THREAD(main); }
// метод запуску тесту
void start(void) { sc_start(); }
// процес тестової системи CTes
void main(void)
{ count_start("simulation.unitrace"); } };
Видно, що розробку модуля запуску тестової системи можна повністю автоматизувати.
Можливість автоматизації кроків розробки
Нижче приводиться зведена таблиця розроблювальних модулів, у якій зазначені мова розробки модуля й можливість автоматизації його розробки.
У таблиці показано, що розробку медіатора й модуля запуску тестової системи можна автоматизувати повністю.
Контрольні запитання:
З яких компонентів складається архітектура тестової системи?
Як відбувається взаємодія між компонентами архітектури тестової системи?
Як відбувається розробка тестів?
Як розробити модуль взаємодії потоків?
Дайте поняття розробки медіатора.
Розкажіть про розробку Verilog – оточення.
Які особливості розробки тестової системи для SystemC-моделей?