Table of Contents

Интеграция цифровых процессоров сигналов (DSP) в конструкции System-on-Chip (SoC) стала краеугольным камнем современной электроники, питая все от смартфонов и автомобильных передовых систем помощи водителю (ADAS) до промышленной автоматизации и медицинских устройств. В то время как обещание сочетать специализированное ядро DSP с процессорами общего назначения, ускорителями и периферийными устройствами на одном кристалле обеспечивает беспрецедентную производительность и энергоэффективность, путь к успешной интегрированной в DSP SoC чреват техническими препятствиями. Инженеры должны ориентироваться в сложном ландшафте архитектурных ограничений, проблем управления питанием, узких мест пропускной способности памяти и ограничений программных средств. В этой статье рассматриваются критические проблемы интеграции процессоров DSP в конструкции SoC и предлагают практические идеи для их преодоления.

Понимание ландшафта интеграции DSP-SoC

Процессор цифровых сигналов спроектирован для высокоскоростных числовых операций в реальном времени — обычно многократно аккумулируемых (MAC) циклов, которые являются центральными для фильтрации, FFT, свертки и модуляции. При размещении внутри SoC ядро DSP должно гармонично сосуществовать с другими процессорами серии ARM Cortex-A, ядрами GPU, нейронными процессорами (NPU) и пользовательскими аппаратными ускорителями. Основная мотивация для интеграции заключается в том, чтобы разгрузить сигнальные задачи от основного процессора, тем самым уменьшая задержку и энергопотребление. Однако сами характеристики, которые делают DSP эффективными, также создают трение интеграции. В отличие от процессоров общего назначения, DSP часто требуют детерминированного доступа к памяти, специализированных трубопроводов инструкций и предсказуемой обработки прерываний. Если ткань SoC вводит дрожь или задержку, гарантии DSP в реальном времени могут быть нарушены, что делает систему непригодной для ее предполагаемого применения.

Роль гетерогенных вычислений

Сегодняшние проекты SoC неоднородны по своей природе. Типичная архитектура может включать в себя двухъядерный или четырехъядерный кластер CPU, ядро DSP, работающее под управлением операционной системы реального времени (RTOS) или голый металлический код, аппаратные ускорители для кодирования / декодирования видео и программируемое межсоединение, такое как шина ARM AMBA или сетевая шина (NoC). DSP должен связываться с другими блоками через общую память, двигатели прямого доступа к памяти (DMA) или выделенные каналы точки-точки. Одно из самых ранних решений, с которым сталкивается архитектор SoC, заключается в том, использовать плотно связанный DSP (интегрированный в кластер CPU с когерентной памятью) или свободно связанный DSP (связанный через шину или NoC в качестве независимого раба). Каждый подход несет в себе различные компромиссы по сложности, производительности и мощности.

Основные проблемы аппаратного обеспечения в интеграции DSP

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

Архитектура автобусов и согласованность данных

Большинство DSP предназначены для работы с интерфейсами памяти с высокой пропускной способностью, низкой задержкой - часто с отдельными программами и памятью данных (архитектура Гарварда). Интеграция такого ядра в общую шину системы, такой как AXI или AHB, может создавать проблемы с разнобой и узким местом. Например, если DSP выполняет поток операций FIR-фильтра в реальном времени, в то время как CPU одновременно записывает в общий буфер, задержки арбитража шины могут привести к тому, что DSP пропустит периоды выборки. Чтобы смягчить это, дизайнеры часто используют выделенные DMA каналы , которые перемещают данные без вмешательства CPU или DSP, но это добавляет сложность в переводе адресов и синхронизации. Кроме того, когерентность кэша становится проблемой, когда и CPU и DSP читают и пишут в одну и ту же область памяти. Без когерентного межсоединения программное обеспечение должно вручную смывать или аннулировать кэши, увеличивая сложность код

Часовые домены и структуры сброса

DSP часто работают на разных тактовых частотах, чем остальная часть SoC, чтобы оптимизировать производительность на ватт. Управление пересечением часового домена (CDC) между часами DSP и системными шинными часами требует надежных синхронизаторов, FIFO или асинхронных мостов. Плохо спроектированный CDC может привести к метастабильности, повреждению данных или периодическим сбоям. Кроме того, архитектура сброса должна обеспечить, чтобы DSP воспитывался в известном состоянии, не мешая другим модулям во время инициализации. Некоторые высокопроизводительные DSP поддерживают динамическое напряжение и частотное масштабирование (DVFS) для экономии мощности, что дополнительно усложняет синтез часового дерева и проектирование сети доставки энергии.

Физический дизайн и планирование этажей

С точки зрения физического дизайна ядро DSP занимает значительную площадь кристалла и часто имеет плотную структурированную компоновку, оптимизированную для скорости. Интеграция такого блока в большую планировку SoC может нарушить маршрутизацию сигналов для других блоков. Порты верхнего уровня DSP - интерфейсы памяти, линии прерывания, интерфейсы отладки - должны быть размещены без создания перегрузки маршрутизации. Кроме того, если DSP поставляется в качестве жесткого макроса от стороннего поставщика IP, его след может не соответствовать стандартной библиотеке ячеек целевого технологического процесса, заставляя дизайнеров использовать пользовательское размещение или повторное наведение. Целостность питания - еще одна проблема: DSP может рисовать временные токи в десятках ампер во время пиковой работы, требуя надежной емкости разъединения и энергосистемы низкого давления.

Управление питанием: доминирующее ограничение

DSP известны своими энергоемкими вычислительными возможностями — особенно при выполнении операций с устойчивым вектором или матрицей. В устройстве с питанием от батареи каждая милливатта имеет значение. Интеграция DSP в SoC без тщательного управления мощностью может быстро превышать тепловые бюджеты. Современные SoC используют несколько доменов мощности и островов напряжения. DSP может быть размещен в своем собственном домене, который может быть отключен (закрытый питанием) когда не используется. Однако, определение мощности вводит проблемы: регистры удержания состояния должны сохранять критический контекст, и DSP должен быть в состоянии проснуться достаточно быстро, чтобы справиться с событиями в реальном времени. Динамическое масштабирование напряжения (DVS) также может применяться для снижения напряжения, когда DSP работает на более низких частотах, но PLL DSP должен быть разработан для поддержки широких частотных диапазонов без блокировки сбоев.

Утечка и тепловые проблемы

На продвинутых технологических узлах (7 нм, 5 нм и далее) ток утечки доминирует над общим потреблением энергии даже в простаивающих состояниях. Дизайнеры должны реализовать многопороговые переключатели CMOS (MTCMOS) или переключение на обратный корпус для блока DSP, добавляя слои маски и сложность конструкции. Термальные горячие точки также могут развиваться, если DSP размещен рядом с аналогичным блоком высокой мощности, таким как GPU или NPU. Передовые конструкции SoC часто включают тепловые датчики и динамические механизмы дросселирования, которые уменьшают тактовую частоту DSP при превышении температурных ограничений - нетривиальная задача, когда производительность в реальном времени необходима.

Ограничения пропускной способности и задержки памяти

Производительность DSP напрямую связана с его способностью быстро получать доступ к данным. Многие алгоритмы обработки сигналов требуют устойчивой пропускной способности в несколько гигабайт в секунду. Если система памяти SoC не может обеспечить эту пропускную способность, DSP будет останавливаться, теряя циклы. Иерархия памяти должна быть тщательно разработана: тесно связанные воспоминания (TCM), прикрепленные непосредственно к DSP, но их размер ограничен. Большие наборы данных должны храниться в общей системной памяти (например, кэш L3 или внешняя DRAM), доступ к которым осуществляется через многоуровневый кэш или DMA. Задача интеграции здесь заключается в обеспечении архитектуры памяти, которая является одновременно высокопроизводительной и согласованной с другими мастерами. Некоторые SoC используют общую структуру памяти , которая позволяет DSP и CPU получать доступ к тем же банкам SRAM, но спорная и арбитражная логика может добавить сотни наносекунд задержки. Оптимизация приложений - например, разделение памяти на частные и общие области - часто требует детального моделирования производительности на ранней стадии проектирования.

Cache Architecture Tradeoffs (недоступная ссылка)

Некоторые DSP включают небольшие кэши L1 для инструкций и данных. В то время как кэши улучшают среднюю задержку, они вводят неопределенность для задач в реальном времени из-за промахов кэша и заполнения линий. В критически важных приложениях (например, автомобильных тормозных системах) дизайнеры иногда отключают кэши вообще или используют механизмы блокировки кэша для обеспечения детерминированного времени. Команда интеграции SoC должна решить, поддерживать ли протоколы когерентности кэша (например, ACE или CHI) между DSP и CPU, что добавляет сложность шины и энергопотребление. Для многих конструкций предпочтительнее более простая парадигма передачи сообщений с явными передачами DMA.

Программное обеспечение и интеграционные решения

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

Совместимость с Toolchain Compatibility

DSP от таких поставщиков, как CEVA, Cadence/Tensilica или Synopsys/ARC, поставляются с собственными архитектурами набора команд (ISA) и инструментальными цепочками. Для переноса алгоритмов обработки сигналов из DSP с фиксированной точкой в новый SoC может потребоваться переписывание оптимизированных для сборки ядер. Даже при использовании компиляторов C/C++ высокая производительность часто включает в себя внутренние функции или прагмы, которые специфичны для поставщика. Команды SoC должны проверять, что инструментальная цепочка DSP легко интегрируется с их средой разработки (IDE, отладчики, профили производительности). Если DSP IP недавно разработан, инструментальная цепочка может быть незрелой, что приводит к ошибкам в генерируемом коде или субоптимальной поддержке инструментальной цепи. Ограниченная поддержка инструментальной цепи может задерживать сроки проекта на месяцы.

Операционная система в реальном времени и развитие драйверов

DSP обычно запускает RTOS или голый металлический код, который должен связываться с операционной системой основного процессора (например, Linux, Android). Настройка межпроцессорных механизмов связи (IPC) - таких как очереди совместно используемой памяти, почтовые ящики или аппаратные семафоры - требует тщательного проектирования драйвера. Накладные расходы IPC должны быть минимальными, чтобы не нарушать крайние сроки в реальном времени. Кроме того, DSP должен обрабатывать прерывания от периферийных устройств (например, полное преобразование ADC, готовые данные датчика), которые маршрутизируются через контроллер прерываний SoC. Сопоставление этих прерываний с ядром DSP и обеспечение детерминированного ответа включает в себя низкоуровневый код инициализации платформы, который часто не документирован.

Отладка и отслеживание

Отладка системы с несколькими ядрами — каждое из которых работает потенциально различным программным обеспечением — как известно, затруднена. DSP часто имеют ограниченные возможности отслеживания по сравнению с процессорами, и интеграция модуля отслеживания в реальном времени (например, ETM для ARM) в ядро DSP может быть дорогостоящей. Разработчики SoC должны включать инфраструктуру отладки, такую как JTAG, последовательный вывод провода или встроенный логический анализатор, который может захватывать состояние DSP без остановки всего чипа. Кроме того, синхронизация временных меток между процессором и DSP имеет важное значение для анализа производительности. Без надлежащих отладочных крючков изолирование ошибки, которая возникает только при определенных шаблонах данных, может занять недели.

Проверка и сложность проверки

Проверка DSP-интегрированного SoC требует больше, чем просто тестирование DSP в изоляции. Сценарии системного уровня, где DSP обрабатывает данные в реальном времени, в то время как процессор взаимодействует с памятью и ввода-вывода, должны быть смоделированы или эмулированы. Традиционное моделирование RTL слишком медленно для запуска миллионов циклов DSP, поэтому команды проверки зависят от аппаратной эмуляции или прототипирования FPGA. Однако интеграция ядра DSP в прототип FPGA нетривиальна, потому что макрос DSP может не отображаться непосредственно на ресурсы FPGA. Платы эмуляции, которые включают массивы FPGA для логики DSP и модели памяти, могут стоить сотни тысяч долларов.

Со-верификация оборудования и программного обеспечения

Проверка аппаратного/программного обеспечения необходима для раннего выявления ошибок интеграции. Многие команды используют виртуальные прототипы (например, на основе Synopsys Virtualizer или Cadence Xcelium), которые запускают симулятор набора инструкций DSP вместе с моделью шины SoC. Хотя этот подход ускоряет разработку программного обеспечения до кремния, точность времени и мощности ограничена. Полная проверка чипа с фактическим DSP RTL в среде моделирования со смешанным сигналом медленна, но необходима для анализа критического пути. Метрики покрытия должны включать шаблоны доступа к регистру управления DSP, транзакции DMA и сценарии прерывания.

Дизайн компромиссы и архитектурные решения

Интеграция DSP редко является простым процессом «вброса». Команда SoC должна принять несколько архитектурных решений, которые влияют на производительность, площадь и время выхода на рынок. Например, выбор между жестким макросом DSP и мягким синтезируемым ядром. Жесткие макросы предварительно оптимизированы для конкретного узла процесса, предлагая более высокую производительность и меньшую площадь, но они ограничивают переносимость. Мягкие ядра могут быть нацелены на различные литейные заводы, но требуют большего усилия по интеграции и могут не достигать той же ширины тактового диапазона. Другое решение - ширина бита DSP: фиксированная точка 16-бит или 24-бит против плавающей точки 32-бит. Последний упрощает программное обеспечение, но увеличивает площадь и мощность. Для большинства потребительских приложений адекватна фиксированная точка DSP с программной эмуляцией плавающей точки, но автомобильная или аэрокосмическая может требовать нативной точности плавающей точки.

Реальные примеры интеграции DSP SoC

Такие компании, как Texas Instruments, NXP и Qualcomm, освоили интеграцию DSP в своих семействах SoC. Многоядерный DSP TI TMS320C66x интегрирует несколько ядер C66x с общей памятью, EDMA и периферийными устройствами, такими как SerDes и PCIe, - все на одном чипе. Ключевой задачей было поддержание когерентности кэша на нескольких ядрах DSP, позволяя при этом иметь доступ к внешней памяти с низкой задержкой. SoC серии NXP i.MX объединяют ядра ARM Cortex-A с Cadence Tensilica HiFi DSP для обработки звука. Интеграция требовала тщательного разделения часового домена, чтобы позволить DSP оставаться активным, когда процессор находится в глубоком сне. Эти примеры подчеркивают важность раннего архитектурного моделирования и тесного сотрудничества между аппаратными и программными командами.

Будущие тенденции и новые вызовы

По мере того, как технологические процессы масштабируются до 3 нм и далее, проблемы интеграции DSP будут усиливаться. У транзисторов FinFET и GAA будет более высокая утечка, что сделает энергоснабжение еще более критическим. Рост искусственного интеллекта и машинного обучения на краю привел к включению выделенных NPU вместе с DSP, создавая необходимость в эффективном разделении задач. Например, DSP может обрабатывать традиционное кондиционирование сигналов (фильтрация, FFT) в то время как NPU выполняет вывод нейронной сети. Межсоединение должно поддерживать потоковую передачу с низкой задержкой между этими блоками, что может быть достигнуто с помощью архитектуры на основе чиплетов, использующей интерфейсы типа UCIe. Безопасность является еще одной растущей проблемой: DSP часто обрабатывают конфиденциальные данные (например, голосовые записи, биометрия), поэтому SoC должна внедрять безопасные среды выполнения, шифрование памяти и механизмы изоляции. Наконец, программная экосистема развивается в сторону более стандартизированных API (например, OpenVX, oneAPI), которые абстрагируют базовое оборудование DSP, но поддержка этих рамок все еще отстает от традиционного программирования G

Заключение

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

Внешние ресурсы: