[MaratZuev 0]

Всем добра!
Собираемся приступить к этому (не уверен, что нужному, но мимо стандарта не попрёшь) делу.
У кого-то есть опыт использования инструментов от, например, Aldec (по-моему, ещё Mentor умеет, но сходу не нашёл)?

Чтобы сразу обозначить задачу, скажу, что для того, чтобы, в соответствии с вышеупомянутыми стандартами верифицировать (прошивку) ПЛИС, её "окружают" другой ПЛИС, которая, в свою очередь, вкупе с ПО, тестирует первую.

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

[Skryppy 0]

Ну такие стандарты должны сопровождаться печатями, комиссиями. Они вам подскажут как им удобнее принимать, может примеры дадут какие-нибудь. Знаю вроде матлаб как-то тестирует по таким стандартам, но как это работает не в курсе.

[MaratZuev 0]

Это всё есть и будет (есть). А, вообще, я просил конкретики. Уж простите, но вилами по воде совсем не интересно.

[nice_vladi 1]

Можете, действительно, в сторону матлаб посмотреть. Там есть два интересных режима:

1. Co-simulation. Это больше программные тесты, к матлабу подключается questa и матлаб работает с её сигналами.

2. Hardware-in-loop. Тут уже ПЛИС подключается к матлаб и матлаб работает непосредственно с её сигналами. Но там свои заморочки с согласованием интерфейсов в плис-матлаб и т.д.

Наверное вам интереснее 2й вариант. Можно напрямую с целевой плис работать, можно собрать плис dut + плис driver.

[litv 0]

Было  тут

В Матлабе - https://se.mathworks.com/solutions/aerospace-defense/standards/do-254.html 

или тут

https://docs.exponenta.ru/slcheck/ug/model-checks-for-do-178cdo-331-standard-compliance_mw_a52bfc8a-8bd4-4892-a829-4c33a541a75f.html .

 

 

[lexx 0]

13 hours ago, MaratZuev said:

для того, чтобы, в соответствии с вышеупомянутыми стандартами верифицировать (прошивку) ПЛИС, её "окружают" другой ПЛИС, которая, в свою очередь, вкупе с ПО, тестирует первую.

Т.е. необходимо верифицировать FPGA с прошивкой, что он функционально соответствует исходному ТЗ и стандартам описываемым в ТЗ? Но в теме нет стандартов...

[MegaVolt 25]

16 часов назад, MaratZuev сказал:

Чтобы сразу обозначить задачу, скажу, что для того, чтобы, в соответствии с вышеупомянутыми стандартами верифицировать (прошивку) ПЛИС, её "окружают" другой ПЛИС, которая, в свою очередь, вкупе с ПО, тестирует первую.

А JTAG  с его граничным тестирование не сможет заменить внешнюю плис? Или скоростные параметры тоже нужно тестировать?

[MaratZuev 0]

7 hours ago, nice_vladi said:

Наверное вам интереснее 2й вариант.

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

3 hours ago, litv said:

Было  тут

Было, но, думал, что посвежее есть. Матлаб не интересует.

3 hours ago, lexx said:

стандартам описываемым в ТЗ

ТЗ не описывает стандарты, оно на них ссылается

32 minutes ago, MegaVolt said:

А JTAG  с его граничным тестирование не сможет заменить внешнюю плис?

Это - разные вещи. Вы ещё тестер предложите...

[Mad_kvmg 0]

Добра и Вам. 

Вопрос инструментария не первостепенный, нужно начать со стандартов. В оригинальном стандарте DO-254 приведен большой список того на что у вас в компании должен быть стандарт (текстовое описание как вы это делаете). Что касается стандарта жизненного цикла разработки электроники класса А и еще ряда стандартов, то для вас их могут разработать третьи компании. Прямую ссылку давать не буду, компания барс, найдете в интернете. С ними стоит поговорить, они много чего полезного могут рассказать про сертификацию по кт-254. К сожалению, в части программируемой логики за вас они стандарты сделать не смогут, может что и изменилось, но 5 лет назад все, что они смогли сказать относительно стандарта верификации FPGA, это то, что там применяются эвристические методы   

 

Стандарты и методики проектирования и верификации FPGA проектов придется разрабатывать самим. 

Касательно стандарта верификации, то прямо подробно все расписываете как каждый IP core в вашем проекте вы тестируете. Как составляете test plan, что в него входит, какие технологии применяете direst tests, CRT, error injection. Как выглядит отчет о верификации IP Core. Какую метрику используете для оценки качества верификации SVA coverage, code/functional coverage. 

 

В итоге у вас получается следующая картина. Для каждого IP Core у вас есть исходные требования (текстовое перечисление, что модуль должен делать, а что нет) которые трассируются к проектным спецификациям и test plan на разработку RTL и VIP. Дальше эти требования трассируются к исходному коду RTL и VIP. Что бы аудитор мог тыкнуть пальцем в любое требование и вы ему показали как это требование реализуется и проверяться (текстовое описание реализации в спецификациях и конкретные строки кода в исходниках). И наконец требования трассируются к логам (отчетам) о проведении тестирования. То есть, полный цикл: что требуется -> как это реализуется и проверяется -> что получилось по факту. 

 

Есть много разного софта который поможет автоматизировать различные стадии этого процесса. В Questasim есть verification management (как то так называется) он может втягивать в себя test plan и графически отображать прогресс верификации и печатать репорты. Но не забывайте, в DO-254 есть такое понятие как tool assessment, то есть, грубо говоря инструмент должен быть сертифицирован для использования в маршрутах проектирования электроники от надежности функционирования которой зависят жизни людей.  

  

 

[MaratZuev 0]

Приветствую, земляк  

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

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

Вопрос стандарта кодирования поставлен, будем решать, как обычно, постфактум, глядя на то, что выложено в сети представителями одной из известных (по-моему, питерской) фирм, насчёт стандартизации верификации ничего не слышал ни от кого: вот от Вас сейчас первый раз. Да, в наших проектах, другие как PLL, IP блоки (если под ними подразумевать не наши блоки) не используются: м.б. звучит дико, но это так. Про SVA тоже вопрос: в КТ-254, а, точнее, РМ-254 такого понятия нет, а есть code coverage, состоящий из statements coverage, FSM и transitions coverage. Вероятно, я ошибаюсь. Functional coverage мы подразумеваем, как функциональное тестирование, целью которого показать, что удовлетворяются все требования, упомянутые в ТЗ.

Про картину: м.б. под IP Core Вы подразумеваете (top) FPGA project, тогда да, требования написаны и по ним ведётся работа. В противном случае простое умножение всех наших проектов, которых наберётся не один десяток, на количество блоков, на которые разбивается проект представляется необозримой задачей. С остальным в этом параграфе полностью согласен. Как раз "барсики" на той неделе нам произнести именно эти слова.

Насчёт Quest-ы, мы пока обходимся ModelSim-ом, который мы как раз и квалифицировали (насчёт tool assessment), сопоставив его vcd c оным от Active-HDL, что должно, по нашему представлению, быть комильфо.