[10ff 0]

Коллеги, хотелось бы услышать ваше мнение.

Допустим, есть наработанная годами база различных модулей. Они отлажены, протестированы, редко в них вносятся изменения. В данный момент каждый разработчик копирует эту базу в папку своего проекта, дорабатывает некоторые модули, иногда находит и устраняет ошибки. Плюс ко всему, в зависимости от проектов появляются разные вариации тех же самых модулей под разные задачи. С ростом числа проектов и количества разработчиков отслеживать все это становится просто нереально, возникают проблемы синхронизации. Как вы организуете совместный доступ к единой базе модулей? Git + САПР? Или более сложные механизмы?

[Alex77 4]

вполне достаточно предложенного...

[des00 25]

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

[fguy 5]

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

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

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

[10ff 0]

Понятно, мнения о целесообразности общего репозитория разделились...

[Alex77 4]

ничто не запрещает "В каждом проекте создаю отдельную папку с ядрами и правлю их под конкретный проект." и заливать туда конкретную версию корки.

[RobFPGA 35]

Единый реп корок требует определенной организации процесса разработки. Тогда вы получаете профит от единой базы кода.     
"Каша" с локальными репами проста в изготовлении но вести десяток версий одной и той же корки та еще  головная боль.   

[kenezoer 0]

В 24.03.2023 в 17:35, RobFPGA сказал:

Единый реп корок требует определенной организации процесса разработки. Тогда вы получаете профит от единой базы кода.     
"Каша" с локальными репами проста в изготовлении но вести десяток версий одной и той же корки та еще  головная боль.   

Поддержу. Нормально отлаженный workflow и требования разрабатывать параметризуемые модули (в т.ч. параметризация по платформе / техпроцессу) позволяет это дело юзать достаточно удобно и не пересоздавать базу под каждый новый проект.

[fguy 5]

9 часов назад, kenezoer сказал:

требования разрабатывать параметризуемые модули

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