Оптимизация разработки программного обеспечения до создания кристалла

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

Растущий спрос на SoC создал высококонкурентный рынок. Из-за этого SoC становятся все более сложными, периферийные устройства в SoC постоянно развиваются, а время выхода на рынок сокращается. Важным компонентом, отвечающим сложностям разработки SoC, является доступность программного обеспечения. Здесь мало места для ошибок, и программное обеспечение должно быть готово как можно скорее. Чтобы справиться с этой задачей, разработка программного обеспечения должна быть начата до появления части SoC.

Разработка программного обеспечения для SoC

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

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

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

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

Подходы к разработке до кремния

Чтобы начать разработку программного обеспечения до выхода на магнитную ленту SoC, разработчики могут использовать несколько подходов, таких как прототипирование программного обеспечения, испытательный стенд RTL, платы FPGA, аппаратные эмуляторы и т. Д. Поскольку эти подходы обычно ориентированы на отдельные модули, каждый из этих подходов имеет свои собственные проблемы, поскольку цель заключается в разработке программного обеспечения для запуска всего SOC, а не отдельных модулей. Если мы разбиваем проблему на более мелкие модули, первое, что необходимо сделать перед началом разработки драйверов, - это знать каждый разрабатываемый процессор, ускоритель или периферийное устройство.

Модели системы C

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

Тестовая среда RTL

Чтобы решить эту проблему неточности, можно использовать другой подход - использовать тестовую среду Verilog. Средство тестирования обычно разрабатывается и поддерживается командой разработчиков SoC для проверки. Среда тестирования Verilog основана на спецификации языка передачи регистров (RTL) SoC, представляя полную SoC, а не только некоторые IP-блоки. Следовательно, он точен от цикла к циклу. По мере развития RTL тестовая среда движется в ногу с ним. Это гарантирует, что это наиболее актуальное и точное представление о SoC в стадии разработки. В целях разработки программного обеспечения средство тестирования Verilog также может использоваться для разработки драйверов программного обеспечения.

Программное обеспечение, разработанное с использованием этого метода, является точным и может помочь сократить время запуска программного обеспечения, когда образцы SoC прибывают после процесса изготовления. Но у этого подхода есть проблема. Поскольку верстак Verilog точен по циклу, он работает очень медленно. Разработка программного обеспечения в такой среде возможна, но разработка и отладка будут чрезвычайно медленными. На разработку драйвера с помощью этой методологии могут уйти месяцы. Средство тестирования Verilog можно использовать, запустив его намного раньше - по существу увеличив время, необходимое для предварительной обработки кремния, чтобы учесть медленную скорость решения (но зависит от доступности средства тестирования). В альтернативном подходе эту методологию может использовать другая команда разработчиков программного обеспечения (работая только над предварительной разработкой) - существенно увеличивая количество необходимых ресурсов, тем самым не устраняя эту проблему, аналогичную проблеме с методом поведенческой модели C.

На практике мы не можем согласиться с неточными или длинными циклами разработки, а также не можем принять дополнительные затраты, необходимые для дублирования или увеличения количества ресурсов для сохранения нормального графика цикла разработки. Следовательно, мы должны рассмотреть другой подход к разработке программного обеспечения на основе кристаллов. Этот подход предполагает эмуляцию каждого IP-блока SoC на программируемой вентильной матрице (FPGA).

Прототипы ПЛИС

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

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

щелкните, чтобы увеличить изображение

Рисунок. Краткий обзор предварительных решений для разработки программного обеспечения. (Источник:Нитин Гарг)

Эмуляторы SoC

Чтобы решить проблему точности, скорости и покрытия, можно использовать более надежный подход, который использует эмуляторы SoC. Существует множество коммерчески доступных эмуляторов SoC, которые могут эмулировать очень большие и сложные SoC. Эмуляторы SoC основаны на RTL, поэтому они точны и в 100 раз быстрее, чем тестовый стенд Verilog, что делает его намного лучше для разработки программного обеспечения. Поскольку они довольно быстрые, полный перенос ОС и разработка драйверов могут быть выполнены в разумные сроки. Эмуляторы SoC могут масштабировать всю SoC, поэтому разработка программного обеспечения лучше адаптируется к конечной производственной SoC.

Использование эмуляторов SoC для разработки и проектирования программного обеспечения на предварительном кристалле сокращает время и усилия, затрачиваемые на запуск программного обеспечения, поскольку может устранить или уменьшить общие пробелы в разработке. Программное обеспечение также можно отлаживать с помощью стандартных инструментов JTAG на эмуляторе SoC. Эмуляторы могут использоваться для множества задач, таких как разработка и проверка ПЗУ, разработка прошивки и ОС, а также проверка на уровне IP или SoC. Еще одна интересная особенность эмуляторов SoC заключается в том, что они могут связывать SoC с реальными компонентами, такими как те, что представлены на плате разработки. Например, можно подключить реальное или виртуальное устройство NAND к SoC в эмуляторе и разработать ПЗУ, драйверы ОС и т. Д.

Эмуляторы SoC предлагают гораздо больше возможностей, чем другие подходы к разработке программного обеспечения. Эмуляторы могут одновременно связывать SoC с UART, I2C, различными дисплеями, устройствами хранения, устройствами PCIe, устройствами подключения, такими как Ethernet и Wi-Fi, и устройствами захвата, такими как камеры и датчики. Другими словами, эмуляторы SoC могут представлять собой реальную доску для разработки, поэтому можно создать полную структуру, такую ​​как Android, и запустить полный вариант использования, прежде чем снимать SoC. Например, загрузка Android и декодирование нескольких кадров видео в эмуляторе SOC может занять несколько часов, но может оказаться очень полезным при анализе производительности SOC.

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

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

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

Рисунок 2. Сравнительная скорость выполнения каждого решения. (Источник:Нитин Гарг)

Согласно закону Мура, количество транзисторов в интегральной схеме (ИС) удваивается каждые два года из-за увеличения функциональности ИС. Большинство 64-битных SoC на базе ARM сегодня имеют от 100 до 300 миллионов логических вентилей. Из текущих подходов к разработке программного обеспечения SoC, эмуляторы SoC доказали свою способность масштабироваться и поддерживать потребности групп разработчиков программного обеспечения, которые сталкиваются с проблемами, связанными с возрастающей сложностью SoC на сегодняшнем конкурентном рынке.

Ссылки

1. Тримбергер, Стивен М. «Три возраста FPGA». Полнотекстовый PDF-файл IEEE Xplore: 2015 г., ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7086413.
2. БРЮНЕТ, ЖАН-МАРИ. «Почему современные дизайны SoC используют эмуляцию». Проектирование встроенных вычислений , 5 сентября 2018 г., embedded-computing.com/embedded-computing-design/why-modern-soc-designs-embrace-emulation.
3. "Soc Emulation". Эмуляция Соц , 2019 г., www.aldec.com/en/solutions/hardware_emulation_solutions/co-emulation–soc-emulation.
4. «Размещение большего количества компонентов в интегральных схемах». http://www.cs.utexas.edu/ , 2006 г., cs.utexas.edu/~fussell/courses/cs352h/papers/moore.pdf.