[OparinVD 0]

Доброго дня!

Задача такая: наши тестеры пишут свои тесты, задавая параметры в yaml файле. Процесс устоявшийся и работает для софтовых компонентов, а также есть фреймворк для проверки некоторых кейсов в составе готовой прошивки в железе. Мне нужно перетянуть этап тестов на уровень симулятора, т.е. из SystemVerilog прочитать конфигурацию теста и накинуть соответствующие воздействия на UUT. Есть какие-то готовые инструменты для парсинга yaml? Что-то поиск дал только некий svlib от verilab, но там читалка yaml оказалась только на витрине, а внутри всё ограничилось только чтением *.ini. 

Или может я всё усложняю, и можно по-другому?

[dxp 65]

Написать скрипт, который из yaml описания родит SV заголовочный файл. Мы так делаем. Т.е. из описания типа:

parameters:
    PROJECT_NAME                : detector
    TOP_NAME                    : detector_m
    TESTBENCH_NAME              : detector_tb
    DEVICE                      : xcku15p-ffve1517-2-i
    DEVICE_ID                   : 1

    RELEASE_VERSION             : 0
    BUILD_NUMBER                : 0

    NET_PORT_COUNT              : 4
    VLAN_COUNT                  : 10

    MAIN_AXIS_WIDTH             : 512
    MAIN_AXIS_USER_WIDTH        : 48
    MAIN_AXIS_ID_WIDTH          : 8

    PACKET_PERIOD               : 10ns

рожается:

//-------------------------------------------------------------------------------
//
//  This file is automatically generated. Do not edit the file!
//
//-------------------------------------------------------------------------------

`ifndef GUARD_CFG_PARAMS_SVH
`define GUARD_CFG_PARAMS_SVH

// synopsys translate_off
`ifndef SIMULATOR
`define SIMULATOR
`endif // SIMULATOR
// synopsys translate_on

`define PROJECT_NAME                detector
`define TOP_NAME                    detector_m
`define TESTBENCH_NAME              detector_tb
`define DEVICE                      xcku15p-ffve1517-2-i
`define DEVICE_ID                   1
`define RELEASE_VERSION             0
`define BUILD_NUMBER                0
`define NET_PORT_COUNT              4
`define VLAN_COUNT                  10
`define MAIN_AXIS_WIDTH             512
`define MAIN_AXIS_USER_WIDTH        48
`define MAIN_AXIS_ID_WIDTH          8
`define PACKET_PERIOD               10ns

`endif // GUARD_CFG_PARAMS_SVH
  

Реализация на питоне. Тривиальна: всасывается yaml описание с помощю pyyaml, дальше это просто словарь, проход по его ключам с генерированием выходных строк. Как-то так:

import yaml

#-------------------------------------------------------------------------------
...
    with open( <path-to-yaml-file> ) as f:
        cfg = yaml.safe_load(f)
  
    params = cfg['parameters']
  
    max_len = max_str_len(params.keys()) + 2
...
    text += '// synopsys translate_off' + os.linesep
    text += '`ifndef SIMULATOR'         + os.linesep
    text += '`define SIMULATOR'         + os.linesep
    text += '`endif // SIMULATOR'       + os.linesep
    text += '// synopsys translate_on'  + os.linesep*2

    for p in params:
        value = str(params[p])
        text += '`define ' + p + ' '*(max_len - len(p)) + value + os.linesep
...
      
    with open(<path-to-output-svh-file>, 'w') as ofile:
        ofile.write(text)
...      
#-------------------------------------------------------------------------------
def max_str_len(x):
    return len(max(x, key=len))
#-------------------------------------------------------------------------------
      
      
      

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

 

[OparinVD 0]

Спасибо, принцип понял
Кстати, за сборочную систему отдельное спасибо. Еще не прикрутили, но в ближайших планах есть

[kirill70674 5]

В 12.07.2023 в 06:02, dxp сказал:

Написать скрипт, который из yaml описания родит SV заголовочный файл. Мы так делаем. Т.е. из описания типа:

parameters:
    PROJECT_NAME                : detector
    TOP_NAME                    : detector_m
    TESTBENCH_NAME              : detector_tb
    DEVICE                      : xcku15p-ffve1517-2-i
    DEVICE_ID                   : 1

    RELEASE_VERSION             : 0
    BUILD_NUMBER                : 0

    NET_PORT_COUNT              : 4
    VLAN_COUNT                  : 10

    MAIN_AXIS_WIDTH             : 512
    MAIN_AXIS_USER_WIDTH        : 48
    MAIN_AXIS_ID_WIDTH          : 8

    PACKET_PERIOD               : 10ns

рожается:

//-------------------------------------------------------------------------------
//
//  This file is automatically generated. Do not edit the file!
//
//-------------------------------------------------------------------------------

`ifndef GUARD_CFG_PARAMS_SVH
`define GUARD_CFG_PARAMS_SVH

// synopsys translate_off
`ifndef SIMULATOR
`define SIMULATOR
`endif // SIMULATOR
// synopsys translate_on

`define PROJECT_NAME                detector
`define TOP_NAME                    detector_m
`define TESTBENCH_NAME              detector_tb
`define DEVICE                      xcku15p-ffve1517-2-i
`define DEVICE_ID                   1
`define RELEASE_VERSION             0
`define BUILD_NUMBER                0
`define NET_PORT_COUNT              4
`define VLAN_COUNT                  10
`define MAIN_AXIS_WIDTH             512
`define MAIN_AXIS_USER_WIDTH        48
`define MAIN_AXIS_ID_WIDTH          8
`define PACKET_PERIOD               10ns

`endif // GUARD_CFG_PARAMS_SVH
  

Реализация на питоне. Тривиальна: всасывается yaml описание с помощю pyyaml, дальше это просто словарь, проход по его ключам с генерированием выходных строк. Как-то так:

import yaml

#-------------------------------------------------------------------------------
...
    with open( <path-to-yaml-file> ) as f:
        cfg = yaml.safe_load(f)
  
    params = cfg['parameters']
  
    max_len = max_str_len(params.keys()) + 2
...
    text += '// synopsys translate_off' + os.linesep
    text += '`ifndef SIMULATOR'         + os.linesep
    text += '`define SIMULATOR'         + os.linesep
    text += '`endif // SIMULATOR'       + os.linesep
    text += '// synopsys translate_on'  + os.linesep*2

    for p in params:
        value = str(params[p])
        text += '`define ' + p + ' '*(max_len - len(p)) + value + os.linesep
...
      
    with open(<path-to-output-svh-file>, 'w') as ofile:
        ofile.write(text)
...      
#-------------------------------------------------------------------------------
def max_str_len(x):
    return len(max(x, key=len))
#-------------------------------------------------------------------------------
      
      
      

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

 

Даный подход, насколько я вижу, не предполагает иерархичности yaml-дерева. Не лучше ли парсинг yaml переложить на C++, где всё уже написано. Далее небольшая прослойка DPI-C в виде функции аля "int get_field(string yaml_path)" где входная строка будет раскладываться на имена уровней. В итоге на стороне SV мы получаем возможность не compile-time, а run-time конфигурации. Т.о. где-то в топовом initial будут строки вроде "parsed_param = get_field("/level1/level2/key_name")".

[dxp 65]

13 часов назад, kirill70674 сказал:

Даный подход, насколько я вижу, не предполагает иерархичности yaml-дерева.

Не ведаю, что такое "иерархичность yaml-дерева", даже к стыду не знаю, что такое "yaml-дерево". Если имеется в виду, что значения словаря может в свою очередь тоже могут являться ключом для другого словаря, то для определения параметров этого не надо. Гораздо важнее возможность вычислять значения параметров на основе других (определённых выше) и импортировать другие yaml файлы с параметрами, которые так же можно использовать при вычислениях (что штатное "yaml-дерево" не поддерживает, т.к. это просто формат хранения). И это у нас есть.

 

13 часов назад, kirill70674 сказал:

Не лучше ли парсинг yaml переложить на C++, где всё уже написано.

Не лучше. Не знаю, что там написано на С++, но на Python такие вещи делаются куда проще: и пишутся, и читаются, и сопровождаются. А DPI -- это симулятор онли. У нас же эта система параметров используется в первую очередь для обслуживания синтеза, включая генерирование IP ядер, создание проекта синтезатора (Vivado), компиляцию HLS модулей и применение параметров общего назначения, из которых генерятся не только svh заголовки для SV, но и tcl файлики для симулятора и синтезатора. Вся кухня работает по зависимостям, т.е. лишней работы не делается.

 

13 часов назад, kirill70674 сказал:

В итоге на стороне SV мы получаем возможность не compile-time, а run-time конфигурации. Т.о. где-то в топовом initial будут строки вроде "parsed_param = get_field("/level1/level2/key_name")".

И зачем рантайм конфигурация, если это можно сделать на этапе компиляции? Рантайм нужен там, где по-иному не получается или неэффективно (негибко, громоздко). В случае заранее заданных параметров всё известно на этапе компиляции. На рантайме симулятору и другой нагрузки достаточно.

[kirill70674 5]

4 часа назад, dxp сказал:

Не ведаю, что такое "иерархичность yaml-дерева", даже к стыду не знаю, что такое "yaml-дерево". Если имеется в виду, что значения словаря может в свою очередь тоже могут являться ключом для другого словаря, то для определения параметров этого не надо. Гораздо важнее возможность вычислять значения параметров на основе других (определённых выше) и импортировать другие yaml файлы с параметрами, которые так же можно использовать при вычислениях (что штатное "yaml-дерево" не поддерживает, т.к. это просто формат хранения). И это у нас есть.

 

Не лучше. Не знаю, что там написано на С++, но на Python такие вещи делаются куда проще: и пишутся, и читаются, и сопровождаются. А DPI -- это симулятор онли. У нас же эта система параметров используется в первую очередь для обслуживания синтеза, включая генерирование IP ядер, создание проекта синтезатора (Vivado), компиляцию HLS модулей и применение параметров общего назначения, из которых генерятся не только svh заголовки для SV, но и tcl файлики для симулятора и синтезатора. Вся кухня работает по зависимостям, т.е. лишней работы не делается.

 

И зачем рантайм конфигурация, если это можно сделать на этапе компиляции? Рантайм нужен там, где по-иному не получается или неэффективно (негибко, громоздко). В случае заранее заданных параметров всё известно на этапе компиляции. На рантайме симулятору и другой нагрузки достаточно.

Под yaml-деревом я имел в виду именно когда "значения словаря может в свою очередь тоже могут являться ключом для другого словаря".

Всё так, для дизайна под ПЛИС действительно удобно использовать сгенерённые SVH файлы, но речь то изначально про симуляцию. Проблема Вашего подхода в том, что для реконфигурации проекта необходимо запускать весь сборщик заново. И проблем нет пока все тесты независимы друг от друга, т.е. каждый тест начинается с пересборки проекта. А если дизайн нужно реконфигурировать без пересборки? А если если речь идёт о симуляции нет-листа, генерация которого может занимать часы/дни? Тут реконфигурация тестбенча в run-time становится требованием, а не опцией.

Именно по этому (ДЛЯ СИМУЛЯЦИИ) стоит один раз заморочиться с DPI и парсингом, дабы в будущем все вышеописанные проблемы решались легко и непринуждённо. Проект ведь имеет свойство развиваться и расширяться...

P.S. А вообще интересено, есть ли возможность внутри блока generate использовать какие-то самописные функции для того же парсинга YAML или JSON...

[dxp 65]

11 часов назад, kirill70674 сказал:

Всё так, для дизайна под ПЛИС действительно удобно использовать сгенерённые SVH файлы, но речь то изначально про симуляцию.

Название темы опровергает ваш тезис.

11 часов назад, kirill70674 сказал:

Проблема Вашего подхода в том, что для реконфигурации проекта необходимо запускать весь сборщик заново.

Проблема? За несколько лет интенсивного использования и не догадывался, что это проблема.

Запускать сборщик заново? Это проблема? svh файлы генерируются за доли секунды. Если их содержимое не изменилось (сборочный тул проверяет это по хэшам), то дальнейшая цепочка сборки не выполняется.

Что касается времени выполнения, то процесс компиляции по сравнению с прогоном на рантайме по длительности отличается на пару порядков (1-2 минуты компиляция, час-полтора прогон). О какой экономии тут речь?

11 часов назад, kirill70674 сказал:

А если если речь идёт о симуляции нет-листа, генерация которого может занимать часы/дни?

Генерация нетлиста занимает дни? Это что за процесс такой? Боюсь спросить, а сколько времени занимает прогон тестов этого нетлиста? Месяцы?

А если под генерацией нетлиста подразумевается синтез и PnR, то это совсем другая история.

C DPI тоже дружим, но по другому поводу -- связь с инструментарием внешнего (по отношению к симулятору) мира.