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

Введение

Эмуляция аппаратных устройств в проектировании интегральных схем

Эмуляция аппаратного обеспечения другим аппаратным обеспечением

В проектировании интегральных схем аппаратная эмуляция – это процесс имитации поведения одного или нескольких аппаратных устройств (как правило, разрабатываемой системы) другим аппаратным устройством, обычно специализированной системой эмуляции. Модель эмуляции обычно создается на основе исходного кода языка описания аппаратуры (например, Verilog), который компилируется в формат, используемый системой эмуляции. Основная цель – отладка и функциональная верификация разрабатываемой системы. Часто эмулятор достаточно производителен, чтобы быть подключенным к рабочей целевой системе вместо еще не изготовленной микросхемы, что позволяет отлаживать всю систему с использованием реальных данных. Это частный случай внутрисхемной эмуляции. Иногда аппаратную эмуляцию путают с аппаратными устройствами, такими как платы расширения с аппаратными процессорами, которые помогают в функциях программной эмуляции, например, старые дочерние платы с чипами x86, позволяющие операционным системам x86 работать на материнских платах с процессорами других семейств.

Введение

Большая часть повторных итераций и шагов разработки кремниевых интегральных схем обусловлена, по крайней мере частично, функциональными ошибками и дефектами, непреднамеренно внесенными на этапе RTL процесса проектирования. Таким образом, всесторонняя функциональная верификация является ключевым фактором для снижения затрат на разработку и своевременной поставки продукта. Функциональная верификация проекта чаще всего выполняется с использованием логического моделирования и/или прототипирования на программируемых вентильных матрицах (FPGA). У каждого подхода есть свои преимущества и недостатки, и часто применяются оба. Логическое моделирование простое, точное, гибкое и экономичное. Однако моделирование часто недостаточно быстро для больших проектов и почти всегда слишком медленное для запуска прикладного программного обеспечения на аппаратной конструкции. Прототипы на основе FPGA быстрые и недорогие, но время, необходимое для реализации крупного проекта в несколько FPGA, может быть значительным и подвержено ошибкам. Изменения для исправления дефектов проекта также требуют много времени для реализации и могут потребовать изменения разводки печатной платы. При использовании традиционных средств разработки прототипы FPGA обладают ограниченными возможностями отладки, зондирование сигналов внутри FPGA в реальном времени очень затруднено, а перекомпиляция FPGA для перемещения зондов занимает слишком много времени. Ситуация меняется с появлением более продвинутых инструментов отладки прототипов FPGA, устраняющих ограничения на видимость сигналов. Обычно используют моделирование на ранних этапах процесса верификации, когда ошибки и исправления возникают часто, и прототипирование в конце цикла разработки, когда проект в основном завершен и требуется скорость для проведения достаточного количества тестов с целью выявления любых оставшихся системных ошибок. Прототипирование FPGA также популярно для тестирования программного обеспечения. Ускорение моделирования может в определенной степени компенсировать недостатки производительности моделирования. В этом случае проект отображается на аппаратный ускоритель для значительно более быстрой работы, а тестовая среда (и любой код поведенческого описания) продолжает выполняться на симуляторе на рабочей станции. Высокоскоростной канал с низкой задержкой соединяет рабочую станцию с ускорителем для обмена данными между тестовой средой и проектом. В соответствии с законом Амдаля, скорость работы определяется самым медленным элементом в цепочке. Обычно это тестовая среда в симуляторе. При использовании высокоэффективной тестовой среды (написанной на C или на основе транзакций) канал может стать узким местом. В некоторых случаях тестовая среда на уровне транзакций способна подавать в эмулируемый проект столько же данных, сколько и "живой" стимул. Эмуляция в схеме несколько улучшает время реализации прототипов FPGA и обеспечивает всесторонние и эффективные возможности отладки. Эмуляция достигается за счет снижения скорости работы и высокой стоимости (более 1 млн долларов США) по сравнению с прототипами FPGA (75 тыс. долларов США). Рассматривая эмуляцию с другой стороны, она повышает производительность ускорения, заменяя моделируемую тестовую среду "живым" стимулом. Этот стимул может поступать от целевой системы (разрабатываемого продукта) или от испытательного оборудования. Благодаря скорости в 10 000–100 000 раз превышающей скорость моделирования, эмуляция позволяет тестировать прикладное программное обеспечение, обеспечивая при этом всестороннюю среду отладки аппаратного обеспечения.

The largest portion of silicon integrated circuit respins and steppings are due at least in part to functional errors and bugs inadvertently introduced at the RTL stage of the design process. Thus, comprehensive functional verification is key to reducing development costs and delivering a product on time. Functional verification of a design is most often performed using logic simulation and/or prototyping on field programmable gate arrays (FPGAs). There are advantages and disadvantages to each and often both are used. Logic simulation is easy, accurate, flexible, and low cost. However, simulation is often not fast enough for large designs and almost always too slow to run application software against the hardware design. FPGA based prototypes are fast and inexpensive, but the time required to implement a large design into several FPGAs can be very long and is error prone. Changes to fix design flaws also take a long time to implement and may require board wiring changes. With traditional vendor tools, FPGA prototypes have little debugging capability, probing signals inside the FPGAs in real time is very difficult, and recompiling FPGAs to move probes takes too long. This is changing with the emergence of more advanced FPGA prototype debug tools that remove limitations on signal visibility. The usual compromise is to use simulation early in the verification process when bugs and fixes are frequent, and prototyping at the end of the development cycle when the design is basically complete and speed is needed to get sufficient testing to uncover any remaining system level bugs. FPGA prototyping is also popular for testing software. Simulation acceleration can address the performance shortcomings of simulation to an extent. Here the design is mapped into a hardware accelerator to run much faster and the testbench (and any behavioral design code) continues to run on the simulator on the workstation. A high bandwidth, low latency channel connects the workstation to the accelerator to exchange signal data between testbench and design. By Amdahl's law, the slowest device in the chain will determine the speed achievable. Normally, this is the testbench in the simulator. With a very efficient testbench (written in C or transaction based), the channel may become the bottleneck. In some cases, a transaction level testbench is able to feed as much data to the design being emulated as "live" stimulus. In circuit emulation improves somewhat on FPGA prototyping's implementation times, and provides a comprehensive, efficient debugging capability. Emulation does this at the expense of running speed and high cost ($1M+) compared to FPGA prototypes ($75K). Looking at emulation from the other direction, it improves on acceleration's performance by substituting "live" stimulus for the simulated testbench. This stimulus can come from a target system (the product being developed), or from test equipment. At 10,000 to 100,000 times the speed of simulation, emulation makes it possible to test application software while still providing a comprehensive hardware debug environment.

Эмуляция и логика двух состояний

Еще одно различие между моделированием, ускорением и эмуляцией связано с тем, что ускорители используют аппаратную реализацию – у них только два логических состояния, отражающих поведение кремния после изготовления. Это означает следующее:

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

Эмуляция против прототипирования

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