Retrascope

Не очень понятно, какова роль шаблонов в процессе генерации тестбенчей и почему их нельзя генерировать on-the-fly?

Файловое представление более наглядно. Также в него можно вносить изменения без перекомпиляции кода.

А что по поводу первой части вопроса:

Сергей Смолов wrote:

Не очень понятно, какова роль шаблонов в процессе генерации тестбенчей и ...

?

Хранение каркаса, на основе которого генерируются тестбенчи для конкретных модулей.
Планируется, что в этой папке будет два файла: один — для VHDL, другой — для Verilog'а.

По поводу размещения: предлагаю пока шаблоны перенести в src/main/templates/vhdl и src/main/templates/verilog соответственно для VHDL-тестбенчей и Verilog-тестбенчей.
Текстовый формат описания тестов также кажется не самым удобным решением. Что мы будем делать, если потребуется генерировать тесты иной структуры, нежели описана сейчас? Например, тесты для подсистем? Постоянно новые шаблоны в текстовом виде класть в инструмент? А если тесты потребуется делать длинными?
Кроме того, файлы с расширениями "vhd" и "v" - это, все-таки, файлы HDL-описаний. То, что в них кладется сейчас, попросту не синтезабельно. Я считаю, что для описания шаблонов нужно использовать более удобные форматы, например, XML. Их можно, к тому же, обрабатывать автоматически и генерировать синтезабельный HDL в динамике.

По поводу перемещения не возражаю.
По поводу формата: с точки зрения текущего механизма генерации тестбенчей текущий формат шаблонов как раз наиболее удобен, так как их преобразования сводится к простой замене заполнителей на реальный код. Переход к XML усложнит процесс и сделает шаблоны менее наглядными (глядя на XML, тяжелее будет понять, как будет выглядеть итоговый тестбенч).
По поводу тестов иной структуры: хотелось бы увидеть пример таких тестов, тогда смогу прокомментировать.

Igor Melnichenko wrote:

По поводу перемещения не возражаю.

Ок.

По поводу формата: с точки зрения текущего механизма генерации тестбенчей текущий формат шаблонов как раз наиболее удобен, так как их преобразования сводится к простой замене заполнителей на реальный код. Переход к XML усложнит процесс и сделает шаблоны менее наглядными (глядя на XML, тяжелее будет понять, как будет выглядеть итоговый тестбенч).

Но что мешает сгенерировать по шаблону синтезируемый тестбенч и на него полюбоваться?
Текстовый формат нагляден, не спорю. Мне в текущей реализации не нравятся две вещи:

1) Шаблоны тестов имеют расширение HDL - это плохо, ибо вносит путаницу.
2) Содержимое шаблонов непонятно, комментарии (хотя бы даже в духе "This is an automatically generated testbench for...") отсутствуют. Что, например, в тесте HDL-описания, делает вот это:

[code]

procedure extract_next_value(s: inout string; value_string: out string) is
        variable i, j: integer;
    begin
        i := 1;
        j := 1;
        value_string := (others => '/');

while (s(i) /= ' ') loop
            if (s(i) /= '/') then
                value_string(j) := s(i);
                j := j + 1;
            end if;

i := i + 1;
        end loop;

s(i) := '/';
    end extract_next_value;

[/code]

Здорово смахивает на попытку загнать в HDL то, что должно делаться на более высоком уровне (в том же генераторе тестов, как компоненте Retrascope). Зачем в тесте парсить текстовую строку?

По поводу тестов иной структуры: хотелось бы увидеть пример таких тестов, тогда смогу прокомментировать.

src/test/vhdl/hc11/testbenches/bset.vhd
src/test/vhdl/hc11/testbenches/daa.vhd

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

Комментарии добавлю, расширение сменю.
Приведённый код добавлен в тестбенч, потому что он должен считывать тест, записанный в формате DECIDER'а (в котором значения входов записываются в одну строку через пробел). Более красивого решения по преобразованию таких тестов в сигналы я не нашёл.

Сергей Смолов wrote:

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

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

Igor Melnichenko wrote:

Комментарии добавлю, расширение сменю.
Приведённый код добавлен в тестбенч, потому что он должен считывать тест, записанный в формате DECIDER'а (в котором значения входов записываются в одну строку через пробел). Более красивого решения по преобразованию таких тестов в сигналы я не нашёл.

Мне кажется, что парсить DECIDER-тест - это не задача HDL-шаблона. Для этого в проекте должен существовать специально обученный DeciderTestParser, или что-то вроде того.
Поясни, пожалуйста, по шагам схему генерации теста с использованием DECIDER-теста, тогда можно будет что-то придумать.

Я без изменений заимствовал DECIDER'овскую структуру тестбенча, включающую два файла: файл .tst, хранящий тестовые последовательности, и файл .vhd, в котором эти последовательности считываются и подаются на вход тестируемого устройства.
Собственно класс Test из Retrascope преобразуется в .tst, такого формата (ниже приведена одна тестовая последовательность из DECIDER'овского примера):
X X X X 1 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
-3 6 1 1 0 1 X X X X X X X X X X X X X X X X X X X X 5 1 0 0 1 0 0 1 0 1 0 0 0 0 0 1 0 0 X X X X X X X X X
X X X X 0 X X X X X 0 0 0 X X X X X X X X X X X X X 3 0 0 X 1 0 1 0 0 0 0 X 0 0 0 1 0 0 X X X X X X X X X
X X X X 0 X X X X X X X X X 0 X X X X X X X X X X X 0 0 0 X 0 0 X 0 0 0 0 X 1 0 0 0 0 0 X X X X X X X X 0
X X X X 0 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
X X X X 0 X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

В их тестбенче тест считывается без использования процедур путём последовательного повторения следующего куска кода для каждой входной переменной (переменная test_pattern - это строка, считанная из файла):
-- data_in1 value
m:= 0;
while (test_pattern(n) /= ' ') loop
m:= m+1;
value_string(m) := test_pattern(n);
n:= n+1;
end loop;
if value_string(1) = 'X' then
w_data_in1 <= (others => 'X');
else
write(tmp_l_data_in1, value_string(1 to m));
read (tmp_l_data_in1, data_in1_r);
w_data_in1 <= std_logic_vector(to_signed(data_in1_r,4));
end if;
n:= n + 1;

Предлагаю функции чтения выделить в отдельный неизменяемый "кусок" шаблонов и подключать его при генерации тестбенчей (а-ля include).