Перейти к содержанию
    

Организация работы с единой базой модулей

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...