Разработка и тестирование целочисленного сумматора с AXI-Stream интерфейсами Часть 4

Автор: https://github.com/VSHEV92

Исходные коды:
https://github.com/pcbproj/AXI-Stream-Adder/tree/axis-adder-v1
https://github.com/pcbproj/AXI-Stream-Adder/tree/axis-adder-v2

Оглавление

• Введение

• Тестовое окружение для проверки сумматора

• Настройки тестового окружения

• Вспомогательные функции

• Сигналы тестового окружения

• Драйверы и мониторы AXI-Stream интерфейсов

• Описание Scoreboard

• Остальные компоненты окружения

• Примеры использования окружения

• Заключение

Введение

В предыдущей части был рассмотрен основной подход, применяемым для тестирования сложных цифровых устройств — constraint random testing. Мы узнали, как автоматизировать проверку корректности работы устройства с помощью сравнения его выходов с эталонной моделью. Тестовые окружения, работающие по такому принципу, называются self-test testbench. Мы увидели из каких компонентов строятся тестовые окружения и разработали структуру окружения для проверки сумматора с AXI-Stream интерфейсами. В этой статье мы перейдем от теории к практике и покажем, как реализовать это окружение на языке Verilog.

Тестовое окружение для проверки сумматора

Напомним структуру тестового окружения, которое мы хотим описать.

Окружение состоит из трех драйверов, два из которых выступают в роли передатчиков, а один — приемника. Задача передатчиков заключается в формировании случайных слагаемых и отправки их сумматору в соответствии с правилами AXI-Stream интерфейса. Эти два драйвера будут управлять сигналами tdata и tvalid входных интерфейсов сумматора. Драйвер-приемник должен управлять сигналом tready для выходного AXI-Stream интерфейса сумматора. Задержки на интерфейсах будут случайными в пределах настраиваемого диапазона.

Также окружение содержит три монитора, по одному на каждый AXI-Stream интерфейс. Мониторы будут непрерывно анализировать сигналы tvalid и tready и при обнаружении handshake отправлять данные на шине tdata в scoreboard.

В свою очередь scoreboard будет получать транзакции от мониторов и принимать решение о корректности выполнения суммирования. Входные слагаемые будут временно сохраняться в массивы с помощью коллекторов. После получения транзакции от выходного монитора scoreboard будет считывать слагаемые из массивов, передавать их в эталонную модель и далее отправлять эталонный результат в checker. Checker получает результаты от эталонной модели и тестируемого сумматора и выполняет их сравнение. В случае несовпадения выводится сообщение об ошибке.

Также мы будем использовать сторожевой таймер (watchdog), чтобы иметь возможность завершить тест при зависании проверяемого устройства или одного из компонентов окружения.

Перейдем, наконец, к практической части и начнем поэтапно реализовывать наше тестовое окружение на языке Verilog.

Настройки тестового окружения

Для удобства описания тестового окружения выделим некоторые его части в виде отдельных файлов. Окружение будет запускать один случайный тест, который можно будет конфигурировать с помощью различных настроек. Ниже представлено содержимое файла tb_defines.vh, который содержит все параметры теста.

`ifndef TB_DEFINES_VH `define TB_DEFINES_VH  // разрядность шины входных слагаемых `ifndef WIDTH   `define WIDTH 4 `endif  // ширина входных и выходных шин AXI-Stream интерфейса `define AXIS_IN_WIDTH $ceil($itor(`WIDTH)/8)*8 `define AXIS_OUT_WIDTH $ceil($itor(`WIDTH+1)/8)*8  // число транзакций в тесте `ifndef TRANS_NUMBER   `define TRANS_NUMBER 5 `endif  // начальное состояние генератора случайных чисел `ifndef SEED   `define SEED 0 `endif  // минимальная задержка в тактах на AXI-Stream интерфейсе `ifndef MIN_AXIS_DELAY   `define MIN_AXIS_DELAY 0 `endif  // максимальная задержка в тактах на AXI-Stream интерфейсе `ifndef MAX_AXIS_DELAY   `define MAX_AXIS_DELAY 10 `endif  // максимальное значение, генерируемое драйвером AXI-Stream интерфейса `ifndef MAX_AXIS_VALUE   `define MAX_AXIS_VALUE 2**`WIDTH - 1 `endif  // максимальная длительность теста в тактах `ifndef MAX_CLK_IN_TEST   `define MAX_CLK_IN_TEST 300 `endif  `endif 

Разберем назначение каждого параметра:

• WIDTH — разрядность входных слагаемых;

• AXIS_IN_WIDTH — разрядность шины tdata для входных слагаемых;

• AXIS_OUT_WIDTH — разрядность шины tdata для результата суммирования;

• TRANS_NUMBER — число суммирований, которое будет выполнено в тесте. Используется для завершения теста;

• SEED — параметр, задающий начальное состояние генераторов случайных чисел. Изменяя это значение, можно формировать разные последовательности случайных воздействий;

• MIN_AXIS_DELAY — минимальная задержка в тактах перед установкой сигналов tvalid или tready в AXI-Stream интерфейсе;

• MAX_AXIS_DELAY — максимальная задержка в тактах перед установкой сигналов tvalid или tready в AXI-Stream интерфейсе;

• MAX_AXIS_VALUE — максимальное значение, которое может появится на шине tdata. Используется для ограничения значений для входных слагаемых. По умолчанию определяется, исходя из значения WIDTH;

• MAX_CLK_IN_TEST — максимальная длительность теста в тактах. Используется для настройки watchdog.

Отметим, что почти все настройки объявлены внутри конструкции ifndef ... endif. Это сделано для того, чтобы при запуске теста их значения можно было переопределять. Например, если в качестве симулятора используется Icarus Verilog, то добавив в команду запуска конструкцию -D TRANS_NUMBER=15, мы получим тест, который завершится после выполнения 15 суммирований. Если при запуске теста значение для какого-либо параметра не задано, то будет использовано значение по умолчанию, определенное в файле tb_defines.vh. Например, для числа суммирований TRANS_NUMBER значение по умолчанию равно 5. Исключением являются параметры AXIS_IN_WIDTH и AXIS_OUT_WIDTH, которые напрямую зависят от значения WIDTH и не задаются вручную.

В начале файла также присутствуют следующие две строки:

`ifndef TB_DEFINES_VH `define TB_DEFINES_VH 

Это известная в программировании конструкция, которая называется include guard. Она служит для защиты от ошибок множественного определения при многократном выполнении директивы include для одного и того же файла.

Вспомогательные функции

Создадим файл с именем tb_tasks.vh, в котором объявим некоторые вспомогательные процедуры. Файл будет начинаться с include guard и включать в себя настройки теста из tb_defines.vh.

`ifndef TB_TASKS_VH `define TB_TASKS_VH  `include "tb_defines.vh" 

С помощью отдельной процедуры gold_adder опишем эталонную модель сумматора. Модель будет принимать входные слагаемые data1_i и data2_i и вычислять результат суммирования data_o. Ширина шина tdata из-за требований AXI-Stream интерфейса (кратность восьми битам) может превышать значение WIDTH, поэтому перед вычислением суммы выделяем из слагаемых младшие WIDTH бит:

// эталонный сумматор task gold_adder(input integer data1_i, input integer data2_i, output integer data_o);   integer in_1, in_2;   begin     in_1 = data1_i[`WIDTH-1:0];     in_2 = data2_i[`WIDTH-1:0];     data_o = in_1 + in_2;   end endtask 

Также в виде отдельной процедуры с именем compare реализуем checker. Процедура принимает входные слагаемые data1_i и data2_i от коллекторов, пропускает их через модель gold_adder и получает эталонный результат gold_out. Далее этот эталон сравнивается с выходом сумматора data_o. Если значения не совпадают, то выводится сообщение об ошибке. Также на вход процедуры поступает однобитный сигнал error_flag, который служит индикатором наличия ошибок в процессе работы теста. Если checker обнаруживает несовпадение данных, то сигнал error_flag устанавливается в единицу и остается в этом состоянии до конца теста.

// сравнение с эталонной моделью task compare(input integer data1_i, input integer data2_i, input integer data_o, inout reg error_flag);   integer gold_out, dut_out;   begin     gold_adder(data1_i, data2_i, gold_out);     dut_out = data_o[`WIDTH:0];     // вывод на экран и установка флага ошибки     if (gold_out != dut_out) begin       $display("ERROR! Data mismatch! input 1: %0d, input 2: %0d, output: %0d, gold: %0d, time: %0t", data1_i, data2_i, dut_out, gold_out, $time);       error_flag = 1'b1;     end   end endtask 

Последняя процедура check_finish отвечает за завершение теста и вывод отчета о его результатах. На вход поступает число выполненных суммирований trans_cnt, запланированное число суммирований trans_number и сигнал наличия ошибок error_flag. Если число выполненных суммирований совпадает с числом запланированных (trans_cnt == trans_number), то тест завершается с помощью функции $finish. Перед этим проверяется значение сигнала error_flag. Если оно равно единице, то это означает, что во время выполнения теста были обнаружены ошибки, поэтому выводится сообщение TEST FAILED!. Иначе выводится сообщение TEST PASSED!.

// проверка числа обработанных сложений и завершение теста task check_finish(input integer trans_cnt, input integer trans_number, input reg error_flag);   begin     if (trans_cnt == trans_number) begin       if (error_flag) begin         $display("----------------------");         $display("---- TEST FAILED! ----");         $display("----------------------");       end else begin         $display("----------------------");         $display("---- TEST PASSED! ----");         $display("----------------------");       end       $finish;     end   end endtask 

Сигналы тестового окружения

Разобравшись со вспомогательными файлами, начнем описывать основные части тестового окружения. Для начала включим в окружение вспомогательные файлы:

module adder_axis_tb ();    `include "tb_defines.vh"   `include "tb_tasks.vh" 

Далее объявим входные и выходные сигналы сумматора:

  // тактовый сигнал и сигнал сброса   reg aclk = 1'b0;   reg aresetn = 1'b0;    // сигналы для AXI-Stream интерфейсов   reg  data1_i_tvalid, data2_i_tvalid, data_o_tready;   wire data1_i_tready, data2_i_tready, data_o_tvalid;    // слагаемые и результат суммы   reg  [ `AXIS_IN_WIDTH-1:0]  data1_i_tdata;   reg  [ `AXIS_IN_WIDTH-1:0]  data2_i_tdata;   wire [ `AXIS_OUT_WIDTH-1:0] data_o_tdata; 

Объявим массивы, в которые коллекторы будут складывать входные слагаемые. Длина массивов определяется через запланированное число суммирований (TRANS_NUMBER):

  // массивы для сохранения входных слагаемых   reg [`WIDTH-1:0] axis_data1 [0:`TRANS_NUMBER];   reg [`WIDTH-1:0] axis_data2 [0:`TRANS_NUMBER]; 

Создадим несколько счетчиков. Сигналы axis_data1_cnt и axis_data2_cnt подсчитывают число входных слагаемых и используются для индексирования в массивах коллекторов. Счетчик числа суммирований trans_cnt передается в scoreboard для проверки условия завершения теста.

  // счетчики числа слагаемых и результатов суммы   integer unsigned axis_data1_cnt = 0;   integer unsigned axis_data2_cnt = 0;   integer unsigned trans_cnt = 0; 

Отдельно объявим переменную seed для задания начального состояния генераторов случайных чисел. Функция $urandom() требует в качестве аргумента целочисленную переменную. Мы не можем в $urandom() напрямую передавать константу «SEEDиз файла **tb_defines.vh**. Для этих целей будет использоваться переменнаяseed`.

  // начальное состояние генератора случайных чисел   integer seed = `SEED; 

В Verilog все блоки initial и always, а также непрерывные присваивания assign, выполняются одновременно и параллельно друг относительно друга. Для обеспечения cинхронизации этих процессов в Verilog используются события (events). В нашем окружении с помощью events будет координироваться совместная работа мониторов и scoreboard:

  // события handshake на AXI-Stream интерфейсах   event data1_i_e, data2_i_e, data_o_e; 

Объявим однобитный сигнал, указывающий на появление ошибок в процессе выполнения теста, и инициализируем его нулевым значением:

  // флаг наличия ошибок в тесте   reg error_flag = 1'b0; 

Наконец, добавим в окружение наш сумматор и подключим к его портам все необходимые сигналы:

// проверяемый модуль   adder_axis_pipe #(       .ADDER_WIDTH(`WIDTH)   ) dut (       .aclk          (aclk),       .aresetn       (aresetn),       .data1_i_tdata (data1_i_tdata),       .data1_i_tvalid(data1_i_tvalid),       .data1_i_tready(data1_i_tready),       .data2_i_tdata (data2_i_tdata),       .data2_i_tvalid(data2_i_tvalid),       .data2_i_tready(data2_i_tready),       .data_o_tdata  (data_o_tdata),       .data_o_tvalid (data_o_tvalid),       .data_o_tready (data_o_tready)   ); 

Драйверы и мониторы AXI-Stream интерфейсов

Для начала рассмотрим реализацию драйверов для входных интерфейсов сумматора. В нашем окружении должно быть два драйвера, которые выступают в роли передатчиков. Их задача заключается в создании входных слагаемых и отправки их сумматору. Каждый драйвер должен формировать данные для шины tdata и управлять сигналом валидности tvalid. Чтобы обнаружить момент возникновения handshake, драйвер должен следить за сигналом tready.

Ниже представлено описание драйвера для первого входного интерфейса сумматора:

  // драйвер для data1_i AXI-Stream интерфейса   initial begin     // ожидаем выхода из состояния сброса     @(posedge aresetn);        while (1) begin       data1_i_tvalid <= 1'b0;       // выполняем задержку на случайное число тактов       repeat ($urandom(seed) % (`MAX_AXIS_DELAY + 1) + `MIN_AXIS_DELAY) @(posedge aclk);       // выставляем сигнал tvalid и данные       data1_i_tdata  <= $urandom(seed) % (`MAX_AXIS_VALUE + 1);       data1_i_tvalid <= 1'b1;       @(posedge aclk);       // ожидаем сигнал tready для handshake       while (!data1_i_tready) @(posedge aclk);     end   end 

Драйвер реализован внутри блока initial. В начале теста сумматор будет находиться в состоянии сброса. Перед тем, как подавать на него транзакции, мы ожидаем установки сигнала сброса в неактивный единичный уровень (@(posedge aresetn)). Далее драйвер в бесконечном цикле (while (1)) начинает формировать случайные слагаемые и отправлять их сумматору.

В начале драйвер не имеет транзакций для сумматора, поэтому сигнал валидности data1_i_tvalid устанавливается в нулевое значение. С помощью функции $urandom() мы получаем целое число в диапазоне от MIN_AXIS_DELAY до MAX_AXIS_DELAY и используем его для формирования случайной задержки. Для этих целей мы используем цикл repeat, внутри которого ожидаем заданное число фронтов тактового сигнала @(posedge aclk).

После этого мы генерируем случайные данные data1_i_tdata, выставляем сигнал валидности data1_i_tvalid в единичное значение и ждем появления фронта сигнала aclk. Если сигнал готовности data1_i_tready равен единице, то это значит, что на шине произошел handshake. Сумматор получил транзакцию и мы можем повторить весь цикл заново. Иначе с помощью цикла while на каждом такте @(posedge aclk) мы проверяем, произошел ли handshake. Цикл while выполняется до тех пор, пока сигнал data1_i_tready не примет единичное значение.

Драйвер для второго входного интерфейса имеет тот же вид, за исключением того, что теперь мы используем сигналы data2_i_tdata, data2_i_tvalid и data2_i_tready. Его описание представлено ниже:

  // драйвер для data2_i AXI-Stream интерфейса   initial begin     // ожидаем выхода из состояния сброса     @(posedge aresetn);      while (1) begin       data2_i_tvalid <= 1'b0;       // выполняем задержку на случайное число тактов       repeat ($urandom(seed) % (`MAX_AXIS_DELAY + 1) + `MIN_AXIS_DELAY) @(posedge aclk);       // выставляем сигнал tvalid и данные       data2_i_tdata  <= $urandom(seed) % (`MAX_AXIS_VALUE + 1);       data2_i_tvalid <= 1'b1;       @(posedge aclk);       // ожидаем сигнал tready для handshake       while (!data2_i_tready) @(posedge aclk);     end   end 

Теперь рассмотрим, как устроен драйвер для выходного интерфейса сумматора. В этом случае драйвер выступает в качестве приемника данных, и его задача заключается в управлении сигналом tready. В соответствии с правилами AXI-Stream интерфейса сигнал tready не должен зависеть от сигнала tvalid и может изменять свое значение на каждом такте сигнала aclk.

Описание драйвера для выходного интерфейса сумматора представлено ниже:

  // драйвер для data_o AXI-Stream интерфейса   initial begin     // ожидаем выхода из состояния сброса     @(posedge aresetn);          while (1) begin       // сбрасываем сигнал tready       data_o_tready <= 1'b0;       // выполняем задержку на случайное число тактов       repeat($urandom(seed) % (`MAX_AXIS_DELAY + 1) + `MIN_AXIS_DELAY)         @(posedge aclk);       // выставляем сигнал tready       data_o_tready <= 1'b1;       @(posedge aclk);       // опять выполняем задержку на случайное число тактов       repeat($urandom(seed) % (`MAX_AXIS_DELAY + 1) + `MIN_AXIS_DELAY)         @(posedge aclk);     end   end 

Мы ждем выхода из состояния сброса (@(posedge aresetn)), после чего в бесконечном цикле (while (1)) на каждом такте формируем значение сигнала data_o_tready. Сначала задаем нулевое значение и с помощью функции $urandom() и цикла repeat удерживаем сигнал data_o_tready в этом состоянии в течение случайного числа тактов. Далее присваиваем единичное значение и опять выполняем задержку на случайное число тактов. После этого цикл повторяется.

Разобравшись с драйверами, перейдем к описанию мониторов. Монитор должен наблюдать за сигналами интерфейса и определять моменты времени, когда происходит handshake. Для этого на каждом такте отслеживаются значения сигналов tvalid и tready. Handshake наступает, когда оба сигнала равны единице. Описание всех мониторов представлено ниже:

  // монитор для data1_i AXI-Stream интерфейса   always begin     @(posedge aclk);     if (data1_i_tready && data1_i_tvalid) -> data1_i_e;   end    // монитор для data2_i AXI-Stream интерфейса   always begin     @(posedge aclk);     if (data2_i_tready && data2_i_tvalid) -> data2_i_e;   end      // монитор для data_o AXI-Stream интерфейса   always begin     @(posedge aclk);     if (data_o_tready && data_o_tvalid) -> data_o_e;   end 

Для примера, рассмотрим, монитор для выходного интерфейса. Внутри блока always на каждом такте (@(posedge aclk)) проверяется условие, что сигналы data_o_tready и data_o_tvalid принимают единичное значение. При его выполнении с помощью оператора -> запускается событие data_o_e. Так монитор сообщает scoreboard о появлении транзакции на выходном AXI-Stream интерфейсе сумматора.

Описание Scoreboard

Теперь рассмотрим реализацию самого крупного компонента окружения — scoreboard. Он состоит из нескольких частей: коллекторы, эталонная модель и checker. Описание коллектора для слагаемых на первом входном интерфейсе сумматора показано ниже:

  always begin       @(data1_i_e);       axis_data1[axis_data1_cnt] = data1_i_tdata;       axis_data1_cnt = axis_data1_cnt + 1;   end 

В блоке always мы ожидаем срабатывания event (@(data1_i_e)). Его появление означает, что в текущий момент времени на интерфейсе происходит handshake. Поэтому мы берем значение на шине data1_i_tdata и сохраняем его в массив коллектора axis_data1. После этого мы увеличиваем счетчик полученных слагаемых (axis_data2_cnt) на единицу и ждем следующего срабатывания события data1_i_e.

Коллектор для второго входного интерфейса работает таким же образом:

  always begin       @(data2_i_e);       axis_data2[axis_data2_cnt] = data2_i_tdata;       axis_data2_cnt = axis_data2_cnt + 1;   end 

Оставшаяся часть scoreboard, состоящая из эталонной модели и checker, реализуется с помощью еще одного блока always:

  always begin       @(data_o_e);       compare(axis_data1[trans_cnt], axis_data2[trans_cnt], data_o_tdata, error_flag);       trans_cnt = trans_cnt + 1;       check_finish(trans_cnt, `TRANS_NUMBER, error_flag);   end 

Мы ожидаем событие data_o_e, срабатывание которого указывает на появление транзакции на выходном AXI-Stream интерфейсе. Это в свою очередь означает, что ранее уже были получены входные слагаемые, которые сейчас находятся в массивах коллекторов.

Далее мы вызываем процедуру compare, в которую передаем слагаемые из коллекторов axis_data1[trans_cnt] и axis_data2[trans_cnt], результат сложения на выходе сумматора (data_o_tdata) и сигнал наличия ошибок error_flag. Эта процедура вызывает эталонную модель и выполняет сравнение. В случае несовпадения результатов выводится сообщение об ошибке и значение сигнала error_flag устанавливается в единицу. После этого мы увеличиваем счетчик выполненных суммирований (trans_cnt) и проверяем, можно ли завершить тест. Когда число выполненных суммирований trans_cnt станет равным TRANS_NUMBER, тест завершается и выводится отчет о его выполнении. Если сигнал error_flag равен нулю, то тест пройден успешно, если единице — то нет.

Остальные компоненты окружения

Для завершения описания окружения нам необходимо добавить еще несколько компонентов. С помощью блоков always и initial сформируем тактовый сигнал и сигнал сброса:

  // создание тактового сигнала   always #5 aclk = ~aclk;    // создание сигнала сброса   initial begin     repeat (10) @(posedge aclk);     aresetn <= 1'b1;   end 

Включим в окружение сторожевой таймер. Для этого в блоке initial с помощью цикла repeat будем ожидать появления заданного числа фронтов тактового сигнала (@(posedge aclk)). Если моделирование выполняется уже на протяжении MAX_CLK_IN_TEST тактов, то мы считаем, что тест завис. Сторожевой таймер завершает тест, и выводится соответствующее сообщение об ошибке.

  // сторожевой таймер для отслеживания зависания теста   initial begin     repeat(`MAX_CLK_IN_TEST) @(posedge aclk);     $display("ERROR! Watchdog error!");     $display("----------------------");     $display("---- TEST FAILED! ----");     $display("----------------------");     $finish;   end 

Наконец, добавим последний блок inital, отвечающий за дамп временных диаграмм в формате VCD.

  // дамп waveforms в VCD файл   initial begin     $dumpfile("wave_dump.vcd");     $dumpvars(0);   end 

Примеры использования окружения

Наше тестовое окружение готово к использованию. Давайте проверим его работу. Для начала рассмотрим, как оно детектирует различные ошибки. Для этого изменим описание сумматора таким образом, чтобы входной регистр для второго слагаемого работал некорректно и всегда содержал нулевое значение. Запускаем тест, который должен выполнить 5 суммирований, и видим следующие временные диаграммы:

На входы сумматора поступают случайные слагаемые, однако результат суммы всегда совпадает со значением первого слагаемого. Ниже представлены сообщения от симулятора:

Можно увидеть, что окружение обнаружило 5 несовпадений. В сообщениях указаны входные слагаемые, эталонный и фактический результаты сложения, а также момент времени, когда обнаружена ошибка. Также выводится сообщение о том, что тест не пройден.

Теперь внесем в сумматор другую ошибку. Пусть мы забыли подключить к выходному порту data_o_tvalid сумматора сигнал валидности данных от блока управления. После запуска теста получим следующую временную диаграмму:

Драйверы генерируют множество входных транзакций, но сигнал data_o_tvalid всегда находится в z-состоянии. Из-за этого монитор не видит ни одной транзакции на выходе сумматора и ничего не передает в scoreboard. Тот в свою очередь никогда не получит запланированное число транзакций (TRANS_NUMBER) и не завершит тест. Однако, тест не будет выполняться бесконечно долго, так как сторожевой таймер обнаружит зависание и прервет моделирование. В результате мы получим следующее сообщение от симулятора:

Наконец, уберем все ошибки из сумматора и запустим моделирование. Глядя на временные диаграммы, мы можем увидеть, что сложение выполняется правильно:

Однако, чтобы понять, что сумматор работает корректно, не обязательно просматривать все временные диаграммы. Достаточно просто прочитать сообщение симулятора о результатах теста:

Заключение

Мы реализовали на языке Verilog тестовое окружение, структура которого была разработана в предыдущей статье. Окружение построено по принципу self-test testbench и выполняет проверку сумматора с помощью consraint-random testing. Однако, у нас есть еще широкий простор для его улучшения.

Во-первых, при описании драйверов и мониторов мы получили большой объем дублированного кода. Это всегда приводит к сложностям при дальнейшей поддержке и модификации окружения. Во-вторых, для задания параметров теста мы использовали директивы define. Это не самый лучший подход, так как при изменении настроек теста, нам придется заново компилировать все окружение. В случае больших проектов перекомпиляция исходников может занимать достаточно много времени. Есть более удобный способ настройки окружения. Мы исправим эти недостатки и получим окончательный вариант тестового окружения в следующей статье.