Если предыдущая статья про гибридное прототипирование описывала новаторское использование платформы HAPS, то сегодня мы расскажем в общем - что такое прототип, и какие традиционные подходы к прототипированию используют инженеры Baikal Electronics.
В маршруте проектирование сложных System-on-the-Crystal (SoC) прототипирование на FPGA занимает промежуточное место между моделирование на симуляторах (VCS, ModelSim и др.) и эмуляцией.
FPGA-прототипирование позволяет реализовать такие сложные сценарии системной валидации микросхемы как загрузка операционной системы (ОС). На прототипе операционная система может загрузиться за несколько часов, на симуляторе ОС грузилась бы в течении месяцев. При этом на FPGA с помощью встроенного логического анализатора мы можем увидеть поведение любого сигнала нашего дизайна в любой момент времени. А также, в отличие от кремния, можем переконфигурировать наш прототип произвольное количество раз.
В Baikal Electronics мы используем платформы Synopsys HAPS-70, представляющие из себя сборки из четырёх FPGA Xilinx Virtex-7-2000, каждая из которых вмещает до 12 миллионов логических гейтов. Таким образов вместимость одной платформы HAPS-70 – до 48 миллионов логических вентилей. Мы можем соединить два HAPS в стек и получить систему, в которую можем загрузить дизайн объёмом до 96 миллионов логических гейтов. Между собой внутри HAPS-70 ПЛИС соединяются через кабели со стандартными разъёмами HapsTrak 3 (HT3).
Так же с помощью этих же разъёмов можно подключать к платформе дочерние платы (например, интерфейсные) , которые можно купить у Synopsys или разработать самостоятельно. Мы используем платы от Synopsys с DDR3 и SATA.
Интерфейсная плата для HAPS от Байкал
Для работы с низкоскоростными интерфейсами наши инженеры разработали интерфейсную плату, на которой выведены:
JTAG
Spi flash
Ethernet
UART
USB
Блок переключателей
Блок светодиодов
GPIO
Для работы со скоростными интерфейсами у HAPS имеются нативные разъемы MGB, выведенные из мультигигабитных трансиверов Xilinx внутри каждого FPGA.
Этапы тулчейна от RTL до FPGA bitstream
Маршрут компиляции проекта под HAPS, в результате прохождения которого мы должны получить bitstream (микрокод, «прошивки») для FPGA, включает следующие стадии:
1. Partitioning
В приложении Synopsys Protocompiler компилируются RTL-исходники проекта.
В результате мы получаем разбитый, например, на 4 FPGA дизайн в виде списков исходников для каждой FPGA.
2. Компиляция отдельных чипов в Protocompiler
На второй стадии в Protocompiler собирается проект для каждой FPGA.
В результате получается netlist и tcl-скрипт для запуска маршрута Place&Route в Xilinx Vivado.
3. Vivado
На третьей стадии мы запускаем в Vivado уже готовый tcl-скрипт маршрута Place&Route, который берет нетлист. В итоге получаем прошивки для FPGA.
Этапы 2 и 3 хорошо знакомы разработчикам на FPGA, использующим, например, тулчейн Synplify+Vivado, поэтому остановимся подробнее на особенностях и вызовах первого этапа.
Design Partitioning для платформы HAPS посредством тула Synopsys Protocompiler
Разбиение дизайна на чипы FPGA (партишенинг) или распил (все же знают – мы в Baikal Electronics занимаемся как раз этим J) – это итеративный полуавтоматический процесс, в результате которого достигается баланс между заданной пользователем аппаратной конфигурацией (топология межчиповых кабелей, назначение портов и дочерних плат, начальное закрепление частей дизайна за конкретными FPGA) и характеристиками дизайна (эффективная растрассировка сигналов между FPGA, обеспечение приемлемого заполнения FPGA и выдержка требуемых характеристик быстродействия).
Если требуемые характеристики не достигаются, то мы меняем конфигурацию: перетягиваем кабели, переназначаем порты и исходное закрепление некоторых структур за конкретными FPGA. Последнее можно не делать совсем, а отдать начальное размещение полностью на откуп тулу.
Технологии тулы Protocompiler - Multi-Hop оптимизация, Feedthrough оптимизация, Time-Domain-Multiplexing – активно способствуют автоматической части партишенинга.
Multi-Hop оптимизация
Если логика пути сигнала разбивается между двумя FPGA, то путь между этими чипами называется hop («скачок»). Multi-Hop путь может простираться между несколькими FPGA и существенно ухудшать тайминг, при этом степень ухудшения тайминга зависит от доступных межчиповых связей и степени HSTDM-сжатия. (см. ниже).
Пользователю Protocompiler доступны опции, позволяющие автоматически минимизировать количество Multi-Hop путей.
Feedthrough оптимизация
Feedthrough-пути используют промежуточные чипы FPGA для трассировки сигнала от чипа источника до чипа назначения, если межчиповые трассы для point-to-point соединения недоступны.
На Рис. 6 показано, что в сигналe из верхнего левого чипа источника не хватает прямых связей с верхним правым чипом назначения. Тогда автоматический роутер в туле буферизирует сигнал и размещает буфер в нижнем левом чипе, что неизбежно приводит к деградации тайминга. Пользователь может установить разрешение или запрет туле на автоматическое создание feedthrough-путей.
Эта технология используется на этапе System routing, сразу после этапа Partitioning. Обычно она используется в комбинации с технологией Time-Domain-Multiplexing.
Time-Domain-Multiplexing
Партишенинг дизайна на чипы FPGA приводит к дефициту бюджета I/O пинов FPGA для трассировки межсоединений. Партишенинг современной SoC гарантированно приводит к многократному превышению требуемого количества трасс над имеющимися I/O. Выход один – мультиплексирование.
Пользователь может задать тулу максимально допустимую степень сжатия HSTMD (High Speed Time Domain Multiplexing). При этом автоматически вставляемые сериализаторы/десериализаторы работают на частоте свыше 1 ГГц, обеспечивая эффективное сжатие мультиплексируемых сигналов до степени 128:1 и выше.
Отладочные интерфейсы
Управление платформой HAPS осуществляется с помощью утилиты Confpro, через которую мы можем:
Прошивать FPGA
Назначать чаcтоты входных синхросигналов
Управлять сбросами
Устанавливать номиналы питания банков питания FPGA
На прототипе можно разрабатывать и заниматься отладкой программного обеспечения так же, как и на настоящем процессоре в кремнии. Мы подключаемся к отладочному интерфейсу JTAG с помощью Olimex usb-jtag эмулятора, запускаем отладчик Openocd, при необходимости загружаем программы в spi flash память, в ROM, в ОЗУ. Можем подключить UART-интерфейс через usb адаптер к инструментальному компьютеру и осуществить символьный ввод/вывод для программ. Дочерняя плата на разъемах HT3 позволяет подключить SATA диск и Ethernet патчкорд.
Для прототипов процессорных Arm-ядер можно заниматься отладкой ПО через встроенную в ядра отладочную систему Coresight при помощи программного пакета Arm DS через физический интерфейс Arm D-Stream или более простые jtag-эмуляторы.
Встроенный в FPGA синтезируемый логический анализатор доступен через UMR Bus - нативный интерфейс от Synopsys для управления HAPS. Доступен огромный банк хранения выборок сигналов для построения вейвформ.
Прототипирование у нас используется прежде всего для системной валидации и ранней разработки ПО, такого как программы загрузчиков сервисного процессора, загрузчиков Arm TF, UEFI, ОС Linux.
Благодаря месяцам pre-silicon отладки на прототипе, наша команда «подняла» Linux на инженерном образце процессора Baikal-М в первые дни получения инженерного образца в руки!
Комментарии (24)
checkpoint
02.11.2021 20:50Хочу немного прояснить для себя, что именно симулируется в ПЛИС. Я правильно понимаю, что ядро ARM поставляется в виде множества файлов на языках Verilog, SystemVerilog, VHDL. Вы их компилирует и получаете битстрим для десятка ПЛИС которые в связке симулируют все восемь ядер будущего микропроцессора до последнего вентиля. Или же ARM ядра поставляются в виде blackbox-ов с описанным интерфейсом, их симуляция не производится совсем (используются готовые ядра "в кремнии" или эмулируются средствами встроенных PowerPC ядер в Xilinx Virtex-7), а в ПЛИС симулируется только разработанная вами часть "обвеса" ?
Vinedresser
02.11.2021 22:59+4Ядра поставляются в виде верилога. Все восемь ядер не поместятся в указанную конфигурацию HAPS, 2 или 4 помещаются. Но ядра это меньше трети площади кристалла. Критически важно проверить обозначенные сценарии загрузки в составе, например: сервисный процессор-загрузчик, 2 ядра Arm, когерентный интерконнект, низкоскоростная периферия, контроллер DDR. И да, самописный "обвес" везде присутствует. В RTL симуляторах симулируется все, и даже для самых критически важных сценариев синтезированный нетлист.
dmistas
02.11.2021 22:59+1Прототипирование у нас используется прежде всего для системной валидации и ранней разработки ПО, такого как программы загрузчиков сервисного процессора, загрузчиков Arm TF, UEFI, ОС Linux.
Получается, что системноая валидация и ранней разработки ПО выполнялась без несинтезабельных блоков (вроде SRAM, PHY...), заменённых ресурсами ресурсах FPGA. Так ?
Vinedresser
02.11.2021 23:34Верно, но также см. ссылку в начале заметки на нашу статью о косимуляции несинтезабельных в FPGA частей дизайна. Там отлаживали ПО на оригинальных DDR phy в RTL симуляторе + синтезабельный топ дизайна на HAPS. И конечно же на RTL симуляторе верифицировались все оригинальные phy, SRAM и пр. как на уровне отдельных подсистем, так и на топе.
JerleShannara
03.11.2021 01:13Небольшой вопрос — почему был выбран именно Synopsys, а не более мелкие «акулы», к примеру profpga?
Vinedresser
03.11.2021 07:17+1На момент выбора платформы в индустрии HAPS был безусловным лидером. Это и зрелость платформы в несколько поколений, масштабтруемость, наличие дочерних карт, наличие своего уникального софта для партишенинга. Плюс нативная интеграция с EDA тулами в Байкале, которые тогда все были от Synopsys. Байкал был первым во всей Европе, у кого появился HAPS-70 в 2014г.
Khort
03.11.2021 01:21В плис тестируется только RTL, или этапы имплементации тоже? К примеру, DFT: режим скан, компрессоры/декомпрессоры, мультиплексоры клоков, оболочки а-ля ieee 1500, jtag tap, граничное сканирование, mbist, и т.д.
Vinedresser
03.11.2021 07:26+2Только RTL, ведь главная цель - ранняя отладка софта. Ловля багов побочная цель, для этого есть верификаторы. Симуляция отлично покрывает сканы и mbist в приемлемые рантаймы.
lexxsu
03.11.2021 08:00Я бы сказал основная цель прототипирования и ловля багов в основных сценариях работы, использование FPGA для ранней отладки не оптимально (можно конечно, но zebu тут впереди).
amarao
Я совершенно далёк от этой области, но меня всегда интересовало, а каким образом дорогущие fpga защищаются от кз на ножках или вентилях?
dem0crypt
Делают разные вентили по строению. Но вообще токи там небольшие, а сопротивления довольно велики. На ножках бывает ставят разные защиты, но обычно не от КЗ а от превышения максимально допустимого напряжения на входе. Бывает что не ставят и спалить что-нибудь вполне возможно.
VT100
КМК, сигналы с ПЛИС почти никогда не выводятся во "внешний мир" напрямую. Соответственно - защиты обеспечивают другие ИМС.
А в случае "Synopsis за сотни нефти" - это забота квалифицированных инженеров.
amarao
Я очень поверхностно понимаю эту область, но, грубо говоря, если у нас есть набор программируемых вентилей, то что мешает из-за бага в программе сделать их постоянно открытыми между live & ground? Т.е. дело даже не во внешнем мире, а в рамках самой микросхемы. Насколько я мне мой "школьный электронный" подсказывает, если я открываю транзистор без нагрузки в линии, и одна нога у него на землю, а другая на питание, то там протекает максимально возможный ток. Вот от этого как защищаются?
Vinedresser
Для I/O пинов применяются схемы защиты на диодах. Поищите такие топики: ESD protection devices, transient voltage surge suppressors, clamping diodes.
amartology
В настоящих FPGA все чуть-чуть по-другому, но принцип тот же.
Таких схем просто не может быть, потому что быть не может)
VT100
А-а-а! Внутри одного вентиля это невозможно, как разъясняет @amartology . А вариант "два устройства одновременно передают на внутренюю шину" - должен(?) отсеиваться при логическом моделировании.
Однажды рассказали, что при разработке забыли подтяжки/"bus keeper" на внутренней шине поставить. И инжерерные образцы ИМС некоторое время работали, а потом "на ровном месте, в простое" выпускали дым...
amartology
Все подтяжки и прочие открытые коллекторы — это всегда вынужденная мера, от невозможности реализовать более устойчивые к дураку решения.
Khort
При проектировании цифровых схем этого стараются избегать, но надо понимать что внутри микросхем такие места сплошь и рядом, просто они спрятаны внутри элементов. К примеру, любой триггер содержит драйверы во встречном включении, и в момент их переключения заряд хранится просто на внутреннем (паразитном) конденсаторе. Или устройство памяти - ячейки обьединяются общими шинами с подтяжкой. Но память сделана не так как логика, это вообще скорее аналоговая схема, чем цифровая. На старых технологиях попадались мультиплексоры по схеме нескольких драйверов с подтяжкой.
Khort
Раньше меня тоже интересовал этот вопрос, поскольку несмотря на посты выше, в микросхемах постоянно происходят КЗ в логике, в основном в инверторах. Инветоры используются в виде усилителя сигнала, так в цепи клока их до 99% (буфер считаем за два инвертора), они есть в составе большинства логических селлов и триггеров - опять же в виде выходных усилителей. Момент переключения инвертора - всегда КЗ. Спасает здесь то, что сопротивление открытого канала транзистора - десятки килоОм (pmos), сопротивление цепей питания до транзистора порядка килоОма плюс реактивное за счет паразитных емкостей, плюс надо учесть что события эти не одновременны, т.е. размазаны во времени и по площади чипа.
Т.е. таки КЗ присутствуют, причем постоянно. Но это нормально.
amartology
Но только это не КЗ, потому что оно не статично. А ситуация, когда в стандартной КМОП-логике возникает именно статичное короткое замыкание земли с питанием, в нормальных обстоятельствах невозможна.
Khort
КЗ - короткое замыкание. Деление на статическое и динамическое КЗ мне не понятно. Во временах работы цифровых схем, время переключения инвертора, сопровождающееся открытыми NMOS и PMOS можно считать статическим - ведь за это время происходит полный перезаряд паразитной емкости выхода элемента. Т.е. вполне себе короткое замыкание. Другой пример: если задержка (latency) в цепи клока больше периода, то можно утверждать что в каждый момент времени какой то из элементов цепи дерева коротит питание на землю - т.е. 100% времени мы имеем КЗ в цепи клока. Довольно неожиданный вывод, верно? Однако, ничего страшного в этом нет.
Про каждый логический элемент - не согласен. КЗ при переключении происходит всегда - в инверторах (и выходных усилителях), и только изредка - в первом каскаде многовходовых логических элементов. Очевидно что для этого требуется одновременное переключение потенциала на всех входах - статистически маловероятное событие, зависящее от множества параметров (температура, питание и т.д.). Чем больше входов у логического элемента, тем реже можно увидеть КЗ. А вот в инверторе - на каждом переключении. Если питание выше Vth, разумеется, т.е. речь про нормальный режим работы.
amartology
Давайте продолжим говорить об определениях:
Ну и это не говоря о том, что вы сами отметили: импеданс одного открытого транзистора довольно велик, и рассматривать переключение инвертора как короткое замыкание — концептуально неправильно.
В nand на втором статичном входе (или входах) должна быть единица (единицы), в nor — ноль (ноли). Не такое маловероятное событие, как вам кажется.
Khort
Рассматривая инвертор как логический элемент на двух ключах и отбрасывая имплементацию (КМОП, БП, электромеханический ключ), мы говорим о событии, когда оба ключа открыты, т.е. КЗ в определении википедии. Если считать инвертер просто аналоговым усилителем (в контексте имплементации), то не КЗ. Но мы говорим о цифре. Получается, что КЗ здесь - очень даже концептуальное