Тестирование софта - статьи

       

Разработка C-медиатора


Поскольку инструмент CTesK предназначен для разработки тестов для программных интерфейсов на языке программирования С, то из компонентов тестовой системы CTesK нельзя напрямую обращаться к 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

Заметим, что в функциях, реализующих тестовые воздействия, должна осуществляться приостановка модельного процесса тестовой системы для того, чтобы симулятор SystemC мог активизировать процесс тестируемой модели, занимающийся обработкой поданного воздействия.
В инструменте CTesK медиатор реализуется c помощью медиаторных функций, каждая из которых связывает спецификационную функцию с группой тестовых воздействий на целевую систему. Код медиаторной функции состоит из блока воздействия (блока call), в котором осуществляется тестовое воздействие, и блока синхронизации (блока state), в котором осуществляется синхронизация состояния спецификационной модели данных с состоянием целевой системы. Разработку медиатора для Verilog-модели можно осуществить автоматически по следующей схеме:

  • для каждой спецификационной функции пишется медиаторная функция следующего вида:


    • блок call≡  {apply_<воздействие>(<параметры>) ;};
    • блок 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(); } }


После того, как создан C-медиатор, разработка медиатора осуществляется по следующей схеме:

  • разрабатывается функция синхронизации состояний map_state_up, осуществляющая синхронизацию состояния спецификационной модели данных тестовой системы CTesK с состоянием экземпляра тестируемой SystemC-модели;
  • для каждой спецификационной функции пишется медиаторная функция следующего вида:
    • в блоке call осуществляется вызов соответствующей интерфейсной функции C-медиатора;
    • в блоке state осуществляется вызов функции map_state_up.

Ниже приводится медиаторная функция для спецификационной функции 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 { // вызываем соответствующую функцию C-медиатора call { count_inc_posedge(); } // вызываем функцию синхронизации состояний state { map_state_up(model); } }

Видно, что при совпадении интерфейсов C-медиатора и спецификации разработку медиатора можно автоматизировать.

Содержание раздела