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

На хабре периодически появляются статьи, посвященные разработке аппаратуры. Однако большинство из них исходят из теоретических позиций (что такое логические элементы, триггеры и т.д.) и на этом останавливаются, либо рассматривают вопрос в аспекте «сделай сам», т.е. что человек может создать самостоятельно в домашних условиях. Мне бы хотелось рассказать о том, как выглядит процедура проектирования аппаратных средств с точки зрения небольшой компании, зарабатывающей этим себе на хлеб с маслом.
Но сначала несколько слов о специфике данной области (по крайней мере в нашей стране). Приходится исходить из следующих реалий:
  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 и разработано ПО, способное им управлять, начинается процесс тестирования и отладки. Но это уже совсем другая история.

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 30

    +2
    Вау, спасибо! Ждем продолжения…
      0
      Нас в универе учили xilinx spartan II программировать. Очень интересная штука и если бы не цена макетной платы (от 8 т.р.), то я бы и сейчас чего-нибудь на ней придумывал бы =).
        0
        А меж тем бывают варианты весьма бюджетные. Например Altera MAX3000 — 63 рубля. Это конечно не макетка, а просто сам кристалл, и до Spartan II ему далеко, но всё же, для начала освоения весьма неплохо и бюджетно.
        • UFO just landed and posted this here
          • UFO just landed and posted this here
            0
            возможно самый дешевый вариант вот здесь — marsohod.org/index.php/projects
            это open source плата для экспериментов с ПЛИС и там же есть много «проектов»
          • UFO just landed and posted this here
              0
              Википедия — Программируемая пользователем вентильная матрица goo.gl/U8TK7
              0
              Здорово написано, читал с удовольствием. Интересно, а сколько по времени занимает разводка платы в слоев так 12, по размерам типа материнки ATX? И сколько памяти при этом отжирается? Помню лет 12-14 назад это было не так просто. Был специальный двухпроцессорный сервер на каких-то третьих пеньках и 512Mb памяти, что по тем временам было адски круто, но даже при этом процесс занимал от суток времени.
                0
                Разводка платы — у нас процесс ручной, к сожалению. Современные САПР обладают возможностями автоматической трассировки, но нашим разводчикам удовлетворительного результата добиться не удалось. К этому вопросу периодически возвращаются, но пока увы… Ну а сроки ручной разводки — вещь растяжимая. ATX — довольно большая плата, я бы ориентировался на 4-5 недель. По большому счету, все сильно ещ зависит от плотности расположения компонентов и разных специальных требований (если есть RF-часть).
                  0
                  Ах вот оно как, в ручную значит… А там был именно какой-то супер крутой софт, который автоматически разводил с указанными параметрами. Ну или не разводил. Вот так сутки другие ждешь — а он тебе — сорри бразе, но при такой конфе никак не получается у меня как ты хочешь…
                    +1
                    Как я понимаю, оно и сейчас примерно так происходит. Сам я разводкой ПП не занимаюсь, но по моим представлениям ситуация выглядит так: чтобы получить разумную разводку, надо весьма четко формализовать требования. А сделать это порой не проще (не быстрее), чем развести вручную.
                    А вот при трассировке кристалла ситуация с автоматической трассировкой куда как лучше — она работает. Для кристаллов средней емкости (по нынешним временам 50-200k триггеров) вполне подходит обычная машинка (памяти 2 Гб — вполне). Процесс трассировки в нормальных условиях занимает минут 5-15 (если нет серьезных требований по скорости). Если проект находится на границе возможностей кристалла, то несколько часов, вплоть до суток.
                0
                приятно вспомнить, как занимался этим в 1990-м году на первом в нашем тогдашнем НИИ компьютере PC XT Amstrad и крякнутом неизвестным соотечественником P-Cad'е.
                У нас это называлось базовый матричный кристалл полузаказной БИС. Микросхема была аналоговой, слоев металлизации два, технические нормы 2 микрона…
                  0
                  В универе очень с этим намучался, а точнее с упомянутым выше со Spartan 2E. Особенно бесили глючные кнопки (там их 4 если не ошибаюсь), которые в лабах обязательно надо было использовать. Кнопки (видимо ввиду неаккуратного использования платы моими предшественниками) часто срабатывали без моего ведома в каком то случайном порядке, постоянно сбивая порядок нормальной работы несложного устройства, которое я старался разработать. Причем такая ситуация была практически у всех. Так что охоту отбили этим интересоваться, хотя мне нравилось в общем-то, интересно что-то своими руками сделать, тем более что для простых устройств там очень глубоких знаний схемотехники не надо.
                    +1
                    Дребезг контактов тоже надо обрабатывать. Это вам железо, а не кнопочки в дельфи лепить ;)
                      0
                      Ну кнопочки в дельфи лепить это совсем не мое, так что не совсем понимаю к чему была эта часть вашего коммента, пропущу мимо ушей (глаз).
                      Но факт в том, что были несколько нормально работающих схем, а были вот такие, шальные.
                        +1
                        Целью высказывания было не оскорбить вас, а привлечь внимание к тому факту, что при создании компьютерной программы, все что касается нажатий кнопок, за вас делает сама ide или заранее написанная функция, а при работе с железом вы скорее всего не использовали какие-то специальные библиотеки.

                        Почитайте про дребезг контактов и способы борьбы с ним.
                        Что такое дребезг контактов
                        Подавление дребезга механических контактов

                        На VHDL это можно было реализовать, например, в виде счетчика, который бы не давал принимать нажатия, произошедшие раньше чем за 1с (промежуток по желанию) после предыдущего.
                          0
                          За ссылки спасибо, почитаю. В железе действительно я мягко говоря профан, максимум собрать из готового чет свое, но сама идея программирования платы мне безумно понравилась тогда. Надо будет возобновить изучение уже в рамках «для себя».
                          А по поводу дельфи не обессудьте, просто мне лично сравнение с «кнопколепителем» не очень понравилось, видимо не понял что вы имели ввиду этой фразой.
                      0
                      Электроника — наука о контактах (й)
                      У меня лабы по схемотехнике проходили на стендах, в которые втыкались дискретные элементы (155 серии) и провода их соединяющие. Как результат, сперва надо было найти неглючащие провода и микросхемы, собрать стенд, и делая пасы руками, подобрать такое положение проводков, чтобы везде был контакт. После чего надо было быстро (но осторожно) бежать за преподавателем — демонстрировать.
                        0
                        ОО дааа помню я эти стенды. У нас только элементы все были под корпусом, но вот всю логику (а это несколько функций, например программа станка глубокого сверления) приходилось делать ущербными проводами… Адская лабораторная.
                        0
                        Правильно заставляли. Значит изначально надо было учитывать в устройстве дребезги кнопок, а не жаловаться на неаккуратное их использование.
                        +6
                        Елки, меня опередили. хотела написать о сборке какого-нибудь простейшего микропроцессора на ПЛИС
                          +3
                          Женщина? Микропроцессоры? ПЛИС? Обоже, куда катится этот мир!
                            0
                            тсс.
                            0
                            Никто вроде не запрещает, ждем…
                              0
                              Э нет, теперь вы просто обязаны написать о сборке какого-нибудь простейшего микропроцессора на ПЛИС)) Серьезно, ждем.
                                0
                                гуд) как только госы сдам…
                              +2
                              >скоростях потоков данных порядка 100 МГц
                              Ы?
                                0
                                Думаю речь шла о сотнях мегабод, ну это в лучшем случае. Так то понятно что данные скорее всего будут идти медленнее теоретического предела.
                                  0
                                  Криво сформулировал. Имелось в виду, что частота оцифровки/обработки данных составляет 100 МГц и более. Разрядность обычно 10/12 с АЦП и 16 и более внутри при обработке.

                                Only users with full accounts can post comments. Log in, please.