На хабре периодически появляются статьи, посвященные разработке аппаратуры. Однако большинство из них исходят из теоретических позиций (что такое логические элементы, триггеры и т.д.) и на этом останавливаются, либо рассматривают вопрос в аспекте «сделай сам», т.е. что человек может создать самостоятельно в домашних условиях. Мне бы хотелось рассказать о том, как выглядит процедура проектирования аппаратных средств с точки зрения небольшой компании, зарабатывающей этим себе на хлеб с маслом.
Но сначала несколько слов о специфике данной области (по крайней мере в нашей стране). Приходится исходить из следующих реалий:
Одна из немногих успешно работающих моделей — контрактные разработки для западных заказчиков. Идея проста: у нас заказывают наукоемкие исследования/разработки, результаты собирают вместе где-нибудь в Калифорнии (обычно по цепочке через нескольких посредников) и продают в конечном итоге какой-нибудь крупной корпорации-производителю электроники. Тому же Интелу, к примеру. Года через 2-3 все это возвращается к нам в составе сложных агрегатов (телефонов, мониторов и т.д.) в красивой коробке с клеймом “Made in USA” (что редко) либо “Made in China” (значительно чаще) по червонцу за пучок. Ситуация с одной стороны грустная — мы не владеем технологической цепочкой, а способны решать лишь отдельные задачи. Но есть и основания для оптимизма — таким образом российские разработчики входят в общемировую систему и получают ценный опыт. Компания, в которой я работаю, специализируется в основном на исследовательских разработках в области беспроводных коммуникаций. Исходя из этого я и буду вести дальнейший рассказ.
Как же выглядит процесс разработки?
Изначально заказчик предоставляет некоторую информацию (пожелания) о том, какие задачи необходимо решить и в каком виде представить результат. Обычно это математические модели, реализующие алгоритмы, которые предстоит разработать и аппаратура, с помощью которой можно продемонстрировать воплощение алгоритмов «в железе». При взаимодействии обеих сторон составляется техническое задание (ТЗ), которое содержит полную информацию о параметрах создаваемого устройства (диапазоны частот, скорости передачи данных, используемые типы модуляции и т.д.), требования к характеристикам устройства и способы тестирования. Как нетрудно догадаться (чудес, увы, не бывает), в процессе разработки эти параметры могут корректироваться (как с одной стороны, так и с другой) и приходится искать компромиссы. В общем случае, структура создаваемого устройства (телефона, модема) для беспроводной передачи данных выглядит примерно так:
Далее следует этап системного проектирования. Рисуется структурная схема устройства и связи между компонентами. Производится оценка ресурсоемкости задачи, выбирается аппаратура, которая будет реализовывать создаваемые алгоритмы. По большому счету, имеется три пути:
Так же фиксируются параметры других критически важных элементов создаваемой системы — необходимые частоты АЦП и ЦАП, параметры RF (радиотракт — высокочастотная часть) и прочие.
Последующие этапы проходят параллельно по мере готовности предыдущих. Изначально запускается разработка математических алгоритмов и разработка электрической схемы устройства.
Разработка математических алгоритмов начинается обычно с изучения тематической литературы и рисования каких-либо базовых вещей на бумажке. Однако теоретический подход, к сожалению, применяется слабо в виду большой сложности создаваемых алгоритмов. В связи с этим довольно быстро процесс проектирования переходит к использованию специального САПР имитационного моделирования. Он позволяет создавать модели «рисуя» их в графическом режиме из базовых библиотечных блоков и соединений между ними. Эти библиотечные блоки могут представлять собой совершенно различные по сложности объекты — начиная с сумматоров и логических вентилей и заканчивая готовыми фильтрами, модуляторами и т.п.
Кроме модели самого устройства создается также тестовое окружение — компоненты генерирующие тестовые сигналы (такие же, какие будут в реальной жизни) и компоненты, отвечающие за оценку качества работы устройства. Если говорить о телекоммуникационной области, то в зависимости от конкретного типа создаваемого устройства, оперируют обычно такими основными характеристиками как SNR (signal-to-noise ratio – соотношение сигнал/шум) и BER (bit error rate – веротность возникновения ошибки в канале).
Процедура создания математической модели итерационная — создается первый вариант модели, прогоняются тесты, оцениваются получившиеся характеристики. Далее что-то корректируется/дополняется, прогоняются тесты еще раз и так до тех пор, пока не будут выполнены требования ТЗ.
Традиционно используемые для этих задач САПР — Matlab/Simulink и SPW. Первый из них получил значительно более широкое распространение (по крайней мере в нашей стране).
После создания математических моделей становится возможна реализация алгоритмов на FPGA. В зависимости от требований заказчика могут применяться различные подходы, но основная тенденция — это максимальная автоматизация этапа (как, впрочем и во многих других местах) на базе имеющейся мат. модели. Средства проектирования активно развивают эти возможности. В том случае, если мат. модель выполнена с использованием ряда специальных правил, возможна ее автоматическая адаптация к виду, пригодному для использования в FPGA-проекте. С точки зрения разработчика все выглядит (в идеальной ситуации) очень просто — нажал кнопку и получил VHDL/Verilog код, соответсвующий исходной модели. К сожалению, есть 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 выглядит примерно так:
В дальнейшем в эту же модель интегрируются DSP-алгоритмы и производятся последние изменения по завершении этапа трассировки печатной платы (интеграция FPGA-проекта). По большому счету, все что говорилось выше по поводу создание проекта на базе FPGA справедливо и при проектировании ASIC, только уровень ответсвеннности значительно выше, поскольку шанса исправить ошибку нет. После того как проект создан, производится его компиляция (автоматическая с использованием различных САПР, в зависимости от используемого типа FPGA) и проект готов к программированию в кристалл. Если производственный план составлен без грубых просчетов, то примерно к этому времени из производства приходит плата и начинается ее тестирование, а в дальнейшем и эксплуатация (демонстрация работы созданных алгоритмов). Естественно, что в процессе работы эти алгоритмы могут изменяться и дополняться, а «перепрограммируемость» FPGA позволяет оперативно вносить их в проект.
Еще один важный этап проектирования — разработка программной части проекта. Создаваемое ПО делится на две категории: реализация пользовательского интерфейса на ПК (если необходимо ручное управление устройством или обмен данными) и создание встроенного ПО (если необходимо прямо на устройстве реализовывать сложные алгоритмы управления, которые неудобно создавать на логике — в этом случае либо на плату ставится отдельный управляющий процессор, либо используется программное ядро процессора, встраиваемое в FPGA).
После того, как получена и спаяна печатная плата, создан проект для FPGA и разработано ПО, способное им управлять, начинается процесс тестирования и отладки. Но это уже совсем другая история.
Но сначала несколько слов о специфике данной области (по крайней мере в нашей стране). Приходится исходить из следующих реалий:
- невозможно в наших условиях соревноваться с интелом или хотя бы TI в выпуске процессоров и прочих разных микросхем — цена вхождения очень высока, рынки сбыта поделены, и, по большому счету, нет необходимых знаний и опыта;
- бессмысленно соревноваться с китайцами в производстве всевозможной массовой электроники — стоимость труда у них ниже, производственные мощности находятся у них же, рынки сбыта в руках крупных компаний;
- можно окучивать отечественные рынки различной несложной электроникой — от сигнализаций до елочных гирлянд. Кто-то живет этим, но норма прибыли невысока, а мороки много;
- можно участвовать в государственной программе поддержки бедных (РосПил). Отличная тема, но меня пригласить забыли.
Одна из немногих успешно работающих моделей — контрактные разработки для западных заказчиков. Идея проста: у нас заказывают наукоемкие исследования/разработки, результаты собирают вместе где-нибудь в Калифорнии (обычно по цепочке через нескольких посредников) и продают в конечном итоге какой-нибудь крупной корпорации-производителю электроники. Тому же Интелу, к примеру. Года через 2-3 все это возвращается к нам в составе сложных агрегатов (телефонов, мониторов и т.д.) в красивой коробке с клеймом “Made in USA” (что редко) либо “Made in China” (значительно чаще) по червонцу за пучок. Ситуация с одной стороны грустная — мы не владеем технологической цепочкой, а способны решать лишь отдельные задачи. Но есть и основания для оптимизма — таким образом российские разработчики входят в общемировую систему и получают ценный опыт. Компания, в которой я работаю, специализируется в основном на исследовательских разработках в области беспроводных коммуникаций. Исходя из этого я и буду вести дальнейший рассказ.
Как же выглядит процесс разработки?
Изначально заказчик предоставляет некоторую информацию (пожелания) о том, какие задачи необходимо решить и в каком виде представить результат. Обычно это математические модели, реализующие алгоритмы, которые предстоит разработать и аппаратура, с помощью которой можно продемонстрировать воплощение алгоритмов «в железе». При взаимодействии обеих сторон составляется техническое задание (ТЗ), которое содержит полную информацию о параметрах создаваемого устройства (диапазоны частот, скорости передачи данных, используемые типы модуляции и т.д.), требования к характеристикам устройства и способы тестирования. Как нетрудно догадаться (чудес, увы, не бывает), в процессе разработки эти параметры могут корректироваться (как с одной стороны, так и с другой) и приходится искать компромиссы. В общем случае, структура создаваемого устройства (телефона, модема) для беспроводной передачи данных выглядит примерно так:
Далее следует этап системного проектирования. Рисуется структурная схема устройства и связи между компонентами. Производится оценка ресурсоемкости задачи, выбирается аппаратура, которая будет реализовывать создаваемые алгоритмы. По большому счету, имеется три пути:
- Использовать DSP-процессоры (цифровые сигнальные процессоры). Они хороши в ситуациях, когда необходимо реализовывать сложные алгоритмы для потока данных следующих на не очень высокой скорости — алгоритмы, которые удобно описывать с помощью последовательных программ. К сожалению, их производительности хватает далеко не во всех случаях. Несколько миллиардов умножений в секунду — это совсем не много при скоростях потоков данных порядка 100 МГц и более.
- Заказные СБИС (ASIC) – отличный путь для богатых и смелых. Они проектируются под конкретную задачу, поэтому не содержат лишней логики; рабочие частоты 1-2 ГГц. В тех случаях, когда планируется выпускать большую партию устройств (сотни тысяч штук), создание заказной СБИС позволяет получить максимальную производительность при минимальной цене за единицу товара. К сожалению, удовольствие это весьма дорогое. Создание одной ревизии микросхем по не самым современным технологическим нормам стоит порядка 1 млн. долларов.
- СБИС Программируемой Логики (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 проблемы, которые затрудняют такой подход:
- Мат. модель обычно создается для чисел в формате с плавающей точкой, в то время как внутри FPGA вычисления традиционно выполняются в формате с фиксированной точкой (это значительно быстрее и менее ресурсозатратно). В связи с этим необходимо создание промежуточной модели, выполненной в формате с фиксированной точкой. Данный этап выполняется вручную, хотя сейчас идет активная разработка средств, позволяющих автоматизировать этот этап.
- Мат. модель создается без дополнительных задержек, которые необходимы в аппаратуре для успешного функционирования устройства на требуемых частотах (т.н. конвейеризация). Кроме того, внесение таких задержек в алгоритсы с обратными связями сказывается на устойчивости системы и требует тщательного перемоделирования.
Так или иначе, в конечном итоге мат. модель оказывается представлена в виде кода который может быть интегрирован в основной 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 и разработано ПО, способное им управлять, начинается процесс тестирования и отладки. Но это уже совсем другая история.
