[count_enable 0]

Каждый разработчик пишет свои тестбенчи, во время разработки блока они выполняются локально. Когда блок коммитится, добавляются тесты на регрессию и производительность в  CI/CD. Но должен сказать что упор у нас всё же делается на тесты на железе.

16 hours ago, Flood said:

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

1. Есть несколько задач. Сначала простой "дымовой тест" что код синтезировался\скомпилировался. Потом тесты на симуляторе. Потом на железе. Есть пайплайны для железа и для софта. Разработчик может сам выбирать нужную глубину.

2. Да, ночи хватает на синтез и полный набор тестов.

3. Да, иногда у нас были фейлы из-за таймаута, дали запас по времени.

4,5. Мы разрабатываем ускорители, со внешним железом плисина не особо взаимодействует.

6. Нам хватает логов. При необходимости фризим.

[Flood 12]

3 часа назад, count_enable сказал:

4,5. Мы разрабатываем ускорители, со внешним железом плисина не особо взаимодействует.

В принципе, с этого и нужно было начинать.

Получается, софтовая идеология CI/CD реализуема для FPGA проектов, практически неотличимых от софтовых (с поправкой на время компиляции).

Хотя понятно что нельзя все грести под одну гребенку - есть как FPGA проекты, похожие по сути на софт для CPU / GPU, так и ПО, управляющее железом во внешнем окружении - сложность автоматизированного тестирования тут будет зависеть не от природы платформы, а от решаемой задачи.

[RobFPGA 27]

Приветствую!

8 minutes ago, Flood said:

Получается, софтовая идеология CI/CD реализуема для FPGA проектов, практически неотличимых от софтовых (с поправкой на время компиляции).

Не только на время  компиляции.  Нужно еще учитывать то что для софта если тесты прошли то софт уже готов,  а для FPGA есть этап P&R  который  не всегда  заканчивается успешно даже для правильного с точки зрения функциональности тестов дизайнов. А этап физ. имплементация P&R тяжело поддается автоматизации сборки в пиплайне CI/CD особенно для сложных  дизайнов.      

 

Удачи! Rob.    

[nice_vladi 1]

Вообще, т.н. hardware in the loop имеет место быть. Например:

https://inspirehep.net/files/06c877a9ec568472aac84923dd0056a3

Правда затраты времени на организацию всего этого и написания тестов... Разве что для проектов с очень длительным сроком жизни. Что бы время, потраченное на организацию тестов и стенда равномерно размазалось на много лет

[warrior-2001 0]

1 час назад, nice_vladi сказал:

т.н. hardware in the loop имеет место быть

Это актуально для КИТов. Для реального железа разработать полноценный цифровой двойник - работа крайне кропотливая. Разве что реально - на много лет.

[syoma 1]

Мы пробуем сделать CI для проектов на ПЛИС. Пока дошли до возможности делать синтез и P&R на сервере. На этом все. 

Фактически основная проблема, что почти всю инфраструктуру нужно лепить с нуля, готовых решений нет. И вторая основная проблема - HW тестирование. У нас ПЛИС управляет силовой электроникой и для полноценного HIL нужен симулятор за пару сотен килобаксов. Никто его в CI не отдаст.   

[Flood 12]

7 часов назад, RobFPGA сказал:

Не только на время  компиляции.  Нужно еще учитывать то что для софта если тесты прошли то софт уже готов,  а для FPGA есть этап P&R  который  не всегда  заканчивается успешно даже для правильного с точки зрения функциональности тестов дизайнов. А этап физ. имплементация P&R тяжело поддается автоматизации сборки в пиплайне CI/CD особенно для сложных  дизайнов. 

Говоря про софтоподобный дизайн, я имел ввиду именно кейс чего-то вроде акселератора, например, аппаратного кодирования видео с тестами на конечном железе. Тогда в CI входит полный цикл сборки, включая P&R с дальнейшим запуском на локальном или AWS-подобном облачном железе с набором тестов.

[RobFPGA 27]

Приветствую!

12 minutes ago, Flood said:

Говоря про софтоподобный дизайн, я имел ввиду именно кейс чего-то вроде акселератора, например, аппаратного кодирования видео с тестами на конечном железе.

Ну вот сейчас мы пытаемся так делать для сетевых акселераторов на FPGA. И если для симуляции и синтеза  как бы все понятно и относительно просто то вот этап P&R  как раз и доставляет кучу проблем в CI.  И именно непредсказуемостью  результата  для тяжелых  дизайнов. 
У меня кучу времени заняло разработка алгоритмов сборки и ваяние хитрых скриптов которые бы хоть как то автоматизировали процесс P&R. Но все одно 100% гарантированного результата сборки при изменениях в RTL даже для уже вполне устоявшегося проекта добиться не получилось. 
А это ломает всю красивую идею  CI 

Удачи!  Rob.

[Flood 12]

1 час назад, RobFPGA сказал:

У меня кучу времени заняло разработка алгоритмов сборки и ваяние хитрых скриптов которые бы хоть как то автоматизировали процесс P&R. Но все одно 100% гарантированного результата сборки при изменениях в RTL даже для уже вполне устоявшегося проекта добиться не получилось. 

Логично, для проектов с тяжелыми таймингами CI так же не идеален, как и для проектов со сложным тестированием на железе. Опять-таки, далеко не все проекты тянут времена на предел. Слышал, что где-то разводят на стратегиях RuntimeOptimized, и фейлов не случается :)

[rkit 1]

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

 

  

On 9/14/2021 at 2:07 PM, Nick_K said:

При некоторой сноровке, HW может спалить продукт или превратить в кусок пластика, чего в SW не получится при любом усердии.

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

[one_eight_seven 3]

2 hours ago, RobFPGA said:

А это ломает всю красивую идею  CI 

Чтобы "сломать" красивую идею CI не обязательно идти так далеко, как в P&R. RTL тоже сам собой не пишется - это человеческий труд. А CI - это то, как его обложить тестами.

[rkit 1]

2 hours ago, one_eight_seven said:

А CI - это то, как его обложить тестами.

CI это непрерывная интеграция разных веток разработки. Как противоположность интеграции на финальном этапе.

[one_eight_seven 3]

7 hours ago, rkit said:

CI это непрерывная интеграция разных веток разработки. Как противоположность интеграции на финальном этапе.

И что?

[syoma 1]

13 hours ago, RobFPGA said:

У меня кучу времени заняло разработка алгоритмов сборки и ваяние хитрых скриптов которые бы хоть как то автоматизировали процесс P&R. Но все одно 100% гарантированного результата сборки при изменениях в RTL даже для уже вполне устоявшегося проекта добиться не получилось. 

Интересно, почему у вас так. У нас вроде как тяжелые проекты на Ultrascale+, P&R занимает часов 6. Неопределенное время сборки или непредсказуемый результат типа 50/50 допустим только на этапе разработки и отладки функционала, когда дизайн еще сырой и требует доводки, но в финальной версии - которая идет в релиз такое не допускается. Будь ласка, реши все проблемы с времянками, чтобы проект гарантированно собирался, и тогда релизь. 

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

[RobFPGA 27]

Приветствую!

45 minutes ago, syoma said:

Интересно, почему у вас так. У нас вроде как тяжелые проекты на Ultrascale+, P&R занимает часов 6.

Наверное потому что этот проект под Quartus и StratixV   И эта неприятность была еще одним из аргументов для миграции на Xilinx.

 

Но что для Qu что для Vv в общем ситуация похожа. Так как правка RTL кода (и правильность этого кода!) не всегда благополучно оканчивается успешным P&R. И это может быть как существенная правка - например добавили еще один DMA канал (хотя опять же, в RTL для этого можно просто 1 параметр изменить), так мелкая и "банальная" правка логики  (например поменяли рабочий фронт клока ) 

 

И это именно потому что IMHO процесс  физ. имплементации это отдельный flow который трудно поддается автоматизации.
Какой основной алгоритм используется для "автоматизации" успешности P&R?  Метод случайного научного тыка  .  Перебираем все возможные комбинации  стратегий или seed-ы в надежде что "авось сойдется". А если не сходится начинаем ручками шаманить с "бубном" констрейнов. 

 

Понятное дело это не для всех проектов так печально.  Но учитывать эту особенность FPGA flow при построении инфраструктуры и процессов CI/CD все же надо.   

 

Удачи! Rob.