Jump to content

    

Об одном подходе проектирования устройств на базе ПЛИС

Товарищи форумчане, столкнулся скажем так, возможно, с не пониманием или отсутствием каких-то системных знаний, но, возможно, кто-то подскажет. Как правильно проектировать сложные модули на базе ПЛИС, интересует преимущественно программная и алгоритмическая сторона. После общения с многими представителями разных компаний, пришел к вывод, что у всех разные подходы. А именно кто-то разрабатывает в лоб, есть тз описаны конкретные функции, без процесса моделирования и симуляции пишут код под ПЛИС (на verilog, VHDL), добавляют  временные ограничения по клокам, немного подолбаются с отладкой сигналов и готово, отдают заказчику. Другие подходят сложным путем, в начале строят модели алгоритмов, в матлабе отлаживают или на языках высокого уровня, потом смотрят в симуляторе, пишут тесты, потом перекладывают в железо, отлаживают, добавляют и временные ограничения. Так вот, а как надо-то, может кто порекомендует , что почитать или знает, как это устроено у гигантов Самсунга, Хуавея, Эппла, как минимально потратить времени на разработку, и уменьшить время на отладку таких систем.

Share this post


Link to post
Share on other sites

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

А теперь представьте, что вам надо сделать ПО для автомата защиты атомной электростанции. Там всего две релюшки - для разрыва цепи. Но вы же не полезете отлаживать свое ПО на электростанции, правда? Мало того, вам это вообще никто делать не даст, пока вы не докажкте, что ваше ПО делает то, что нужно. А если это ПО для самолетного контроллера? И после того, как вы все отладите, как вы докажете, что ваше ПО полностью протестировано и готово к реальному использованию? Мало того, как вы после этого будете спасть? Спокойно?

Вот тут и появляется другой подход. Более ответственный, я бы сказал. Естественно и более сложный и дорогой.  И в принципе у него есть очень простая цель - выявить как можно больше ошибок на ранних этапах разработки. В идеале еще на этапе требований, так как стоимость исправления ошибки растет в геометрической прогрессии по мере приближения к концу проекта. В настольном приборе, например, вы можете выявить и устранить ошибку прямо на столе и это будет дешево. А в ПО для самолетного контроллера ошибка, выявленная на этапе реальных испытаний - это уже очень поздно и ее устранение обойдется очень дорого

В результате сама сложность модуля или разработки отходит на второй план. Модуль может быть и очень простым, но использоваться в космосе. А может быть очень сложным, но использоваться где-нибудь в телевизионной приставке. Так вот как раз для приставки можно воспользоваться первым методом "в лоб", предложенным вами. А вот с космосом уже придется пользоваться вторым, сложным методом. Самсунг, Хуавей, Эппл ИМХО пользуются методом "в лоб" и просто нанимают тысячи индусов, так как консьюмер маркет, отладка простая, да и баги можно пофиксить потом.

Share this post


Link to post
Share on other sites

Без процесса моделирования и симуляции большие проекты не заработают. Так что моделирование как можно чаще. Другой вопрос какие требования. При разработке требования к модулю/прибору/блоку могут меняться, часто сам заказчик не совсем понимает что ему надо и вам надо как-то заранее прикидывать как вам за вечер/день/неделю быстро добавить новую функцию и переделать старые. После сдачи заказчику обычно ещё появляются хотелки/свистелки у начальства и Вам надо уметь быстро перекраивать код, а без тестирования и применения всяких матлабов, vivado hls и т.п. , я считаю, обойтись трудно.

Share this post


Link to post
Share on other sites
16 hours ago, nepoch said:

А именно кто-то разрабатывает в лоб, есть тз описаны конкретные функции, без процесса моделирования и симуляции пишут код под ПЛИС (на verilog, VHDL), добавляют  временные ограничения по клокам, немного подолбаются с отладкой сигналов и готово, отдают заказчику...

как минимально потратить времени на разработку...

Вы видели сколько минут проект имплементируется или симулится?

 

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

 

Так что в лоб банально неудобно разрабатывать алгоритм - в лоб только переводить готовый алгоритм на язык ПЛИС...

Share this post


Link to post
Share on other sites

Привет, я один из тысяч индусов.

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

link level simulator - здесь вы отлаживаете алгоритмы. по сути это не привязанная ко времени модель обработки, реализованная на с++ или матлаб. также lls является генератором тестовых векторов для rtl

system level simulator - здесь вы проектируете и отлаживаете архитектуру системы, взаимодействие узлов, временные ограничения, коэф. использования, получаете первичные оценки площади и энергопотребления.

в качестве sls порекомендую

 

Share this post


Link to post
Share on other sites

Если цена ошибки велика то обычно делают так:

пишут спецификацию на продукт,

из спецификации одна комманда пишет дизайн реквайрменты, другая верификейшн реквайрменты, 

на основании реквайрментов пишутся планы проектирования и верификации,

после этого дизайн тим делает дизайн удовлетворяя и возможно уточняя дизайн реквайрменты,

верификейн тим - делает модели внешних устройств, тестбенч и тесты для покрытия верификейшн реквайрментов,

потом пускается регрессия тестов и смотрится покрытие верификейшн реквайрментов и покрытие кода,

если покрытие кода превышает порог то переходят к физической имплементации,

после нее СТА и регресси на нетлисте с разными углами

и уже после этого проверка на изделии....

 

Тут я не упоминаю системный уровень когда идет подготовка спецификации.

Share this post


Link to post
Share on other sites

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

Первоначально есть ТЗ на проект, на основании его, а также параллельных разработок делается математическая модель блоков кристалла, составные части SoC. Сами блоки могут быть довольно большими и нет смысла акцентировать внимание на функциях, они  могут быть как связаны с другими так существовать отдельно, только DDR.

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

Тестирование может начинаться одновременно с разработкой на HDL и включает в себя как проверка С модели на равенство с мат. моделью, так и проверка железа с С. В итоге получается жёсткая вертикальная структура с четко прописанными этапами работы 

Share this post


Link to post
Share on other sites
6 hours ago, vitus_strom said:

Если цена ошибки велика то обычно делают так:

пишут спецификацию на продукт,

из спецификации одна комманда пишет дизайн реквайрменты, другая верификейшн реквайрменты, 

на основании реквайрментов пишутся планы проектирования и верификации,

после этого дизайн тим делает дизайн удовлетворяя и возможно уточняя дизайн реквайрменты,

верификейн тим - делает модели внешних устройств, тестбенч и тесты для покрытия верификейшн реквайрментов,

потом пускается регрессия тестов и смотрится покрытие верификейшн реквайрментов и покрытие кода,

если покрытие кода превышает порог то переходят к физической имплементации,

после нее СТА и регресси на нетлисте с разными углами

и уже после этого проверка на изделии....

 

Тут я не упоминаю системный уровень когда идет подготовка спецификации.

А можно ли более по подробнее узнать про то, что входит в спецификацию, как ее грамотно оформить, что, понимается под требованиями к дизайну и верификации, из чего состоит, а так же что из себе представляют планы. Что такое регрессия тестов??? Можно ответить тут или в личку написать. Спасибо за ответ

Share this post


Link to post
Share on other sites

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

Требование к спецификации? - У каждой фирмы наверное свои - это вообщем то документ где описано что должен делать чип, возможно с некоторой детализацией внутренностей. Подобие даташита.

Если я правильно понял требования = реквайрменты, описывает каждой строкой каждое требовани, обычно реквайрменты нумеруют и потом ссылаются в них в тестах при верификации.

Каждый тест покрывает от одного до нескольких (небольшого количества) реквайрментов.

Регрессия это набор таких тестов (коротких).

Обычно окружение для верификации строится таким образом чтобы был тестбенч, к которому подключен девайс андер тест + модели внешних устройств + интерфейс для тестов. Собственно тесты взаимодействуют с верификационным окружением через этот интерфес.

 

 

 

 

Share this post


Link to post
Share on other sites
On 7/8/2019 at 3:24 PM, vitus_strom said:

Требование к спецификации? - У каждой фирмы наверное свои - это вообщем то документ где описано что должен делать чип, возможно с некоторой детализацией внутренностей. Подобие даташита.

А есть примеры подобных документов какой-нибудь фирмы в открытом доступе?

Share this post


Link to post
Share on other sites
4 hours ago, Amurak said:

А есть примеры подобных документов какой-нибудь фирмы в открытом доступе?

Разве что у NASA может что-то заваляться. А так не видел.

Share this post


Link to post
Share on other sites

этого не скажу, как правило это внутренние документы и наружу они не выходят.

Share this post


Link to post
Share on other sites
В 18.07.2019 в 08:10, Amurak сказал:

А есть примеры подобных документов какой-нибудь фирмы в открытом доступе?

Доброго времени суток!

По своей воле мало кто будет такое выкладывать. Но утечки были. Я поищу, где-то были внутренние требования некоторых крупных предприятий. Только вот обычно это делается для СМК и к реалиям отношения не имеет у нас...

Share this post


Link to post
Share on other sites
On 7/3/2019 at 7:54 PM, nepoch said:

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

Если задаётесь такими вопросами, то точно не стоит ориентироваться на таких гигантов как Интел,Самсунг,Хуавей, которые явно не озабочены вопросом бережливого использования инженерных ресурсов, в этих компаниях в порядке вещей дублирование кода - т.е. каждое подразделение имеет свою версию примитивов HDL (например), также практикуется подход дать двум дивизионам одну задачу и посмотреть что из этого выйдет. Более того из общения с экс-менеджерами сложилось впечатление, что в гигантах "рацуху" никто не любит - внедрение этого всего инертно и требует неавтоматических усилий, гораздо эффективнее нанять завтра еще 500 инженеров (или уволить :umnik2:).

Share this post


Link to post
Share on other sites
On 7/3/2019 at 7:54 PM, nepoch said:

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

Увы, так уж сложилось, что на территории эксСССР у большинства отсутствует как класс понятие коммерчески-успешной разработки из-за низкой/отсутствующей конкуренции (госкормушки, заказы ВПК/ФАПСИ, душегубка ввозными пошлинами).

Т.е. методология сразу рассматривается в отрыве от того ради чего она применяется (кроме некоей абстрактной "эффективности").

 

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

Соответственно 2й подход, описанный ТС больше походит на "бережливую" разработку, когда через моделирование, макетирование, пртотипирование получают первые оценки - не только качественные (SNR, dynamic range, selectivity), но и качественные (оценки быстродействия, площади кристалла и энергопотребления).

После получения/создания/согласования RD (Requirements Document) дальше флоу достаточно точно описал коллега vitus_strom

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now