OparinVD 0 November 10 Posted November 10 · Report post Всем доброго дня! Столкнулся с такой проблемой. Проект каждый раз клонируется из гита с нуля. Раньше повторяемость результатов была стопроцентная, а теперь откуда-то взялась неопределенность: исходные условия одинаковые, а на выходе получается один вариант из двух (ориентируюсь по достигнутым частотам). Пытаюсь локализовать и вот что обнаружил. На топ-BD есть axi smartconnect с двумя слейв-входами. Один подключен к внешнему bd_intf_port , а второй к внутреннему мастеру. Дифф двух блок-дизайнов (те, что уже в виде xml-ки) показал, что у axi-мастеров есть некий параметр master_id, и два мастера от случая к случаю получают значения для этого параметра то 1 и 2, то 2 и 1 соответственно. Сами же мастеры всегда подключены к одним и тем же входам смартконнекта (внешний мастер к S00_AXI, внутренний - к S01_AXI). Дотянуться до параметра master_id не удалось, его нет ни в GUI, ни в get_property. Кто и когда его назначает, тоже не понятно. Если из двух BD, дающих разные итоговые результаты сделать write_bd_tcl, то сгенерируются две идентичные tcl-ки. Как видится, именно эти отличия становятся развилкой для настройки потрохов смартконнекта, что в свою очередь, дает на выходе один из двух вариантов. Как можно поймать момент, когда кем присваиваются значения для master_id? А самое главное - понять, чем это кто-то руководствуется при выборе, что при одних и тех же исходных данных назначает разные значения. Quote Share this post Link to post Share on other sites More sharing options...
pavlovconst 7 November 11 Posted November 11 · Report post Уточните, различия проявляются на одной и той же машине, или на разных? Если на разных - то там много чего может повлиять Аналогичный вопрос про Vivado. Каждый раз после клонирования запускаете одну и ту же среду на той же машине? Или есть вероятность, что на машине несколько инсталляций? Или попробовать отключить многопоточность Quote set_param general.maxThreads 1 https://docs.amd.com/r/en-US/ug901-vivado-synthesis/Multi-Threading-in-RTL-Synthesis Quote Share this post Link to post Share on other sites More sharing options...
OparinVD 0 November 11 Posted November 11 · Report post Для сборки у нас есть отдельно выделенная машина, соответственно речь о результатах в рамках одной машины и одинакового окружения. Версий Vivado там сейчас оказалось две, но абсолютно точно используется всегда одна и та же, т.к. она выбирается в ./bashrc: source /srv/Xilinx/Vivado/2023.2/settings64.sh Вот потоков на ней запускается два. Экспериментально было установлено, что если больше, то машина не тянет. Но с двумя всегда справлялась, и раньше повторяемость результатов была 100%. Пытался по истории в гите отсечь момент, когда проблема начала проявляться. Потратил уйму времени, но похоже, поймал совершенно не то... Тогда проблема выглядела немного иначе. Казалось, что не совпадают результаты при клонировании суперпроекта и запуске сборке сразу как есть, и предварительном явном переключении на те же ветки - во втором варианте... Как оказалось, checkout был совсем не при чем 🙂 Сейчас явно установил, что в зависимости от того как распределились значения master_id у мастер-интерфейсов, в smartconnect-e генерятся исходники с разными параметрами, типа <PARAMETER NAME="C_SSC_ROUTE_ARRAY" VALUE="0b1001110110111001"/> и <PARAMETER NAME="C_MEP_IDENTIFIER" VALUE="1"/> Т.е. получается такая цепочка: при клонировании - 100% исходники одинаковые; в процессе генерации BD формируются уже отличающиеся исходники (всего два типа), которые закономерно приводят к одному из двух конечных вариантов. Вот как найти, где в этой цепочке сидит квантовая неопределенность - не могу придумать Quote Share this post Link to post Share on other sites More sharing options...
pavlovconst 7 November 12 Posted November 12 · Report post Попробовал воспроизвести ситуацию у себя на версии 2024.1. Действительно, после зачитывания блок-схемы из TCL скрипта значения master_id поменялись. То, что дизайн не воспроизводится бит-в-бит - это похоже на баг. С другой стороны, поведение-то обоих вариантов идентичное, вне зависимости от того, какой master_id у какого интерфейса. Попытался вписать свойство master_id в TCL скрипт. Не получилось: CRITICAL WARNING: [BD 41-737] Cannot set the parameter master_id on /S00_AXI_0. It is read-only. CRITICAL WARNING: [BD 41-737] Cannot set the parameter master_id on /S01_AXI_0. It is read-only. Наверное, стоит подумать, как вписать заведомо известные значения master_id в .bd файл внешними средствами. Можно внести блок-дизайн под контроль версий, тогда отпадет необходимость восстанавливать его из TCL. Или написать дополнительный скрипт, который будет подменять значения master_id сразу после восстановления из TCL, но перед генерацией исходников. Quote Share this post Link to post Share on other sites More sharing options...
andrew_b 28 November 12 Posted November 12 · Report post Что-то я не припомню, чтобы Xilinx гарантировал идентичный результат сборки при идентичныъ начальных условиях. То, что так получается, приятный бонус, не более. Именно так я это всегда и воспринимал. Quote Share this post Link to post Share on other sites More sharing options...
OparinVD 0 November 12 Posted November 12 · Report post 2 hours ago, andrew_b said: Что-то я не припомню, чтобы Xilinx гарантировал идентичный результат сборки при идентичныъ начальных условиях. То, что так получается, приятный бонус, не более. Именно так я это всегда и воспринимал. Справедливо ) Но пока оно было именно так, и хотелось бы чтобы так и оставалось... И это больше, чем просто приятный бонус. Иначе потеряет всякий смысл, например, тегирование версий. Понадобилось собрать прошивку из прошлого чек-поинта, а она уже не может собраться с прежними результатами. В моем конкретном случае к синтезатору-то как раз претензий нет. Он закономерно дает два разных результата, имея на входе два разных набора исходников, пусть и генерируемых исходников Quote Share this post Link to post Share on other sites More sharing options...
makc 354 November 12 Posted November 12 · Report post 3 минуты назад, OparinVD сказал: В моем конкретном случае к синтезатору-то как раз претензий нет. Он закономерно дает два разных результата, имея на входе два разных набора исходников, пусть и генерируемых исходников Как вариант я вижу только один выход - добавлять в репозиторий dcp (контрольные точки сборки ядер). Quote Share this post Link to post Share on other sites More sharing options...
OparinVD 0 November 12 Posted November 12 · Report post 8 hours ago, pavlovconst said: Наверное, стоит подумать, как вписать заведомо известные значения master_id в .bd файл внешними средствами. Можно внести блок-дизайн под контроль версий, тогда отпадет необходимость восстанавливать его из TCL. Или написать дополнительный скрипт, который будет подменять значения master_id сразу после восстановления из TCL, но перед генерацией исходников. Вносить .bd в контроль версий совсем не хочется, всё-таки первичными являются tcl-скрипт сборки и файл с параметрами, именно они коммитятся. Можно действительно сгенерированный .bd подправить уже не через vivado, а прямо на диске... Выглядит как-то варварски, но определенно должно сработать. Может найдутся еще средства, как можно контролировать master_id? Quote Share this post Link to post Share on other sites More sharing options...
pavlovconst 7 November 12 Posted November 12 · Report post 2 hours ago, andrew_b said: Что-то я не припомню, чтобы Xilinx гарантировал идентичный результат сборки при идентичныъ начальных условиях Ксайлинкс заявляет, что в большинстве случаев идентичность будет https://adaptivesupport.amd.com/s/article/61599?language=en_US Я не раз работал над проектами, где заказчик явно требовал идентичности. И этого можно добиться на практике Quote Share this post Link to post Share on other sites More sharing options...
alexadmin 2 November 12 Posted November 12 · Report post Попробуйте зарезать строго до одного ядра/потока всю виваду. Хотя бы в качестве эксперимента. Quote Share this post Link to post Share on other sites More sharing options...
