Розділ 5 принципи розробки програм для тестування
Тема 5.1 Особливості моделей апаратного забезпечення
Завдання: законспектувати тему до зошита у вигляді відповідей на контрольні запитання, що містяться в кінці теми.
Моделі апаратного забезпечення такими мовами як Verilog HDL і System являють собою системи з декількох взаємодіючих модулів. Як і в мовах програмування, модулі використаються для декомпозиції складної системи на безліч незалежних або слабко зв'язаних підсистем. Кожний модуль має інтерфейс - набір входів і виходів, через які здійснюється з'єднання модуля з оточенням, і реалізацію, що визначає спосіб обробки модулем вхідних сигналів: обчислення значень вихідних сигналів і зміна внутрішнього стану.
Обробка модулем вхідних сигналів ініціюється подіями з боку оточення. Під подіями в моделях апаратного забезпечення розуміють будь-які зміни рівнів сигналів. Оскільки звичайно розглядають двійкові сигнали, виділяють два основних види подій: фронт сигналу (posedge, positive edge) — зміна рівня сигналу з низького на високий і зріз сигналу (negedge, negative edge) — зміна рівня сигналу з високого на низький.
Як правило, кожний модуль складається з декількох статично заданих паралельних процесів, кожний з яких реалізує наступний цикл: спочатку здійснюється очікування одного або декількох подій із заданого набору подій, потім їхня обробка, після чого цикл повторюється. Набір подій, очікуваних процесом для обробки, називається списком чутливості (sensitive list) процесу. Будемо називати процес пасивним, якщо він перебуває в стані очікування подій, і активним у противному випадку.
Важливою особливістю моделей апаратного забезпечення є наявність у них поняття часу: поводження таких моделей визначається не тільки послідовністю подій, але й тривалістю тимчасових інтервалів між ними. Час моделюється дискретною цілочисельною величиною, фізичний зміст одиниці часу можна задавати. Для опису причинно-наслідкових відносин між подіями, що відбуваються в одну одиницю модельного часу використається поняття дельта-затримки (delta delay). Події, між якими є дельта-затримка, виконуються послідовно одна за другою, але в ту саму одиницю модельного часу.
Для виконання моделей з метою аналізу їхнього поводження звичайно використають симуляцію по подіях (event-driven simulation). На відміну від симуляції по інтервалах часу (time-driven simulation), у якій значення сигналів і внутрішні стани модулів обчислюються через регулярні інтервали часу, у цьому способі модель розглядається тільки в ті моменти часу, коли наступають деякі події.
Робота подійного симулятора (event-driven simulator) здійснюється в такий спосіб. На початку симуляції модельний час установлюється в нуль. Далі в циклі, поки є активні процеси, вибирається один з них і виконується доти, поки цей процес не стане пасивним.
Після того, як виконані всі активні процеси, симулятор перевіряє, чи є події, заплановані через дельта-затримку на поточний момент часу. Якщо такі події є, симулятор реалізує ці події й переобчислює безліч активних процесів, після чого цикл повторюється.
Якщо, після чергового виконання циклу, подій запланованих на сучасний момент часу немає, симулятор перевіряє, чи є події, заплановані на майбутні моменти часу. Якщо таких подій немає, симуляція закінчується, у противному випадку, симулятор змінює модельний час на час найближчої події, реалізує події, заплановані на цей момент часу й переобчислює безліч активних процесів, після чого цикл повторюється.
Моделі апаратного забезпечення й технологія UniTesК
Традиційна архітектура тестової системи для тестування моделей апаратного забезпечення виглядає в такий спосіб:
Мал. 5.1 Традиційна архітектура тестової системи.
Тестовий модуль (testbench) послідовно подає на модель, що тестується, тестові впливи й здійснює перевірку правильності реакцій на них. Результатом тесту є VCD4-файл, що створюється симулятором та містить зміни значень сигналів на входах і виходах моделі в часі. Отриманий файл звичайно використається для візуалізації хвильової діаграми тесту - традиційного засобу аналізу результатів тестування.
Для кожного процесу, визначенного в моделі, класифікуємо використовувані їм входи на керуючі, інформаційні й несуттєві. Будемо називати вхід керуючим, якщо процес реагує на виникаючі на даному вході події, інформаційним, якщо значення сигналу на даному вході впливає на поводження процесу, всі інші входи будемо називати несуттєвими.
Під одиничним тестовим впливом будемо розуміти непусту несуперечливу безліч подій зі списку чутливості одного із процесів, реалізованих одночасно, а також набір значень сигналів на інформаційних входах цього процесу. Припустимо, що списки чутливості процесів, визначених у моделі, попарно не перетинаються, а керуючі входи одного процесу не є інформаційними входами іншого. При таких обмеженнях, тестовий вплив може активізувати тільки один модельний процес.
Для специфікації моделі мовою SeС, безліч всіх тестових впливів повинне бути розбите на групи, кожна з яких описується однієї специфікаційною функцією. Один з можливих підходів розбивки полягає в наступному. Кожному процесу, визначеному в моделі, ставиться у відповідність окрема специфікаційна функція, параметри якої відбивають безліч подій зі списку чутливості, реалізовані на керуючих входах, а також значення, що подаються на інформаційні входи сигналів. В передумові специфікаційної функції, крім різного роду перевірок значень, повинна здійснюватися перевірка того, що значення сигналів на керуючих входах процесу дозволяють реалізувати зазначені в параметрах події, а в постумові - те, що зазначені події дійсно були реалізовані.
Після того як визначені специфікаційні функції, тестовий сценарій розробляється звичайним для інструмента CTesК чином: за допомогою функції обчислення стану й сценарних функцій описується кінцевий автомат тесту, використовуваний для побудови послідовності тестових впливів. Відзначимо наступні моменти. Для того, щоб виконуваність передумов специфікаційних функцій визначалася тільки станом тесту, без використання більше детальної інформації про історію тестових впливів, стану тесту повинні включати поточні значення сигналів на керуючих входах. Для того, щоб граф станів кінцевого автомата був сильно зв'язний, необхідно щоб для кожної події, що використовується в тестових впливах, існував тестовий вплив зі зворотною подією, тому що в противному випадку утворяться тупикові стани тесту.
У загальному випадку, поводження моделей апаратного забезпечення визначається не тільки послідовністю тестових впливів, але й тривалістю тимчасових інтервалів між ними. Це характерно, наприклад, для моделей пристроїв з таймерами. Для якісного тестування таких моделей потрібно вміти підбирати й комбінувати тривалості тимчасових інтервалів між тестовими впливами.
Оскільки в технології UniTesК для побудови послідовностей тестових впливів використаються кінцево-автоматні моделі, природно моделювати зміну часу за допомогою спеціальних переходів. Це можуть бути як просто переходи за часом, у яких змінюється тільки модельний час, а значення вхідних сигналів залишаються незмінними, так і сполучені переходи, у яких змінюються й модельний час, і значення вхідних сигналів. З погляду специфікації, зміна модельного часу є параметром відповідного переходу специфікаційної функції. Цікаві для тестування зміни модельного часу перебираються в тестовому сценарії.
Тепер кілька слів про адаптацію тестової системи до виконання в симуляторі. Щоб тестова система могла бути виконана в симуляторі, вона повинна бути оформлена як окремий модельний процес. При цьому можливі дві різні ситуації: коли тестова система може прямо управляти виконанням цього модельного процесу (див. розділ «Тестування SystemC-моделей») і коли не може (див. розділ «Тестування Verilog-моделей»).
У першому випадку, для адаптації тестової системи практично не потрібна розробка додаткових модулів. Головне, щоб після подачі чергового тестового впливу, модельний процес, у якому виконується тестова система, припинявся, щоб симулятор міг активізувати процес моделі, що тестується, що займається обробкою поданого впливу. Припинення процесу тестової системи реалізується в медіаторних функціях.
У другому випадку, потрібно розробити спеціальний модуль симулятора, називаний оточенням моделі, що тестується та взаємодіє з тестовою системою, запущеної у вигляді окремого потоку. До функцій цього модуля відносяться прийом тестових впливів від тестової системи, їхня подача на модель, що тестується, а також передача реакцій моделі, що тестується, тестовій системі.
Приклад лічильника
Розглянемо приклад невеликого пристрою — лічильника, на Verilog- і SystemC-моделях якого ми будемо ілюструвати основні кроки розробки тестів. Інтерфейс лічильника складається із двох двійкових входів inc і rst і одного цілочисельного вихідного регістра cnt.
Мал. 5.2 Схема входів і виходів лічильника.
У відповідь на фронт сигналу inc, пристрій збільшує вміст регістра cnt на одиницю, на фронт rst — обнуляет регістр cnt. Зрізи сигналів не обробляються. Для спрощення специфікації й тестування будемо вважати, що поводження пристрою при одночасному виникненні фронтів сигналів на обох входах не визначено.
Розглянемо специфікацію лічильника мовою SeС. Специфікаційна модель даних містить у собі поточні значення вхідних сигналів inc і rst, а також вихідного регістра cnt:
// специфікаційна модель даних лічильника
typedef struct
{
bool inc; // поточне значення сигналу
// на вході inc
bool rst; // поточне значення сигналу
// на вході rst
int cnt; // поточне значення регістра cnt
} Model;
Специфікаційні функції описують поводження пристрою у відповідь на фронти й зрізи сигналів inc і rst. Нижче приводиться специфікаційна функція inc_posedge_spec, що описує реакцію на фронт сигналу на вході inc. Інші функції визначаються аналогічним чином.
// специфікація реакції на фронт сигналу на вході inc
specification void inc_posedge_spec(Model *model)
updates cnt = model->cnt,
inc = model->inc
{
pre { return model != NULL && inc == false
&& cnt < INT_MAX; }
coverage C { return {single, "Single branch"}; }
post { return inc == true && cnt == @cnt + 1; }
}
Розглянемо сценарій тестування лічильника. Як стан кінцевого автомата для нашого приклада будемо просто використати стан специфікаційної моделі, тобто поточні значення вхідних сигналів inc і rst, а також вихідного регістра cnt. У цьому випадку функція обчислення стану кінцевого автомата буде виглядати як показане нижче.
static List* scenario_state()
{
List* list = create_List(&type_Integer);
append_List(list, create_Integer(model.inc));
append_List(list, create_Integer(model.rst));
append_List(list, create_Integer(model.cnt));
return list;
}
Щоб обмежити число станів кінцевого автомата, заборонимо подачу фронту inc у станах, у яких значення регістра cnt більше або дорівнює десяти. Інші стимули (фронт rst, зрізи inc і rst) зробимо припустимими у всіх досяжних станах.
У початковому стані тесту встановлюємо низькі рівні сигналів inc і rst, а значенню регістра cnt привласнюємо нуль.
Нижче приводиться сценарна функція для фронту inc. Інші функції визначаються аналогічним образом.
scenario bool inc_posedge_scen()
{
if(model.cnt < 10)
{
if(pre_inc_posedge_spec(&model))
inc_posedge_spec(&model);
}
return true;}
Контрольні запитання:
Що представляють собою моделі апартного забезпечення мовами Verilog HDL та SystemC ?
Як виконується обробка специфікаціних подій моделлю?
В чому особливість застосування технології UniTesK ?
З чого складається традиційна архітектура тестової системи UniTesK ?
Дайте визначення тестового модулю.
Як реалізовується тестовий модуль?
Приведіть приклад застосування технології UniTesK.