OparinVD

а, всё нормально, заблудился в namespace'ах всё, что прописано в bd.tcl, живет в namespace, образованном от vlnv (без разделителей), поэтому надо было или определять namespace eval ::ns1 {} чтобы наследоваться от топа, или сразу обращаться к любой функции в bd.tcl как ${vlnv}::my_func думаю, на этом всё ))

это поле - строка, хранит последнее записанное значение... если надо положить туда несколько значений - кладите список: set_property generic {generic1=14 generic2=12} [current_fileset]

я не спец и не очень представляю, для чего это поле, но property generic выглядит так: Property Type Read-only Value GENERIC string* false ... какого поведения вы ожидали?

Попробовал зайти чере namespace. Добавил вот это в bd.tcl namespace eval ns1 { proc my_callback {cell params} { puts "**********************" puts "$cell Hello from my_callback" puts "** params: $params ***" } } но не прокатило. Видимо bd.tcl в явном виде не сорсится. Или сорсится, но в каком-то отдельном служебном контексте...

Доброго дня! Я прикручиваю bd.tcl к своему кастомному ip. Можно ли в нем помимо стандартных callback'ов, которые дергает вивда при валидации bd, положить свои функции, которые буду дергать я со своего топлевел-bd? Например, передавать по кругу некий list, а каждый инстанс bd_cell добавит в этот list всё, что сочтет нужным. Если абстрактно, то выглядеть должно как-то так: set bdcell_01 [ create_bd_cell -type ip -vlnv <somthing #01> ] set bdcell_02 [ create_bd_cell -type ip -vlnv <somthing #02> ] set reglist [list ] bdcell_01.register reglist bdcell_02.register reglist foreach item $reglist { ...} Как этим пользоваться я в полной мере еще не продумал )) Может и не нужно оно вовсе, но пока интересна принципиальная возможность такой техники, можно ли на нее закладываться?

Да, глянул из любопытсва, что там у Вивады. Уж не знаю полный список обновлений в стандарте, но Вивадо поддерживает очень скромный перечень. Ну и традиционно нельзя на BD кинуть топлевел файл, если он не просто vhdl, а vhdl-2008 или тем более 2019

Я связался с автором статьи, он пояснил, что к сожалению, configuration - это только про копание внутри архитектуры, а в объявление контекста конфигурацией не залезть. Как вариант, показал, что в VHDL-2019 появилось понятие "Conditional analysis" - по сути это директивы препроцессора. Но я пока побаиваюсь пробовать 2019, вероятно мой путь - это всё-таки скриптом дублировать исходник топ-левела и у клона править используемый контекст.

configuration - определенно правильное направление, но пока не получилось... как разберусь, отпишусь спасибо

можете поделиться примером? про configuration слыхал, но в руках еще не крутил... в интернете примеры направлены на манипуляции с entity: выбор архитектуры, перемэпинг портов и т.д. Как правило встречается в контекскте тестбенчей

в ug901 нашел, что можно: засовывать generic в package, передавать type через generic и даже передавать function через generic (как много нам открытий чудных дает чтение книг дальше 20й страницы 🙂 ), но не нашел о передаче package через generic... У меня в package не только сами record объявлены. Для каждой record объявлена константа, определяющая длину std_logic_vector, получаемого конкатенацией всех полей record-а. А также две функции: conv_rec_to_slv и conv_slv_to_rec (эти имена одинаковые для всех record, резолвятся по типу аргументов). Зная теперь, что можно через генерик передать не только константу, но и тип с функцией, из всего этого наверное можно слепить что-то рабочее, но получится очень громоздко. У меня около десятка типов record, каждую по отдельности замучаешься настраивать 😞

если record'ы назвать разными именами, то потеряется смысл, т.е. у каждого декодера будет свой текст, в котором он использует свои record'ы а вот если можно через generic передавать подключаемый package, то это бы всё решило... это возможно?

Доброго дня! Пишу на VHDL, но в топике язык не стал указывать, т.к. решение, возможно, придется искать за пределами hdl. Задача такая: у меня есть два протокола передачи данных, они одинаковы по структуре, т.е имеют одинаковые заголовки и подзаголовки и схожие по смыслу но отличающиеся в деталях пейлоады (разный порядок и состав полей). Парсинг я делаю примерно так: выделяю из потока буфер нужной длины (например, очередной заголовок) и накладываю на него record с полями. Сами структуры описаны в разных библиотеках templates1.vhd и templates2.vhd. Внутри этих файлов объявлены типы с одинаковыми именами, типа type payload1 is record field1 : std_logic_vector(7 downto 0); end record для одного шаблона и type payload1 is record field1 : std_logic_vector(15 downto 0); field2 : std_logic_vector(15 downto 0); end record Хочется подключением разных package с шаблонами выбирать, какой протокол реализует компонент. Навскидку видятся такие пути решения: 1. Продублировать исходник компонента и в шапке первого прописать use templates1.all, а в шапке другого соответственно use templates2.all. Все просто и понятно, но неприятность в дублировании кода. 2. Внутри компонента ссылаться всегда на одно и то же имя use templates.all, а шаблоны с одинаковым именем файла разделять разными путями к файлу. На этапе package ipcore в Вивадо скрипту упаковки передаем список исходников и разным ipcore кладем разные файлы с шаблонами. На уровне Вивадо вроде как всё пройдет гладко, т.к. не возникнет конфликта - OOC синтез увидит только свой шаблон, а дальше пойдет нетлист. Но видится, что если оба ipcore одновременно встретятся, например, на симуляции в Квесте, то возникнет конфликт имен, т.к. в общей видимости появятся два package с одинаковыми именами и одинаковыми объявленными типами данных. 3. Некий гибрид 1 и 2. При упаковке ipcore любым скриптовым языком генерим код компонента путем копирования исходника и правкой шапки с подключением библиотеки. Вроде рабочий вариант, но отдает какой-то костыльностью. Есть мысли как лучше это сделать?

Спасибо

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

Не стал отдельную тему заводить Порекомендуйте, пожалуйста, какой симулятор взять с фтп, чтоб был полноценный, был совместим с vivado 2022.2, желательно работал под убунтой, ну и самое важное - с рабочей таблеткой ))

что-то новое сейчас осваивать вряд ли возьмёмся, будем прикручивать вивадовский xsim, а он вроде из коробки знаком с uvm

да, пожалуй, это как раз представлялось вторым шагом на пути развития тестбенча после прямых тестов. Я читал SystemVerilog For Verification и пробежал несколько быстрых гайдов по uml, и у меня сложилось впечатление, что uvm это "экранизация" по Крису Спиру. Отсюда и родилась идея попробовать uml, чтобы вручную не реализовывать те классы, которые в книжке описаны, а взять что-то готовое, где всё уже увязано между собой... ошибаюсь?

Тестирование в железе у нас есть, но не покидает ощущение не прикрытого зада :) У нас есть отдел тестирования, и они тестируют готовую прошивку на наборе прямых тестов. Есть сравнительное тестирование (тоже в железе) с версией софтовой реализации той же задачи. Поднимать отдел для верификации - это скорей не про нас. Будем сами переключаться с дизайна на верификацию. В качестве первого шага, вероятно, переложим существующие тесты с железа в симулятор, а в будущем снабдим каждый свой ipcore тестбенчем, который будет запускаться при необходимости перед сборкой, чтобы заранее выявить, что где-то порылась собака. С одной стороны хочется, чтобы тест был достаточно полным, чтобы спать спокойно, с другой стороны есть понимание, что мы вряд ли освоим кунг-фу в полном объеме. А в чем видится погибельность такого пути? Тут да, в полном смысле CD конечно нет. Есть git-lab, есть скрипты сборки, но полная сборка триггерится только вручную, ибо трёх-часовую имплементацию не назапускаешься на каждый чих. Есть желание, чтобы в рамках CD хотябы запускался симулятор.

"Модульное тестирование" - это пожалуй не очень удачный термин. У нас сейчас в принципе не достаточное покрытие на всех этапах. Мы как разработчики от себя конечно стараемся выдать проверенный продукт, но этого становится мало. Для начала хочется просто обмазаться авто-тестами для отдельных компонентов для ci/cd, а потом углубиться до чего-то более интеграционного

Доброго дня! В нашем проекте в последнее время на флаг подняли тему про "модульное тестирование". Смысл в том, что пришла пора построить взрослую верификацию, в связи с чем мы находимся на распутье. Я так понимаю, флагманом в отрасли является UVM, но начав копаться в теме, наткнулся на OSVMM, есть смысл на него смотреть? Привлекает, конечно, тем, что, как видится, цена входа существенно ниже, т.к. под синтез мы пишем именно на VHDL. Но не покидает ощущение, что это несколько суррогатное решение... С SV я пока на "вы", так писал несколько testbench-поделок без ООП и читал книжки. Нужно принять волевое решение, в какую сторону копать, что посоветуете?

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

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

тут имелось в виду, что в доках в основном только и говорят, что о встроенных PS, а про софтовые ядра, я не нашел... может, конечно, я за деревьями леса не увидел, и это как раз то, что мне и нужно... но как раз это и хочется понять. Повторюсь, на этом этапе хочу просто тезисно понять основные моменты MB хочу использовать для взаимодействия с хостом: принимать сообщения, инициализировать Rtl-внутренности, формировать Log-сообщения и т.д. Сейчас это всё реализовано и работает в rtl, но чем дальше, тем менее гибкой становится система, тупик близок 🙂

у нас U50, там нет встроенных процов

Доброго дня! Мы работаем на Alveo, и проект существенно разросся. Для управления этим хозяйством думаю взять Microblaze. Совет старейшин такой ход пока не одобрили, поэтому в полный рост эксперименты начать не могу. По диагонали прошерстил документацию и понял, что это в принципе возможно, но в явном виде об этом нигде не говорится (или я не нашел). В основном речь везде идет о Zync PS, а про софт-процессор хоть бы главку где уделили. Мы работаем на стандартной платформе с NoDMA, собираем RTL-кернелы, потом в коннективити.ini их соединяем и запускаем V++ через консоль. Сейчас хочется хотя бы тезисно понять, как сюда впишется MB: 1) какую платформу брать при создании проекта в Vitis? Это обычная платформа, которая получается экспортом hardware из BD, на котором живет microblaze? Или потребуется ваять свою Alveo-платформу на основе стандартной? 2) был вопрос, как подключаться к этому процессору, но потом встретил фразу, что если платформа поддерживает xvc, то дебаг-модуль без проблем подцепится через него. Останется только понять, можно ли будет одновременно цепляться и к MB, и к ILA.. 3) как отлаживать это хозяйство? наверно процесс должен распасться на две части - постулируем, что железо отлажено и моделируем/отлаживаем софт, и наоборот.. так? 4) как обновлять софт для MB, не перезапуская разводку всего проекта. Встречал директиву -package для v++, которая вроде берет xclbin + elf и на выходе дает xclbin. Это оно?