Jump to content

    
OparinVD

Continuous integration в проектах на ПЛИС

Recommended Posts

Всем доброго дня!

Начну издалека. У нас в команде появился менеджер проектов, и недавно с ним состоялась беседа, типа:
- А как вы решаете merge конфликты?
- А у нас нет merge конфликтов :mda:, у нас каждый делает свой ipcore, и не бывает так, что несколько разработчиков коммитят изменения в один и тот же исходник...

Потом еще долго говорили о том, что каждый должен разбираться во всём проекте, а еще нужна непрерывная интеграция и т.д. Сходу я не нашел объективных аргументов "против" кроме как "я не пробовал, но осуждаю..." Понятно, что дело это индивидуальное и завистит от многих обстоятельств,... но в своем ближайшем окружении я не знаю никого, кто в проектах на ПЛИС применял бы современные методики, всё как-то по-старинке работают. Вот я и хочу понять, это просто лень и махровый ретроград внутри каждого мешают или же CI/CD - это удел web-проектов, а в нашем цеху неприменимо?

Если пользуетесь, поделитесь:

- какие средства для непрерывной интеграции под проекты на ПЛИС лучше подходят? (GitLab CI/CD, Jenkins и т.д)

- как выглядит маршрут CI?

- какой схемы ветвления git придерживаетесь? (наверно сюда до полноты картины уместно будет)

- и, наконец, возможно ли работать разным разработчикам над одним куском кода?

Share this post


Link to post
Share on other sites

Несколько тем по этому вопросы было недавно на форуме. Даже опрос был. Поиском по ключевым словам найдёте без труда (GitLab, Jenkins ...)

Ключевой для меня вопрос в вашем тексте - что значит

8 минут назад, OparinVD сказал:

разным разработчикам над одним куском кода

?

Вот я разрабатываю проект верхнего уровня, и использую кучу сторонних сложно-функциональных сблоков. В них я не лезу, однако если найдена ошибка в блоке, который уже находится в релизных проектах - делается либо версия отдельная СФ блока, либо выполняется пересборка и перепроверка всех завершённых ранее проектов (а это подчас недопустимо!).

Но если уж так случилось, и коллега в отпуске, а мне нужно править его код - то я делаю ветку. И потом коллега либо соглашается с моим решением, либо исправляет сам и ветку убивает.

Как-то так.

Share this post


Link to post
Share on other sites

Маршрут ci напрямую зависит от инструментов. Я использую Jenkins.

От классического ci отличие в том, что коонвейер сборки может ломаться, и будет ломаться, особенно на ранних стадиях проекта.

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

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

Share this post


Link to post
Share on other sites

Нас сейчас всего двое разработчиков в проекте. Делаем настолько разные куски, что объединяемся только при линковке Витисом наших кернелов. Вполне допускаю, что когда-то нацилимся на более близкие друг к другу задачи, возможно, нас даже станет больше... Но если работать разным людям над одним куском кода - нежелательно, откуда тогда вообще появляются merge конфликты? Есть еще источники появления проблемы?

Share this post


Link to post
Share on other sites

Так оттуда и берутся. Иногда поблема разделения труда - не решена. Например, оба добавили свои блоки в общий файл сборки, например, в Makefile.

Ну, ещё бывают уникальные снежинки, которые узнали о командах, git: rebase, vommit --amend, push --force, но как работает git, и что делают эти команды - не знают, но имеют жгучую потребность ими пользоваться

Share this post


Link to post
Share on other sites

Из всех известных мне компаний, только одна-единственная подняла CI/CD для своих проектов. И то только лишь для того, чтобы при любых изменениях-нововведениях быть уверенными, что старые проекты не сваляться. При этом сам производитель занимаеться обновлением прошивок на поставляемых устройствах, а конечные продукты настолько плотно обмазаны тестбенчами, что даже страшно.

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

Глобольно же на всех остальных конторах, разработка идёт по принципу "один модуль-один разработчик". Наверху всё может интегрировать системный инженер, отвечающий за проект или тестировщики. Merge-конфликты решает последний комитящий или по принципу поправить минорные нюансы, либо подходит к автору второго конфликта и решают вместе, кто правее.

И в заключение ИМХО эффективный менеджмент лучше применять на программистиках. Разработка схем такого не любит, хотя издалека кажется, что занимаются одним и тем же: но это только кажется. Поинтересуйтесь как справляются с такими задачами разработчики PCB, там дляже Гит неприменим по понятным причинам.

P.S. Делаем изменения в глобальных ветках (типа backend, dev и т.д.), на определённых этапах мерджим в кучу и пушим в мастер - так получаем ревизию и фриз. Фичи, проверки и т.п. каждый может гадить в своей ветке и оставить только нужное для мерджа в глобальную ветку.

P.P.S. А как Вы себе представляете совместную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил.

Share this post


Link to post
Share on other sites

Мы построили CI/CD систему с тестированием коммитов на железе. Очень улучшает жизнь и качество проектов, даже если блок делается одним разработчиком.

  • Упрощает ведение документации и отслеживание изменений в проекте.
  • Меньше багов т.к. невозможно забыть прогнать тесты.
  • Проверка на различных железных платформах.
  • Старый код регулярно проверяется и поддерживается в рабочем состоянии.
  • Дисциплинирует, не даёт делать сотни веток "а попробую я это", "это не работает с квестой, временный костыль" и т.д.
  • Можно прогонять большие наборы тестов автоматически ночью, а с утра разбирать логи.
  • Система масштабируется как по размеру команды, так и по сложности кода. Все разрабы довольны.

Наш случай это когда разрабатывается RTL, софт для встроенного проца + математика. Три независимые команды. RTL делает несколько людей. Совместная разработка не на уровне счётчиков и автоматов (хотя и делаем совместные code review), а на уровне интерфейсов между блоками. Кто-то делает блок памяти, кто-то математический блок, кто-то интегрирует внешнюю память и CI/CD гарантирует что у нас получится один проект с новейшей кодовой базой, а не три несовместимых.

Так что очень рекомендую.

 

Share this post


Link to post
Share on other sites

Для pcb-шников встречал такую штуку: https://m.habr.com/ru/company/flipperdevices/blog/554548/ но сам не пробовал, т.к. далек от этого

8 minutes ago, Nick_K said:

P.P.S. А как Вы себе представляете совместную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил.

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

Share this post


Link to post
Share on other sites
1 minute ago, OparinVD said:

есть принципиальные отличия между sw и hw разработчиками

Я скажу больше - есть огромное отличие от SW и HW. При некоторой сноровке, HW может спалить продукт или превратить в кусок пластика, чего в SW не получится при любом усердии. Принципы мышления абсолютно разные, оперируемые понятыя - абсолютно разные, тип разработки тоже разный (по сути это о Вашем вопросе).

Да для разработки используются одинаковые инструменты, но на этом сходство и заканчивается. SW не будет писать тестбенч для обычного счётчика, а здесь это ровная тема (особенно если нужен счётчик с пресетом и счётом на -1 значение и т.д.). Это я условно.

Share this post


Link to post
Share on other sites

Если рассматривать целиком hw сферу, то, конечно да... У меня работающая из коробки Alveo, спалить ее своим проектом я пожалуй не смогу :)) (надо было с этого начать, пардон)

Share this post


Link to post
Share on other sites
2 minutes ago, OparinVD said:

Если рассматривать целиком hw сферу, то, конечно да... У меня работающая из коробки Alveo, спалить ее своим проектом я пожалуй не смогу :)) (надо было с этого начать, пардон)

Я не конкретно к Вашему примеру. Скорее что лет 5 так можно было легко сделать, превратить 10К$ в металлолом. Сейчас конечно и защиты побольше и синтез-имплементация поумнее с проверками разными.

Но при некоторой сноровке... :dance:

Share this post


Link to post
Share on other sites
1 hour ago, one_eight_seven said:

Например, оба добавили свои блоки в общий файл сборки, например, в Makefile.

Во! Про файлы сборки-то я и забыл, на них мы вполне пересекаемся... сюда же наверно и какие-то rtl-топлевелы могут добавиться. В общем и целом тогда понятно, спасибо.

 

40 minutes ago, count_enable said:

Мы построили CI/CD систему с тестированием коммитов на железе

а тест-бенчи для rtl у Вы на CI-сервере запускаете или локально? или наверно тут есть смысл делить модульные тесты и некий общий функциональный тест-бенч :scratch_one-s_head:

Share this post


Link to post
Share on other sites
1 hour ago, Nick_K said:

Я скажу больше - есть огромное отличие от SW и HW.

SW гораздо опаснее, так как оно гораздо больше (тупо по количеству строк кода)

из мировой практики - вспомнилось как израильтяне поломали иранские центрифуги софтом.

из личного опыта - несколько раз было, что обкирпичивались пользовательские устройства от неправильного софта, а от прошивки ПЛИС такого ни разу не было

-----------------

по теме - мы мёржим RTL с разных веток - мое мнение - важно правильное тестирование (с хорошим покрытием), а не всякие сложные правила писания кода  

Share this post


Link to post
Share on other sites
3 часа назад, count_enable сказал:

Мы построили CI/CD систему с тестированием коммитов на железе. Очень улучшает жизнь и качество проектов, даже если блок делается одним разработчиком.

Очень интересно! Сразу куча вопросов:

  1. До какого уровня CI дотягивает проект? Всякий раз - до железа, или до симулятора?
  2. Если до железа, как часто происходит CI? Если это ночные билды, то хватает ли времени на полный имплемент с таймингами?
  3. А если тайминг в билде до железа за отведенное время не вытягивается, это фейл?
  4. Тестирование коммитов на железе - значит, в системе имеется автомат тестирования железа, который в том числе управляет питанием аппаратуры, прошивкой, автозапуском тестов?
  5. Опять-таки, тестирование на железе предполагает наличие автоматических тестовых стендов для всего создаваемого под CI/CD оборудования? Это в софте не страшно - если прилетает коммит в проект, который обновляли три года назад, CI его исправно отработает. А в железе это значит годы держать подключенный стенд в рабочем состоянии.
  6. До какой точки доходит CD (и как часто это происходит)? Полный релизный набор выходных файлов и документов после каждого коммита?

Share this post


Link to post
Share on other sites
10 hours ago, Nick_K said:

P.P.S. А как Вы себе представляете совместную разработку? У тебя вот тут счётчик странный, давай я тебе "впаяю" туда регистров побольше? Или вот тут автомат не концептуальный, давай я на комбинационный дежифратор поменяю? Есть требования, есть интерфейс взаимодействия - каждый работает согласно этих правил.

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

На находите, что смысл никак не меняется?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.