Как предотвратить сбой проектов на основе FPGA

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

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

№1: Первая проблема касается не только разработки на основе ПЛИС, но и инженерии в целом. Проблема заключается в отсутствии стабильного базового уровня требований при запуске. Всегда есть желание начать проект, пока требования еще созревают, исходя из того, что необходимо продемонстрировать прогресс. Однако, если мы вскочим и начнем разработку без полного понимания требований, то - слишком часто - любой начальный прогресс окажется ложным, а выполнение последующих исправлений приведет к дополнительным задержкам и затратам. На самом деле слишком раннее начало вносит риск в разработку, и этот риск необходимо уменьшить. Я понимаю, что в зависимости от конкретного приложения глубина и детализация требований могут масштабироваться. Я ожидал бы гораздо больше и более подробных требований к системе SIL4, чем к коммерческой системе. Тем не менее, короче говоря, если требования не согласованы и не определены с самого начала, произойдет расползание объема. Хотя дизайн, возможно, начинался с разумной архитектуры для требований, как они понимаются, он будет становиться все более сложным, когда разработчики попытаются внедрить новую функциональность по мере развития базовой линии. Вскоре что-то сломается.

№2: Поняв ситуацию с требованиями, каждый член команды должен понять план разработки FPGA. Следовательно, неплохо иметь план, определяющий подход, который будет применяться от начала до реализации, с указанием основных задействованных шагов и параметров инженерного анализа, которые будут применяться в процессе разработки. Наряду с планом нам также необходимо задокументировать архитектуру и дизайн, определить каждую из основных функций, решить, какие функции должны быть разработаны заново, а какие использовать сторонний IP или повторно использовать существующий IP (подробнее об этом позже). Эта объединенная документация по плану, архитектуре и описанию проекта позволит группе инженеров четко понять поставленную задачу. Мы также можем отследить все функции до набора требований, чтобы гарантировать, что предлагаемый подход соответствует всем требованиям высокого уровня.

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

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

№5: До сих пор вы, возможно, заметили, что большинство вопросов, которые я поднял, связаны с процессами и более широкими инженерными аспектами, а не с кодированием самого дизайна. Конечно, разработка кода важна, но также важно убедиться, что мы используем сторонний IP-адрес и повторно используем внутренний IP-адрес. В идеале мы должны повторно использовать как можно больше существующих IP-блоков из нашей библиотеки. Если это невозможно, нам, конечно же, потребуется разработать новые модули. В этом случае создание этих новых модулей таким образом, чтобы их можно было повторно использовать в будущих проектах, должно быть в первую очередь в наших умах. Чтобы помочь нам создать эти новые блоки, мы должны рассмотреть возможность использования инструментов синтеза высокого уровня (HLS). Позволяя нам работать на более высоком уровне абстракции, эти инструменты дают возможность более легко исследовать пространство решений и сокращать риски, время разработки и затраты.

Представленные выше моменты - это лишь некоторые из вещей, которые я заметил при спасении проектов FPGA. Мне было бы очень интересно услышать ваше мнение о неудачных проектах.