Гибкая телеметрия в OVHCloud - Часть III

Эта статья является третьей в серии статей, мы рекомендуем сначала прочитать часть 1 и часть 2:

  • Рождение гибкой телеметрии в OVHcloud — Часть I
  • Гибкая телеметрия в OVHCloud — Часть II

В последнем посте, посвященном гибкой телеметрии, мы сосредоточимся на микровидении. В любом проекте разделение микро и макро видения жизненно важно для эффективного общения.

Макро и Микровидение

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



Микровидение



Три блока данных

В этой части нашей панели инструментов отображаются три важных элемента информации, касающихся хода наших спринтов: ожидаемое, неожиданное и причина неожиданного.



BurdownChart

(1) Это прогресс текущего спринта и его процент завершения. Процент выполнения просто вычисляется:



(2) Это показывает, сколько раз команда разработчиков выходила из спринта, чтобы что-то исправить, и время завершения. На прилагаемом графике показаны пиковые дни, когда команда была мобилизована.



Чтобы сообщить об этом типе информации:

  • Команды добавляют в поле «Ярлык» JIRA заголовок: препятствие.
  • Они регистрируют время, проведенное в поле «Журнал работы» в JIRA.



Накопленная информация затем отображается на нашей панели инструментов. Это помогает нам понять, почему спринт не продвигается. Когда команды проводят недели на устранение неполадок, мы можем объяснить почему.

NB: Важно отделить спринт от препятствий. Эти две части информации позволяют сравнить «ожидаемое» и «неожиданное». Это позволяет предложить 2 типа графиков.

(3) В последней части рассказывается, почему команды вмешались, когда они вышли из спринта. Эти ценные данные дают нам четкое представление о ситуации. Если команда тратит 90% своего времени на устранение ошибок или устранение неполадок в поддержке, это дает информацию о процессах принятия решений для будущих проектов.



Природа препятствия

Пример: мы предоставляем 30 часов на исправление ошибок во время спринтов; должны ли мы сосредоточиться на создании чего-то нового или сокращении технического долга?

Вывод: Сегодня Agile-телеметрию используют 19 команд в OVHCloud. Это облегчает и позволяет нам измерять производительность и прогресс команд удаленно и в режиме реального времени. Он также предоставляет нам актуальную информацию, необходимую для реализации наших проектов. Именно эта методология получила награду Innovations Awards для сотрудников OVHCloud.

Если вы хотите погрузиться в Agile Telemetry, вы можете сделать это прямо сейчас!!! Просто возьмите нашу панель инструментов с открытым исходным кодом и нашего бота Jerem — github.com/ovh/jerem.

Гибкая телеметрия в OVHCloud - Часть II

В предыдущем посте мы изложили причины, которые побудили нас создать инструмент Agile-мониторинга. Чтобы извлечь выгоду из этого коллективного успеха, нам нужно было:

  • Установите эффективную, простую и общепринятую методологию поддержки команд разработчиков.
  • Изложите различные видения, необходимые для правильного выполнения проекта.
  • Определите микровидение для команд разработчиков.
  • Определите макро-видение для спонсоров.
  • Индустриализируйте эту инновационную концепцию для других команд в OVHcloud.



Как и в каждой новой задаче, в ней был элемент сложности. OVHcloud — международная компания, и наши команды распределены по всему миру. Поэтому инструмент должен был быть легко читаемым и простым в обслуживании, а показатели должны обновляться автоматически, поскольку наши команды работают в меняющемся контексте, где часто происходят незапланированные события.

Нам нужно было создать инструмент, который позволил бы нам удаленно измерять производительность и прогресс команд в режиме реального времени и обновлять информацию, необходимую для управления проектом. Это наша телеметрия.

«Прежде чем привлекать команду разработчиков, составьте план строительства… нарисуйте!» Помня об этом, я начал набрасывать несколько набросков на блокноте, а затем на программном обеспечении.

Первый каркас гибкой телеметрии

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

Но как заставить эту доску ожить?

В OVHcloud мы используем инструмент для продажи билетов: JIRA. Этот инструмент помогает нам в повседневной организации проектов. Однако он не показывает нужную нам информацию. Тем не менее, мы можем заставить его говорить…



Основываясь на этой концепции, мы и наши команды создали таблицу показателей с помощью инструмента GRAFANA.

Это наша гибкая телеметрия



В этом втором посте блога мы сосредоточимся на макро видении. В следующем посте мы рассмотрим микровидение.

Макровидение



1- й блок данных: Квартальные КПЭ



  • (А) Предсказуемость. Сможете ли вы выполнить все проекты / запросы? С помощью этого индикатора высшее руководство и команды разработчиков могут отслеживать свои возможности в отношении сроков. Мы можем отслеживать эти данные по следующей формуле:



  • (B) Прогресс на четверть . Показывает завершенные части квартала.
  • © Скорость команды. Количество сюжетных пунктов, завершенных за день. Обладая этой информацией, мы можем строить наши будущие спринты и поддерживать ритм команды.
  • (D) Среднее препятствие . Эта информация важна для построения следующего спринта и оценки коэффициента безопасности.

Пример

Предположим, у нас есть команда из семи человек с производительностью 350 часов на спринт (7 человек x 5 часов в день x 10 дней). Если наша команда зафиксировала 58 часов в качестве препятствий во время спринта, мы могли бы использовать эту информацию, чтобы настроить коэффициент безопасности для следующего спринта.



В среднем команда тратит 17% своего времени на устранение препятствий во время спринта. Имея эту информацию, мы можем рассчитать коэффициент безопасности.

2-й блок данных: «Sum of Roadmap Epics»



В этой таблице собраны ожидаемые эпопеи. Он показывает количество очков истории, оцененных командами, количество очков, которые они уже выполнили, количество задач, «не оцененных», и скорость прогресса. С помощью этой таблицы мы можем дать цифры, относящиеся к прогрессу.

3-й блок данных: Завершение



  1. Эпическое завершение ( 1 ): в течение каждой недели мы можем наблюдать за развитием дорожной карты. Иногда мы видим, что дорожная карта завершения сокращается. Это нормально, потому что мы добавили в план сюжетную линию. ( 4 )
  2. Количество препятствий (2): это количество раз, когда команды выходили из спринта из-за препятствий.
  3. Длительность препятствий (3): общее время, потраченное на препятствия.
  4. Запланированная дельта-точка истории (4): количество точек, входящих или выходящих из дорожной карты, что позволяет нам видеть любые вариации на графиках.

4- й блок данных: Нарисуйте график!



  • А. Этот рисунок представляет собой график выполнения дорожной карты. Он создан по сумме завершенных эпосов.
  • Б. Наша дорожная карта выгорания.

На этом графике представлены две кривые:

  • a  — Кривая элементов, количественно определенная и оцененная командами.
  • b  — это предел, рассчитанный с использованием скорости команды по количеству дней в квартале. Затем мы добавляем коэффициент безопасности команды.





  • c — Кривая задач, выполненных командами.

Вывод

Эта панель инструментов объединяет всю информацию, которую нам удалось собрать воедино благодаря потрясающему вкладу команд. Веруя в ценности и доверяя методу, группа уже достигла зрелости, которой они достигли сами.

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

В следующем посте я подробно расскажу о микровидении. А пока сохраняйте Agile!

Jerem: Agile-бот

В OVHCloud мы открываем исходный код для нашего проекта «Agility Telemetry». Джерем , как наш сборщик данных, является основным компонентом этого проекта. Джерем регулярно очищает нашу JIRA и извлекает определенные показатели для каждого проекта. Затем он пересылает их в наше приложение для длительного хранения, платформу данных метрик OVHCloud .



Концепции Agility с точки зрения разработчика

Чтобы помочь вам понять наши цели для Jerem , нам нужно объяснить некоторые концепции Agility, которые мы будем использовать. Во-первых, мы составим техническую ежеквартальную дорожную карту для продукта, в которой изложены все функции, которые мы планируем выпускать каждые три месяца. Это то, что мы называем эпосом .

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

Затем, чтобы продвинуть нашу дорожную карту, мы будем проводить регулярные спринты, которые соответствуют периоду в десять дней , в течение которого команда выполнит несколько задач. Количество очков истории, набранных в спринте, должно соответствовать или быть близким к скорости команды . Другими словами, среднее количество очков истории, которое команда может набрать за день.

Однако во время спринтов могут неожиданно возникнуть другие срочные задачи. Это то, что мы называем препятствием . Например, нам может потребоваться помощь клиентам, исправление ошибок или срочные инфраструктурные задачи.   

Как работает Джерем

В OVH мы используем JIRA для отслеживания нашей активности. Наш Jerem бот обрывки наших проектов из JIRA и экспорта всех необходимых данных для нашей OVHCloud Метрики платформы данных . Джерем также может передавать данные в любую базу данных, совместимую с Warp 10. В Grafana вы просто запрашиваете платформу Metrics (используя источник данных Warp10 ), например, с помощью нашей панели управления программами . Все ваши KPI теперь доступны на красивой панели инструментов!



Откройте для себя показатели Jerem

Теперь, когда у нас есть обзор основных задействованных концепций Agility, давайте погрузимся в Джерема! Как преобразовать эти концепции гибкости в показатели? Прежде всего, мы извлечем все показатели, относящиеся к эпикам (т.е. новым функциям). Затем мы подробно рассмотрим метрики спринта.

Эпические данные

Чтобы объяснить эпические метрики Джерема, мы начнем с создания новой. В этом примере мы назвали это Agile Telemetry. Мы добавляем лейбл Q2-20, что означает, что мы планируем выпустить его во втором квартале. Чтобы записать эпопею с Джеремом, вам нужно установить четверть для окончательной доставки! Затем мы просто добавим четыре задачи, как показано ниже:



Чтобы получить метрики, нам нужно оценить каждую отдельную задачу. Мы сделаем это вместе на подготовительных сессиях. В этом примере у нас есть собственные очки истории для каждой задачи. Например, мы оценили write a BlogPost about Jeremзадачу на 3.



В результате у Джерема теперь есть все необходимое, чтобы начать сбор эпических показателей. В этом примере представлены пять показателей:

  • jerem.jira.epic.storypoint
    : общее количество очков истории, необходимых для завершения этой эпопеи. Значение здесь 14 (сумма всех очков эпической истории). Этот показатель будет развиваться каждый раз, когда эпик обновляется путем добавления или удаления задач. 
  • jerem.jira.epic.storypoint.done
    : количество выполненных задач. В нашем примере мы уже выполнили 
    Write Jerem bot
    и 
    Deploy Jerem Bot
    , поэтому мы уже выполнили восемь пунктов истории.
  • jerem.jira.epic.storypoint.inprogress
    : количество «выполняемых» задач, например 
    Write a BlogPost about Jerem
    .
  • jerem.jira.epic.unestimated
    : количество неоцененных задач, как 
    Unestimated Task
    в нашем примере.
  • jerem.jira.epic.dependency
    : количество задач, у которых есть метки зависимостей, указывающие, что они являются обязательными для других эпиков или проектов.



Таким образом, для каждого эпика в проекте Джерем собирает пять уникальных показателей.

Данные спринта

Для выполнения грандиозных задач мы работаем по спринту . Выполняя спринты, мы хотим подробно рассказать о наших достижениях . Вот почему Джерем тоже собирает данные о спринтах!

Итак, давайте откроем новый спринт в JIRA и начнем работать над нашей задачей. Это дает нам следующее представление JIRA:



Джерем собирает следующие показатели для каждого спринта:

  • erem.jira.sprint.storypoint.total
    : общее количество очков истории, набранных в спринт.
  • jerem.jira.sprint.storypoint.inprogress
    : сюжетные точки, которые в настоящее время выполняются в рамках спринта.
  • jerem.jira.sprint.storypoint.done
    : количество очков истории, набранных на данный момент за спринт.
  • jerem.jira.sprint.events
    : даты начала и окончания спринта, записанные как строковые значения Warp10.



Как вы можете видеть в представлении «Показатели» выше, мы будем записывать каждую метрику спринта дважды. Мы делаем это, чтобы быстро просмотреть активный спринт, поэтому мы используем метку «текущий». Это также позволяет нам запрашивать прошлые спринты, используя настоящее имя спринта. Конечно, активный спринт также можно запросить по его имени.

Данные о препятствиях

Запуск спринта означает, что вам нужно знать все задачи, над которыми вам придется работать в течение следующих нескольких дней. Но как мы можем отслеживать и измерять незапланированные задачи? Например, очень срочное для вашего менеджера или товарища по команде, которому нужна небольшая помощь?

Мы можем добавить в JIRA специальные билеты, чтобы отслеживать выполнение этой задачи. Это то, что мы называем «препятствием». Они маркируются в соответствии с их природой. Если, например, постановка требует вашего внимания, то это препятствие «Инфра». Вы также получите метрики для «Всего» (все виды препятствий), «Избыточности» (незапланированные задачи), «Поддержка» (помощь товарищам по команде) и «Исправление ошибок или другое» (для всех других видов препятствий).

Каждое препятствие принадлежит активному спринту, в котором оно было закрыто. Чтобы закрыть препятствие, вам нужно только пометить его как «Готово» или «Закрыто».

Мы также получаем такие показатели, как:

  • jerem.jira.impediment.TYPE.count
    : количество препятствий, возникших во время спринта.
  • jerem.jira.impediment.TYPE.timespent
    : количество времени, затраченного на устранение препятствий во время спринта.

TYPE соответствует виду зафиксированного препятствия. Поскольку мы не обнаружили никаких реальных препятствий, Джерем собирает только totalметрики.



Чтобы начать запись препятствий, мы просто создаем новую задачу JIRA, в которую добавляем метку «препятствие». Мы также устанавливаем его характер и фактическое время, потраченное на это.



В качестве препятствия мы также извлекаем глобальные метрики, которые всегда записывает Джерем:

  • jerem.jira.impediment.total.created: время, затраченное с даты создания на устранение препятствия. Это позволяет нам получить общее количество препятствий. Мы также можем записывать все действия с препятствиями, даже вне спринтов.

Для одного проекта Jira, как в нашем примере, вы можете ожидать около 300 показателей. Это может увеличиваться в зависимости от эпика, который вы создаете и помечаете в Jira, и того, который вы закрываете.

Панель управления Grafana

Нам нравится создавать информационные панели Grafana! Они дают команде и менеджеру много информации о ключевых показателях эффективности. Лучшее в этом для меня, как разработчика, — это то, что я понимаю, почему хорошо выполнять задачу JIRA!

На нашей первой панели управления Grafana вы найдете все лучшие KPI для управления программами. Начнем с глобального обзора:

Обзор квартальных данных



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

Данные активного спринта



Активная панель данных спринта часто оказывается отличной поддержкой во время наших ежедневных встреч. На этой панели мы получаем краткий обзор достижений команды и можем установить время, потраченное на параллельные задачи.

Подробные данные



В последней части представлены более подробные данные. Используя переменную epic Grafana, мы можем проверять конкретные эпики, а также завершение более глобальных проектов. У вас также есть velocity chart, который отображает прошлый спринт и сравнивает ожидаемые баллы истории с фактически завершенными.

Панель управления Grafana доступна напрямую в проекте Jerem. Вы можете импортировать его прямо в Grafana, если у вас настроен действительный источник данных Warp 10.

Чтобы панель управления работала должным образом, вам необходимо настроить переменную проекта Grafana в виде списка WarpScript [ 'SAN' 'OTHER-PROJECT' ]. Если наш программный менеджер может это сделать, я уверен, вы сможете!

Настройка Jerem и автоматическая загрузка данных управления программами дают нам много полезного. Мне как разработчику это очень нравится, и я быстро привык отслеживать в JIRA гораздо больше событий, чем раньше. Вы можете напрямую видеть влияние ваших задач. Например, вы видите, как быстро продвигается дорожная карта, и можете определить любые узкие места, которые создают препятствия. Затем эти узкие места становятся эпопеями. Другими словами, как только мы начинаем использовать Jerem, мы просто заполняем его автоматически! Надеюсь, вам тоже понравится! Если у вас есть отзывы, мы будем рады их услышать.

Рождение гибкой телеметрии в OVHcloud - Часть I

В октябре 2018 года, незадолго до саммита OVHcloud, я присоединился к платформе Product Unit Platform в качестве менеджера программы. С этой новой ролью возникла новая задача… поддержать команду, работающую над новым продуктом: OVHcloud Managed Kubernetes. Крайний срок был коротким, у нас было много дел, и нам нужно было обеспечить видимость как для менеджеров, так и для команд разработчиков. Но как программный менеджер у меня в сумке были нужные инструменты: SCRUM и agility.



Моим первым действием, как новичком, было попросить команду выразить себя. Я хотел понять, как работает группа, поскольку слушание — один из первых шагов в процессе гибкого строительства.

Имея дело со значительными изменениями, необходимо управлять изменениями и сопровождать людей на протяжении всего процесса. Слишком часто слово «agile» употребляется таким образом, чтобы жертвовать здравым смыслом, становясь козлом отпущения, когда происходят непредвиденные события или задержки в доставке. Ключевой задачей было успокоить команду и объяснить им, что гибкость не сделает их жизнь тяжелее или добавит накладных расходов к повседневным задачам. Мы добились этого несколькими способами:

  • Организация нескольких презентаций и методических занятий
  • Проведение личных встреч с командами в Париже и Лионе 
  • Объяснение того, как метод будет работать во время реального спринта
  • C ollectively разрабатывает руководство для нашей реализации метода SCRUM 

После того, как мы вместе проверили основы, мы перешли к методологии. На этом этапе мы могли бы начать добавлять ценность проекту, используя гибкость.

Ценность нашей маневренности

После нескольких спринтов с использованием гибкого метода наша группа обрела некоторую стабильность, то есть мы достигли хорошей «скорости», как мы называем это на сленге практиков Agile. Скорость — важная ценность и определяющий фактор в нашем постоянном движении к гибкой телеметрии.

Чтобы быстро (пере) определить это, скорость — это количество «очков усилий», которые команда может выполнить во время спринта. Этот ключевой показатель позволил нам оценить, сколько работы наша команда могла бы выполнить за определенный период времени.

Скорость и усилия в нашем проекте Managed Kubernetes

Давайте посмотрим на упрощенную схему того, как этот метод работал в нашем проекте Managed Kubernetes:



Здесь у нас есть три основных шага. Для каждого из них мы собрали количественные значения, чтобы получить консолидированное представление о скорости каждого шага в дополнение к глобальному обзору всего проекта. С такими скоростями мы получили хорошее представление о продвижении проекта и некоторую видимость сроков.



Пример:



Эта гибкая модель позволила нам достичь нашей цели и вовремя доставить проект Managed Kubernetes нашим клиентам, и этот успех впоследствии побудил нас поделиться этими передовыми методами со всеми командами в подразделении продукта.

Но возникла вторая проблема, так как поддержание этого процесса требовало большой дисциплины, с многочисленными возможностями для совершения ошибок. Итак, нашим следующим шагом было создание инструмента, способного снизить риск ошибки, сохраняя при этом полную видимость проектов как на макро-, так и на микроуровне. Это то, что мы подробно представим в следующем сообщении блога: Agile-телеметрия от OVHcloud.

Использование ПЛИС в рабочем процессе гибкой разработки

OVHcloud недавно получил новое имя, чтобы подчеркнуть свою направленность: облако, чтобы дать вам возможность легко запускать свои рабочие нагрузки, не слишком заботясь о базовом оборудовании. Так зачем говорить о ПЛИС?

FPGA — это аппаратный ускоритель, реконфигурируемый чип, который может вести себя как заказной кремний, разработанный для конкретного приложения. Мы используем ПЛИС в качестве настраиваемых сетевых устройств для нашей системы защиты от атак. Но разработка ПЛИС сильно отличается от разработки программного обеспечения: она требует специализированного проприетарного программного обеспечения и длительных циклов разработки.



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

Зачем использовать ПЛИС?
ПЛИС — чрезвычайно универсальные микросхемы, их можно использовать для построения схем для очень широкого круга приложений:

  • обработка сигнала
  • финансы
  • машинное обучение (классификация)
  • сеть

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

Для сетевых приложений преимущества:

  • прямое подключение к каналам 100GbE: нет сетевой карты, нет канала PCIe, пакеты принимаются непосредственно на чип
  • доступ к памяти с чрезвычайно низкой задержкой и очень быстрым произвольным доступом (QDR SRAM: каждый банк позволяет около 250 миллионов операций чтения и записи в секунду)
  • возможность создавать собственные конвейеры обработки пакетов для максимального использования ресурсов чипа.

Это позволяет нам обрабатывать 300 миллионов пакетов в секунду и 400 Гбит / с на одной плате FPGA с потребляемой мощностью менее 70 Вт.

Чтобы узнать больше о ПЛИС, хорошим ресурсом является электронная книга ПЛИС для чайников.

Традиционный рабочий процесс разработки FPGA

Языки, используемые для разработки на ПЛИС, имеют сильную специфику: в отличие от стандартных последовательных языков все происходит параллельно, чтобы моделировать поведение миллионов транзисторов, работающих параллельно на кристалле. Используются два основных языка: VHDL и SystemVerilog. Мы используем SystemVerilog. Вот пример модуля SystemVerilog:

// Simple example module: a counter
// Will clear if clear is 1 during one clock cycle.
// Will increment at each clock cycle when enable is 1.
 
`timescale 1ns / 1ps
 
module counter
    #(
        // Number of bits of counter result
        parameter WIDTH = 5
    )
    (
        input                    clk,
 
        // Control
        input                    enable,
        input                    clear,
         
        // Result
        output reg [WIDTH-1:0]   count = '0
    );
 
    always_ff @(posedge clk) begin
        if (clear) begin
            count <= '0;
        end else if (enable) begin
            count <= count + 1;
        end
    end
 
endmodule


Модули можно объединять вместе, соединяя их входы и выходы для создания сложных систем.

Тестирование на тренажере

Очень важным инструментом при разработке на ПЛИС является симулятор: тестировать код непосредственно на реальной ПЛИС сложно и медленно. Чтобы ускорить процесс, симуляторы могут запускать код без специального оборудования. Они используются как для модульных тестов, чтобы протестировать каждый модуль в отдельности, так и для функциональных тестов, имитирующих всю конструкцию, контролирующих ее входы и проверяющих ее выходы. Вот результат на модуле счетчика:



Это волна, показывающая значение каждого сигнала в каждом тактовом цикле. Конечно, симулятор также может работать без головы, и тестовая среда может быть модифицирована так, чтобы возвращать результат прошел / не прошел.

Базовый симулятор предоставляется Xilinx, производителем FPGA. Более продвинутые симуляторы предоставляются Mentor или Synopsys. Эти тренажеры являются коммерческими и требуют дорогих лицензий.

Создание двоичного файла

Как только все тесты пройдены, пора получить двоичный файл, который можно использовать для настройки FPGA. Крупнейшие поставщики FPGA, Intel и Xilinx, предоставляют собственные инструменты для этого процесса. Первый этап, синтез, преобразует исходный код в схему. Вторая фаза, «место и маршрут», представляет собой очень сложную задачу оптимизации, чтобы подогнать схему к ресурсам, предоставляемым ПЛИС, при соблюдении временных ограничений, чтобы схема могла работать на желаемой частоте. Это может длиться несколько часов, даже до одного дня для очень сложных конструкций. Этот процесс может завершиться неудачно, если дизайн чрезмерно ограничен, поэтому обычно приходится запускать несколько процессов с разными начальными числами, чтобы иметь больше шансов получить рабочий двоичный файл в конце.

Наш текущий рабочий процесс разработки FPGA

Наш текущий процесс разработки очень близок к традиционному. Но обычно разработка FPGA намного медленнее, чем разработка программного обеспечения. В OVHcloud мы можем разработать и отправить небольшую функцию за один день. Мы достигаем этого, используя рабочий процесс, используемый разработчиками программного обеспечения, и нашу облачную инфраструктуру. Вот глобальный рабочий процесс:



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

Использование нашего публичного облака

Настройка всех машин выполняется Ansible. Есть несколько важных ролей для установки различных важных компонентов:

  • симулятор
  • компилятор Xilinx, Vivado
  • компилятор Intel, Quartus
  • сервер лицензий для симулятора и компиляторов

Сервер лицензий, а также блоки разработки — это давно работающие экземпляры общедоступного облака. Сервер лицензий — это наименьший из возможных экземпляров, ящик для разработки — это экземпляр с быстрым процессором и большим объемом оперативной памяти. Симулятор и компиляторы устанавливаются на модуле разработки. Авторизациями для доступа к серверу лицензий управляют группы безопасности OpenStack.

Экземпляры, используемые для моделирования тестов и для компиляции, при необходимости запускаются с использованием OpenStack API. Это очень важно, поскольку позволяет запускать несколько наборов тестов параллельно для разных разработчиков. Это также очень важно для составления. Мы компилируем наши проекты для нескольких целей (ПЛИС Stratix V для 10 Гбайт и ПЛИС Ultrascale + для 100 Гбайт), поэтому нам необходимо выполнять несколько заданий компиляции параллельно. Кроме того, мы запускаем задания параллельно с несколькими начальными числами, чтобы повысить наши шансы получить правильный двоичный файл. Поскольку сборка наших проектов может длиться 12 часов, очень важно начать достаточно параллельно, чтобы быть уверенным, что мы получим хотя бы один рабочий двоичный файл.

Запуск тестов

Функциональные тесты очень важны, потому что они проверяют каждую функцию, предоставляемую нашими проектами. Тесты разработаны на Python с использованием scapy для отправки трафика и анализа результатов. Они могут работать как с имитацией проекта, так и с реальным дизайном на реальных платах FPGA. CDS может автоматически запускать тесты на реальных платах, зарезервировав лабораторные серверы и подключившись к ним через SSH. Тот же процесс используется для тестов производительности.

Результатом такой инфраструктуры является то, что разработчики могут разместить новую функцию в ветке нашего репозитория git, и они получат полные результаты модульных и функциональных тестов через 30 минут. Если все в порядке, они могут запустить компиляцию и проверить результат на борту на следующий день. Затем им просто нужно пометить новую версию пакета, чтобы появилась новая версия. После этого команда, управляющая производством, может развернуть новую версию с помощью ansible.

Идти дальше

Мы максимально автоматизировали наш процесс и используем инфраструктуру общедоступного облака для ускорения рабочего процесса. Но в настоящее время мы все еще используем вполне традиционный процесс разработки FPGA. Существует множество различных подходов для дальнейшего развития, и, поскольку мы хотим приблизить процесс разработки FPGA к разработке программного обеспечения, мы рассмотрели многие из них.

HLS

Очень распространенный подход — использовать синтез высокого уровня (HLS). Он заключается в использовании языка высокого уровня для разработки модулей вместо SystemVerilog. С Vivado HLS можно разрабатывать на C ++. Также возможно использование OpenCL, который мы протестировали на платах Intel. Принцип HLS состоит в том, чтобы извлечь алгоритм из кода высокого уровня, а затем автоматически построить лучшую конвейерную архитектуру на FPGA. Но мы занимаемся обработкой пакетов, наши алгоритмы очень простые. Сложность нашего кода заключается в самой архитектуре, позволяющей поддерживать очень высокие скорости передачи данных. Таким образом, мы не смогли эффективно использовать HLS, код, который мы получили, был на самом деле более сложным, чем та же функция в SystemVerilog.

Долото

SystemVerilog является чрезвычайно низкоуровневым и не позволяет использовать высокий уровень абстракций (по крайней мере, если вы хотите, чтобы код можно было использовать компиляторами Intel и Xilinx). Что нам действительно нужно для упрощения разработки, так это возможность использовать более высокие уровни абстракции. Нам не нужен сложный компилятор, чтобы попытаться угадать лучшую архитектуру. Для этого у нас есть аспирант, который в настоящее время участвует в проекте с открытым исходным кодом: Chisel.

Chisel — это язык проектирования оборудования, основанный на Scala. Его главный интерес заключается в том, что он позволяет использовать весь уровень абстракции, предлагаемый Scala, для описания оборудования. Это также полностью открытый код, что очень необычно в мире разработки оборудования. Для тестирования он использует Verilator, симулятор с открытым исходным кодом. Это означает, что мы можем избавиться от проприетарных симуляторов и иметь полностью открытый набор инструментов, вплоть до компиляции.

В настоящее время нет инструментов с открытым исходным кодом для фазы размещения и маршрута, по крайней мере, на самых последних ПЛИС Xilinx и Intel. Но Chisel может генерировать Verilog, который может использоваться проприетарными компиляторами.

Мы планируем в ближайшее время использовать в производстве наши первые модули, разработанные в Chisel. Это должно помочь нам получить более удобный для повторного использования код и постепенно избавиться от проприетарных инструментов.

Смена парадигмы

Сообщество с открытым исходным кодом чрезвычайно важно для того, чтобы сделать разработку FPGA все ближе и ближе к разработке программного обеспечения. Признаком улучшения является постепенное появление ПЛИС начального уровня в FabLabs и проектах электроники для хобби. Мы надеемся, что Xilinx и Intel FPGA последуют за ними, и что однажды они перейдут на открытый исходный код для своих компиляторов, что может сделать их более эффективными и совместимыми. ПЛИС — это ускорители, которые предлагают невероятную гибкость и могут быть мощной альтернативой центральным и графическим процессорам, но для демократизации их использования в облачных средах сообществу открытого исходного кода необходимо стать намного сильнее.