Pull to refresh

Разработка цифровых устройств на базе СБИС программируемой логики

Electronics for beginners
Sandbox
На хабре периодически появляются статьи, посвященные разработке аппаратуры. Однако большинство из них исходят из теоретических позиций (что такое логические элементы, триггеры и т.д.) и на этом останавливаются, либо рассматривают вопрос в аспекте «сделай сам», т.е. что человек может создать самостоятельно в домашних условиях. Мне бы хотелось рассказать о том, как выглядит процедура проектирования аппаратных средств с точки зрения небольшой компании, зарабатывающей этим себе на хлеб с маслом.
Но сначала несколько слов о специфике данной области (по крайней мере в нашей стране). Приходится исходить из следующих реалий:
  1. невозможно в наших условиях соревноваться с интелом или хотя бы TI в выпуске процессоров и прочих разных микросхем — цена вхождения очень высока, рынки сбыта поделены, и, по большому счету, нет необходимых знаний и опыта;
  2. бессмысленно соревноваться с китайцами в производстве всевозможной массовой электроники — стоимость труда у них ниже, производственные мощности находятся у них же, рынки сбыта в руках крупных компаний;
  3. можно окучивать отечественные рынки различной несложной электроникой — от сигнализаций до елочных гирлянд. Кто-то живет этим, но норма прибыли невысока, а мороки много;
  4. можно участвовать в государственной программе поддержки бедных (РосПил). Отличная тема, но меня пригласить забыли.

Одна из немногих успешно работающих моделей — контрактные разработки для западных заказчиков. Идея проста: у нас заказывают наукоемкие исследования/разработки, результаты собирают вместе где-нибудь в Калифорнии (обычно по цепочке через нескольких посредников) и продают в конечном итоге какой-нибудь крупной корпорации-производителю электроники. Тому же Интелу, к примеру. Года через 2-3 все это возвращается к нам в составе сложных агрегатов (телефонов, мониторов и т.д.) в красивой коробке с клеймом “Made in USA” (что редко) либо “Made in China” (значительно чаще) по червонцу за пучок. Ситуация с одной стороны грустная — мы не владеем технологической цепочкой, а способны решать лишь отдельные задачи. Но есть и основания для оптимизма — таким образом российские разработчики входят в общемировую систему и получают ценный опыт. Компания, в которой я работаю, специализируется в основном на исследовательских разработках в области беспроводных коммуникаций. Исходя из этого я и буду вести дальнейший рассказ.

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


Далее следует этап системного проектирования. Рисуется структурная схема устройства и связи между компонентами. Производится оценка ресурсоемкости задачи, выбирается аппаратура, которая будет реализовывать создаваемые алгоритмы. По большому счету, имеется три пути:
  1. Использовать DSP-процессоры (цифровые сигнальные процессоры). Они хороши в ситуациях, когда необходимо реализовывать сложные алгоритмы для потока данных следующих на не очень высокой скорости — алгоритмы, которые удобно описывать с помощью последовательных программ. К сожалению, их производительности хватает далеко не во всех случаях. Несколько миллиардов умножений в секунду — это совсем не много при скоростях потоков данных порядка 100 МГц и более.
  2. Заказные СБИС (ASIC) – отличный путь для богатых и смелых. Они проектируются под конкретную задачу, поэтому не содержат лишней логики; рабочие частоты 1-2 ГГц. В тех случаях, когда планируется выпускать большую партию устройств (сотни тысяч штук), создание заказной СБИС позволяет получить максимальную производительность при минимальной цене за единицу товара. К сожалению, удовольствие это весьма дорогое. Создание одной ревизии микросхем по не самым современным технологическим нормам стоит порядка 1 млн. долларов.
  3. СБИС Программируемой Логики (FPGA) – это компромисс для тех кто создает прототипы устройств (тираж — несколько штук). Содержат множество стандартных блоков, выполняющих те или иные задачи. Пользователю предоставляется возможность настраивать параметры этих блоко и устанавливать связи между ними. Современные FPGA способны работать на частотах до 500 МГц и содержат при этом до 1000 встроенных аппаратных блоков умножения (плюс логические элементы, встроенная память, высокоскоростные приемопередатчики и т.д.). Удовольствие это тоже не дешевое — одна микросхема подобного класса обойдется в сумму 10-15 тысяч долларов. Естественно, что не всегда требуется столь крупный кристалл. В моей практике стоимость используемых FPGA составляет обычно 300-2000 $ (это если говорить именно о DSP-задачах). Два основных производителя FPGA – Xilinx и Altera, в совокупности занимают более 80% рынка программируемой логики.Линейки микросхем обеих компаний имеют сходные параметры и, зачастую, выбор между ними обуславливается не техническими характеристиками, а предпочтениями заказчика.

Так же фиксируются параметры других критически важных элементов создаваемой системы — необходимые частоты АЦП и ЦАП, параметры RF (радиотракт — высокочастотная часть) и прочие.

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


Разработка математических алгоритмов начинается обычно с изучения тематической литературы и рисования каких-либо базовых вещей на бумажке. Однако теоретический подход, к сожалению, применяется слабо в виду большой сложности создаваемых алгоритмов. В связи с этим довольно быстро процесс проектирования переходит к использованию специального САПР имитационного моделирования. Он позволяет создавать модели «рисуя» их в графическом режиме из базовых библиотечных блоков и соединений между ними. Эти библиотечные блоки могут представлять собой совершенно различные по сложности объекты — начиная с сумматоров и логических вентилей и заканчивая готовыми фильтрами, модуляторами и т.п.

Кроме модели самого устройства создается также тестовое окружение — компоненты генерирующие тестовые сигналы (такие же, какие будут в реальной жизни) и компоненты, отвечающие за оценку качества работы устройства. Если говорить о телекоммуникационной области, то в зависимости от конкретного типа создаваемого устройства, оперируют обычно такими основными характеристиками как SNR (signal-to-noise ratio – соотношение сигнал/шум) и BER (bit error rate – веротность возникновения ошибки в канале).
Процедура создания математической модели итерационная — создается первый вариант модели, прогоняются тесты, оцениваются получившиеся характеристики. Далее что-то корректируется/дополняется, прогоняются тесты еще раз и так до тех пор, пока не будут выполнены требования ТЗ.
Традиционно используемые для этих задач САПР — Matlab/Simulink и SPW. Первый из них получил значительно более широкое распространение (по крайней мере в нашей стране).

После создания математических моделей становится возможна реализация алгоритмов на FPGA. В зависимости от требований заказчика могут применяться различные подходы, но основная тенденция — это максимальная автоматизация этапа (как, впрочем и во многих других местах) на базе имеющейся мат. модели. Средства проектирования активно развивают эти возможности. В том случае, если мат. модель выполнена с использованием ряда специальных правил, возможна ее автоматическая адаптация к виду, пригодному для использования в FPGA-проекте. С точки зрения разработчика все выглядит (в идеальной ситуации) очень просто — нажал кнопку и получил VHDL/Verilog код, соответсвующий исходной модели. К сожалению, есть 2 проблемы, которые затрудняют такой подход:
  1. Мат. модель обычно создается для чисел в формате с плавающей точкой, в то время как внутри FPGA вычисления традиционно выполняются в формате с фиксированной точкой (это значительно быстрее и менее ресурсозатратно). В связи с этим необходимо создание промежуточной модели, выполненной в формате с фиксированной точкой. Данный этап выполняется вручную, хотя сейчас идет активная разработка средств, позволяющих автоматизировать этот этап.
  2. Мат. модель создается без дополнительных задержек, которые необходимы в аппаратуре для успешного функционирования устройства на требуемых частотах (т.н. конвейеризация). Кроме того, внесение таких задержек в алгоритсы с обратными связями сказывается на устойчивости системы и требует тщательного перемоделирования.

Так или иначе, в конечном итоге мат. модель оказывается представлена в виде кода который может быть интегрирован в основной FPGA-проект.

При разработке электрической принципиальной схемы в первую очередь производится выбор электронных компонентов исходя из их характеристик, а так же доступности (для покупки). В России сроки поставки компонентов (кроме тех, что уже лежат на российских складах дистрибьютеров) весьма высоки и в приобретении компонентов могут помочь заказчики (при условии, что они находятся в Европе/США/ЮВА, а не где-нибудь в Африке). Но даже в этом случае бывают ситуации, что сроки поставки нужных компонентов могут составлять 20-30 недель и тогда приходится искать замену (и, бывает, вносить изменения в разведенную уже плату).
По завершении создания электрической схемы запускается следующий, тесно с ним связанный этап: трассировка печатной платы. Все выбранные компоненты устройства размещается на печатной плате (ПП) и между ними создаются соединения в соответствии со схемой. В зависимости от сложности (размеры платы, плотность установки компонентов и их количество), число слоев печатной платы обычно составляет 4-12. Естественно, их число стараются минимизировать, но в конечном итоге все зависит от запросов человека, занимающегося трассировкой (разводчика) и его опыта. В процессе трассировки учитывается множество требований, касающихся целостности и времени распространения сигналов по ПП.

Для разработки схемы и трассировки наиболее часто используются такие средства проектирования, как Pads (Expedition) от Mentor Graphics, Cadence OrCAD (Allegro) и Altium Designer. В российской глубинке продолжают активно использовать P-CAD (причем не самой последней версии), но если вы предложите выполненную таким образом схему западному заказчику — вас не поймут (выпуск новых версий P-CAD закончен 5 лет назад, поддержка прекращена в 2008).
После создания окончательной (хе-хе) версии трассировки ПП, она отдается в производство, все последующие модификации производятся скальпелем, паяльной станцией и монтажным проводом. Сама плата производится чаще всего в регионе ЮВА (обычно через российских посредников), компоненты паяются в России (как можно ближе, чтобы недалеко было возить на исправление обнаруженных проблем с пайкой). В виду малой тиражности и высокой сложности создаваемых плат (мы так условились во введении), наладить технологический процесс идеально не удается и потому каждая плата при вводе в эксплуатацию отлаживается/ремонитруется по сути вручную.

После того, как готова схема устройства (т.е. известен перечень компонентов с которыми будет общаться FPGA) можно начинать разработку интерфейсно-сервисных функций FPGA. Разработка проекта для FPGA производится с помощью специальных языков проектирования. Стандартами де-факто на данный момент являются языки VHDL и Verilog. Синтаксически первый из них похож на Аду (Паскаль), второй на Си. Однако у этих языков есть принципиальное отличие — они предназначены не для описания последовательных программ (хотя могут применяться и для этих целей тоже), а для описания аппаратуры, т.е. параллельных структур. Наиболее распространенный способ описания аппаратуры носит наименование RTL (register transfer level – уровень регистровых передач). При этом описываются объекты памяти (триггеры, регистры, блоки памяти) и правила передачи (и трансформации) данных между ними (логика, комбинационнные схемы). Чтобы не быть голословным, описание простейшего счетчика на VHDL выглядит примерно так:
process(clk, rst)
begin
if rst = '1' then cnt <= 0;
elsif rising_edge(clk) then
cnt <= cnt + 1;
end if;
end process;
Естественно, возможно построение иерархических описаний с использованием компонентов, разработанных как вами, так и сторонними разработчиками. Еще один способ описания проекта для FPGA – это графический ввод. В этом случае с помощью специального редактора вы составляете ваше устройства из различных компонентов и соединяете их между собой. На эту тему ведутся бесконечные религиозные войны, краткое резюме которых — описание алгоритмической части схемным способом — это зло, так как проект получается не сопровождаемым (разобраться в нем может только автор и то недолго); описание верхних уровней иерархии графическим способом может быть удобно (дает человеку оценить структуру системы в целом), но затрудняет работу с такими файлами автоматических средств сравнения текстовых файлов (поиск изменений). Для отладки создаваемых компонентов пишутся тесты, чаще всего на тех же VHDL/Verilog, которые позволяют в автоматическом либо ручном (анализирую временные диаграммы) режиме убедиться в правильности работы блока.



В дальнейшем в эту же модель интегрируются DSP-алгоритмы и производятся последние изменения по завершении этапа трассировки печатной платы (интеграция FPGA-проекта). По большому счету, все что говорилось выше по поводу создание проекта на базе FPGA справедливо и при проектировании ASIC, только уровень ответсвеннности значительно выше, поскольку шанса исправить ошибку нет. После того как проект создан, производится его компиляция (автоматическая с использованием различных САПР, в зависимости от используемого типа FPGA) и проект готов к программированию в кристалл. Если производственный план составлен без грубых просчетов, то примерно к этому времени из производства приходит плата и начинается ее тестирование, а в дальнейшем и эксплуатация (демонстрация работы созданных алгоритмов). Естественно, что в процессе работы эти алгоритмы могут изменяться и дополняться, а «перепрограммируемость» FPGA позволяет оперативно вносить их в проект.

Еще один важный этап проектирования — разработка программной части проекта. Создаваемое ПО делится на две категории: реализация пользовательского интерфейса на ПК (если необходимо ручное управление устройством или обмен данными) и создание встроенного ПО (если необходимо прямо на устройстве реализовывать сложные алгоритмы управления, которые неудобно создавать на логике — в этом случае либо на плату ставится отдельный управляющий процессор, либо используется программное ядро процессора, встраиваемое в FPGA).

После того, как получена и спаяна печатная плата, создан проект для FPGA и разработано ПО, способное им управлять, начинается процесс тестирования и отладки. Но это уже совсем другая история.
Tags:fpgaASICСБИС ПЛПЛИСVHDLVerilogMentor GraphicsCadenceAlteraXilinx
Hubs: Electronics for beginners
Total votes 60: ↑58 and ↓2 +56
Views13.4K

Popular right now

Профессия Project Manager
June 17, 202191,000 ₽Нетология
Факультет DevOps
June 17, 2021230,000 ₽GeekBrains
Факультет тестирования ПО
June 17, 2021144,000 ₽GeekBrains
Data Scientist
June 18, 2021126,000 ₽Нетология
Аналитик данных
June 18, 202166,000 ₽Нетология