Русский
Русский
English
Статистика
Реклама

История разработки

Почему бизнес хочет DevOps и что нужно знать инженеру, чтобы говорить с ним на одном языке

27.10.2020 14:04:24 | Автор: admin
Последние несколько лет мы при каждом удобном случае снова и снова обсуждаем, что же такое DevOps. Это уже порядком надоело, но раз всё еще происходит, значит есть проблема проблема взаимодействия бизнеса и инженеров.

Я часто вижу, как люди, пришедшие к применению DevOps из разных сфер, говорят на разных языках и понимают под словом DevOps совершенно разное. В итоге в какой-то момент времени оказывается, что участники проекта по трансформации абсолютно не понимают и друг друга, и зачем нужен весь этот DevOps тоже.



Я не хочу рассуждать о том, что такое DevOps и какое его понимание более правильное. Мне интересно проследить за эволюцией процессов в IT и разобраться, что бизнес хочет получить от внедрения DevOps, что это значит для инженеров и как нам быть на одной волне.

N.B.: Материал для этой статьи лёг в основу моего выступления на DevOps Live, поэтому вместо чтения можно послушать доклад он вполне сойдёт за подкаст.

На примере клиентов ITSumma я вижу, как изменились запросы бизнеса в последние несколько лет. Мы занимаемся сопровождением сложных информационных систем с 2008 года, и поначалу это в основном была работа по обеспечению отказоустойчивости сайтов, но теперь появились кардинально новые запросы. Раньше важнее всего было, чтобы продакшен стабильно работал, был готов к масштабированию, а в случае аварии быстро поднимался. Теперь не менее важным стало обеспечение отказоустойчивости платформ разработки и систем выкладки.
В крупных компаниях произошло смещение системы ценностей: стабильная работа develop-окружения теперь так же важна, как и надежность продакшена.
Чтобы проследить траекторию и понять, что изменилось в мышлении и где мы теперь, погрузимся ненадолго в историю разработки программного обеспечения.

Немного истории разработки


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

Мейнфреймы. 19601980-е годы


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

Пользователи: сотрудники компании. Число пользователей программ того времени очень ограниченно: это 3 космонавта корабля Аполлон, 20 человек, рассчитывающих государственный бюджет, 100 человек, обрабатывающих результаты переписи населения.

Дистрибуция ПО: физическая, на мейнфрейме. Пробиваются перфокарты, загружаются в ЭВМ, и минут через 10 программа готова к использованию. За доставку, по сути, отвечает человек, который пробивает перфокарты. При этом если программист допустил ошибку, то исправлять её долго: заново писать и отлаживать код, пробивать перфокарты, загружать. На всё это уйдут дни и впустую будет потрачено время многих людей цена ошибки очень высока, возможно, катастрофа.

На этом этапе IT-бизнеса как такового еще не существует. Если посмотреть в Википедии количество компаний по производству ПО, основанных в 1975-м, то их там будет всего четыре. Правда, одна из них Microsoft, которая тогда была очень маленькой и нишевой.

Персональные компьютеры и ООП. 1980-1990-е годы


Все начинает меняться примерно в 1985 году с массовым распространением персональных компьютеров: в 77-м началось производство Apple II, в 81-м появился IBM PC, чуть раньше стали популярны минимейнфреймы от DEC.

Особенности периода: создание программного обеспечения начинает формироваться в бизнес-направление. Это становится возможным, потому что пользователей программ стало больше и можно строить программы на продажу.

Например, в 79-м появляется электронная таблица VisiCalc, которая заменяет собой бухгалтера-калькулятора человека, который фактически работал excel'ем. Бухгалтер заносил в большую бумажную таблицу числа и как-то по формулам их обрабатывал. Потом аналитик спрашивал, что будет, если доход в третьем квартале будет в два раза больше, и бухгалтер-калькулятор менял одно значение и снова всё пересчитывал на бумаге.

Пользователи: внешние по отношению к производителю ПО компании. VisiCalc перевернул всю индустрию компьютерного бизнеса, программа, вместо узконаправленной штуки, которая пишется для конкретного набора людей, стала массовой. Например, экономисты и аналитики стали покупать компьютеры, чтобы использовать электронные таблицы.

Поскольку пользователей стало много и программы начали продавать частным лицам, возникает вопрос: как сделать так, чтобы программа работала у такого большого количества людей, и как разрабатывать такие сложные программы.

Поскольку расширяется аудитория, то нужна и большая функциональность. Соответственно, нужно увеличивать команду разработки это уже не десяток программистов, а 100-500 человек, которые работают над сложным программным продуктом.

Интересно, что в каждой эпохе становления IT есть несколько ключевых книг, которые в своё время вызвали переворот в мышлении. Период, когда зарождается бизнес разработки программного обеспечения и команды разработчиков растут, на мой взгляд, характеризуется двумя книгами: Мифический человеко-месяц и Приёмы объектно-ориентированного проектирования. Паттерны проектирования. То есть с одной стороны появляется понимание, что невозможно, увеличив команду в 4 раза, сократить время разработки в 4 раза. А с другой что есть решение, которое способно помочь масштабироваться.

Популярным решением проблемы роста сложности ПО становится ООП. Считается, что если взять большую программу, допустим, Microsoft Excel, и разбить на какие-то объекты, то группы разработчиков смогут работать над ними независимо. Таким образом получится масштабировать работу на отдельные элементы функциональности и ускорить разработку нашего Microsoft Excel. Причем под ускорить, скорее всего, понимается цикл разработки в несколько лет.
Аргументация внедрения ООП звучит очень похоже на плюсы микросервисной архитектуры.
Но по сути, мы по-прежнему упаковываем программу в один пакет exe-файл во времена повсеместного использования Microsoft DOS, а потом Windows и поставляем пользователю.

Доставка ПО: на физических носителях. Но так как теперь это массовое производство, то доставка ПО заключается в том, чтобы: записать наш exe-шник на дискеты, наклеить на них наклейки с названием продукта, упаковать в коробки и буквально доставить пользователям в разных странах. При этом необходимо не допустить существенное количество брака, потому что если произвести дискеты где-нибудь в Америке, доставить в Россию и обнаружить, что половина из них с браком, это будут огромные издержки и мы потеряем пользователей насовсем.

Цена ошибки: пользователи вернут деньги и больше никогда не купят продукт, что может погубить весь бизнес.

Цикл разработки ПО просто потрясающе долог, этапы занимают месяцы:

  • планирование 12 месяцев;
  • разработка 24 месяца;
  • тестирование 12 месяцев;
  • доставка 12 месяцев.

Новая версия выпускается раз в несколько лет, поэтому никак нельзя допускать ошибки на этапе кодирования.

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

Представьте: мы придумали новый IT-продукт, провели небольшое исследование и решили, что, возможно, эта программа понравится пользователю. Но убедиться в этом мы никак не можем! Мы можем только два года писать софт, а потом попросить бухгалтеров у себя в округе, например, в Редмонде, поставить новую версию Excel и попробовать её использовать. И это по сути все наши возможности для тестирования продукта. Поэтому не исключено, что через два года разработки окажется, что наше ПО никому не нужно.

Если же наш софт всё-таки покупают, но он имеет баги и плохо работает, то пользователи легко могут его вернуть это еще физический товар, коробка, которую можно принести обратно в магазин. И заодно решить, что покупать ПО этого производителя больше никогда не стоит.

Agile. 20012008


Следующая эра начинается с распространением интернета в 2000-х.

Особенности периода: IT-бизнес переходит в интернет, но браузеры работают еще так себе.

Microsoft создаёт Internet Explorer и бесплатно поставляет его всем пользователям Windows. Интернет становится доступен огромному числу людей, но при этом браузер Microsoft целенаправленно сделан не очень пригодным для реализации динамической функциональности, чтобы защитить свои программы от конкуренции со стороны браузерных приложений и Netscape (подробнее по запросу Война браузеров). Поэтому интернет еще используется в основном для загрузки файлов, но этого уже достаточно, чтобы бизнес перешёл в интернет.

Доставка ПО: дистрибутивы становится возможно распространять через интернет.

Дистрибуция ПО через интернет позволяет гораздо чаще раз в несколько месяцев выпускать обновления и новые версии. Больше не обязательно записывать ПО на дискеты и диски пользователи могут скачать обновления из интернета, а разработчики могут допускать больше ошибок.

Цена ошибки: риск для бизнеса уже не так велик, потому что пользователь может получить обновление и продолжить пользоваться продуктом.

Где-то в это время зарождается Agile и выходят книги о гибкой разработке и экстремальном программировании, которые и для современного IT-менеджмента являются классической основой, например: Extreme Programming Explained: Embrace Change, Refactoring. Improving the Design of Existing Code, Test Driven Development.
Основная идея в том, что раз доставлять ПО можно через интернет, то цикл производства может быть гораздо короче, а новую версии можно выпускать каждые полгода.
Цикл разработки в начале 2000-х выглядит примерно так:

  • планирование 2 месяца;
  • разработка 6-12 месяцев;
  • тестирование 1-3 месяца;
  • доставка несколько недель.

Можно, например, больше не тестировать так тщательно. Если у 10% пользователей проявятся баги, то для них можно выпустить патч, а не тратить заранее год на то, чтобы убедиться, что наше ПО работает как надо абсолютно везде. Таким образом, можно гораздо быстрее проверять гипотезы, но быстрее тут это по-прежнему полгода-год.

То, что можно меньше вкладываться в тестирование и детальное планирование, позволяет сократить расходы на проведение эксперимента. И слово эксперимент станет ключевым в следующую эпоху.

DevOps. 20092020


Особенности периода: устанавливаемого ПО практически не осталось, а немногое существующее обновляется через интернет. Интернет используется повсеместно, становятся популярны социальные сети и развлекательный софт, которые живут исключительно в интернете. Реализовывать сложную динамическую функциональность интерфейсов можно непосредственно в браузере и мы переходим туда.

Доставка ПО: посредством Облака. Если раньше, программа всё равно устанавливалась на компьютер пользователя и для него должна была быть отлажена, то теперь по сути нужно сделать программу лишь под один компьютер сервер в Облаке. Для нас это удобно тем, что у нас есть полный контроль над этим компьютером и тем, как работают на нём наши программы. Конечно, остаются некоторые трудности с отрисовкой интерфейсов в браузере, но они гораздо менее серьезные чем те, что были раньше.

Всё это позволяет ускорить планирование, реализацию, тестирование. Больше нам не нужно месяцами или годами жить с чёрной дырой неизвестности: выстоит ли проект или нет, нужна ли в нём такая функциональность и т.д. Обновлять ПО можно практически в реальном времени.

Но в 2006-2008 идеологически ПО еще разрабатывается по-прежнему как некое цельное ядро. Это, конечно, не exe'шник, но это всё равно цельный монолит, состоящий из набора очень плотно связанных объектов. Такое ПО слишком тяжеловесное, для того чтобы меняться так быстро, как этого хочет рынок.

Для решения проблемы неповоротливости монолита те же самые ребята, которые принесли нам ООП, говорят, что приложение можно и в целом разделить на отдельные программы, которые будут между собой коммуницировать. И тогда будет возможным ещё больше увеличить команду разработчиков с сотен до тысяч и создавать новую функциональность непрерывно. Тем самым проводить как можно больше экспериментов, проверять гипотезы, адаптировать бизнес под запросы рынка и действия конкурентов и двигать его вперед.

В 2009 году выходит первый доклад о том, как Dev и Ops объединяются, чтобы обеспечить 80 деплоев в день, и это становится одной из главных ценностей в разработке. Цикл разработки теперь выглядит совершенно по-другому:

  • планирование несколько недель;
  • разработка несколько недель;
  • тестирование несколько дней;
  • доставка несколько минут.

Ошибки можно исправлять практически на лету и разрабатывать гипотезу очень быстро. Тут же появляется всем известное теперь слово MVP.

Если в 70-е у разработчика почти не было права на ошибку и ПО было фактически недвижимым при запуске космонавтов на луну требования к функциональности не часто меняются то теперь софт становится абсолютно динамическим. Все готовы к тому, что будут баги, поэтому и нужна поддержка и команда, которая будет обеспечивать работу системы в условиях динамичного развития.
В новой эпохе впервые за историю развития IT специальность, связанная с доставкой ПО, стала действительно айтишной.
До этого профессия человека, который обеспечивал систематическую доставку программного обеспечения, вообще говоря, не была айтишной. В 70-80-е это были люди, которые засовывали перфокарты в компьютеры, в 80-90-е люди, которые грамотно вели переговоры с фабриками и заводами по производству дисков и занимались логистикой. Это всё абсолютно не связано ни с разработкой, ни с системным администрированием.

Не погруженные глубоко в тему DevOps люди часто думают, что DevOps это новое клёвое название для админов, которые больше общаются с разработчиками. Но бизнес (и википедия) считает, что DevOps это методология внутри процесса разработки ПО. И не так важно, что конкретно она означает, важно, что она дает. А дает DevOps как методология возможность максимально быстро адаптироваться к изменениям рынка и менять сам процесс разработки ПО.

Если компания не хочет отставать от конкурентов, то ей нужно переходить от длинных циклов разработки и релизов раз в месяц к DevOps. DevOps-трансформация при этом означает обеспечение Agile-процесса целиком от разработки до выкладки. И таким образом процесс доставки ПО включается в процесс разработки и становится айтишной специальностью.

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

У большинства админов, которые занимаются обеспечением отказоустойчивости, идеология работает не трожь! находится во главе угла. Они хоть и не запускают Аполлон на Луну, но мыслят теми же категориями надежности. А бизнес в новых условиях, пускай и ценой сбоев, хочет:

  • минимальное время от идеи до продакшена;
  • максимальное количество проверенных гипотез за короткое время;
  • минимальное влияние ошибок на работу продакшена.

Пускай оно сразу упадет это ничего, мы откатим, поправим и снова выложим. Лучше быстрее проверить, чем вкладываться во что-то, на что не будет спроса.
Подход к отказоустойчивости меняется: больше не нужно, чтобы текущая версия ПО была стабильной на протяжении долгого времени нужно, чтобы ошибка в текущей версии ПО минимально влияла на работоспособность всей системы.
Не нужно обеспечивать стабильность маленького кусочка нового кода; нужно иметь возможность выкинуть его как можно быстрее и вернуть тот, который работал. Это опять про гибкость: ценность не в стабильности кода, который выложен в инфраструктуре, а в способности инфраструктуры быть максимально гибкой.

Как инженеру пойти навстречу бизнесу


Итак, что же мы можем сделать, чтобы найти больше пересечений с ценностями бизнеса?

Если мы говорим, что внедрение DevOps служит нуждам бизнеса, то должен быть способ понять, делает ли инженер то, что нужно бизнесу. Вот какие метрики можно ввести, если изучить отчёт DORA State of DevOps и исследование состояния DevOps в России:

  • Частота деплоев (deployment frequency) как часто вы деплоите код в продакшен или как часто ваши конечные пользователи получают новые релизы.
  • Время внесения изменений (lead time for changes) от коммита кода в репозиторий до его выкладки в продакшен.
  • Время, за которое сервис восстанавливается после сбоя или аварии (time to restore).
  • Частота аварий, вызванных выкладкой изменений (change failure rate) какой процент деплоев приводит к ухудшению качества обслуживания пользователей и требует исправлений, например, откатов.

Эти метрики позволяют оценить, как компания использует возможности DevOps. В то же время, посмотрев на эти метрики, инженер может понять, какими своими действиями он может помочь бизнесу.

Частота деплоев


Понятно, что чем чаще компания деплоится, тем вернее она движется по пути DevOps-трансформации. Но деплоиться часто страшно. Однако DevOps-инженер может помочь справиться с этими страхами.

Страх 1: выложим что-то плохо протестированное, из-за чего продакшен упадет под нагрузкой.

Роль DevOps: обеспечить возможность легкого отката, помочь автоматизировать тестирование в инфраструктуре.

Страх 2: выложим новую функциональность с багами, а её внедрение изменит данные или структуру данных настолько, что откатиться будет невозможно.

Роль DevOps: работать в связке с разработчиками и помочь в архитектурных решениях, предложить эффективные методы миграции данных и т.д.

Страх 3: выкладывать долго и сложно (практика показывает, что 20 минут на сборку docker обычная история).

Роль DevOps: обеспечить скорость деплоя и отката, ускорить процесс сборки.

Время внесения изменений


Это отчасти менеджерская метрика, потому что именно менеджер должен организовать процесс так, чтобы код, который написал разработчик, можно было максимально быстро закоммитить и задеплоить. Устранить препятствия на этом пути тоже может помочь DevOps-инженер.

Проблема 1: долго проходит pull request. Например, потому что есть ревью и ревью на ревью. В корне этой проблемы лежит всё та же боязнь выложить код.

Роль DevOps: работать с менеджером разработки в вопросе автоматизации принятия PR.

Проблема 2: долгий ручной процесс тестирования.

Роль DevOps: помочь автоматизировать тестирование.

Проблема 3: долгая сборка.

Роль DevOps: мониторить время сборки, уменьшать его.

Поэтому DevOps-инженеру нужно, во-первых, понять, как тестируется софт, как тестирование автоматизируется и как автоматизацию тестирования можно интегрировать в процесс сборки ПО. Во-вторых, разложить весь пайплайн выкладки ПО на составляющие и найти, где его можно ускорить. Замониторьте весь процесс от коммита до выкладки в продакшен, узнайте, сколько идет сборка, сколько pull request ждёт аппрува, и вместе с менеджером и разработчиками придумайте, на чём можно сэкономить.

Время восстановления работоспособности


Time to restore время, за которое сервис восстанавливается после сбоя или аварии, метрика, гораздо более близкая к SRE.

Проблема 1: сложно локализовать техническую проблему.

Роль DevOps: организовать observability, вместе с разработкой обеспечить инфраструктуру для мониторинга и настроить систему мониторинга так, чтобы эффективно следить за работой сервиса.

Проблема 2: инфраструктура не готова к легкому процессу отката.

Роль DevOps: обеспечить техническую возможность.

Проблема 3: после миграции невозможно откатиться.

Роль DevOps: научить разработчиков практикам миграции данных, позволяющим легкие откаты, и практикам отказоустойчивости.

Частота аварий


Change failure rate как часто выложенный код падает это снова про менеджмент и идеологию, но здесь есть интересный момент: код часто падает, если его редко выкладывать.

К сожалению, я видел случаи, когда компания берет курс на DevOps-трансформацию, внедряет GitOps и Kubernetes, но частота релизов от этого не меняется. Подход остаётся прежним, и разработка новой версии как занимала полгода, так и занимает полгода. А если вы пишете код, который на протяжении месяцев не выкладываете в продакшен, то он упадет с гораздо большей вероятностью, чем код, который выкладывается каждую неделю. Этого разрушает весь процесс целиком: если компания взяла курс на DevOps, а при этом цикл разработки занимает шесть месяцев, то это какая-то беда.

В таком случае DevOps должен забить тревогу и попытаться ещё раз объяснить суть DevOps-подхода и то, как изменился подход к разработке за последние годы.

Дивный новый мир


Нам как инженерам нужно понимать, что же важно для бизнеса, и на это и направлять свои усилия.

  • Стабильность текущей версии кода не так важна, как стабильность инфраструктуры целиком и возможность откатиться к предыдущей версии, изолировать проблему и быстро её исправить.

  • Стабильность окружения разработки, его производительность критически важна, особенно если в команде сотни разработчиков. Когда разработчики из-за проблем со средой разработки вынуждены ждать, это равносильно простою фабрики.

  • Мониторинг процесса доставки ПО стал частью мониторинга всей инфраструктуры. Если что-то выкладывается 20 минут, то надо попытаться это ускорить.
  • Скорость доставки ПО становится одной из ключевых задач, нужно обеспечить такую молотилку и чтобы она при этом работала как часы.
  • Создание удобных окружений для разработки ещё одна ключевая задача. Если разработчику удобно, он пишет код быстрее, чаще выкладывает и всё работает хорошо.

Подписывайтесь на наш блог, здесь мы регулярно публикуем интересное из мира DevOps и рассказываем о случаях из нашей практики, которые помогут, например, подготовить сервисы к чёрной пятнице. Или подключайтесь к моему телеграм-каналу там я собираю мысли на профессиональные (и не только) темы и делюсь любопытными ссылками.
Подробнее..

Скоростной АЦП с нуля. 16 бит за 10 лет

01.12.2020 12:23:05 | Автор: admin
Чего стоит разработать быстродействующий аналого-цифровой преобразователь, почти не имея опыта? Насколько сильно наше отставание в этой области? Есть ли в этой нише шанс найти коммерческое применение своей продукции и отщипнуть хоть кусочек рынка у гигантов мира сего? Выпуская в свет новый 16-битный 80 МГц АЦП, хотим порассуждать на эти темы и рассказать о самой микросхеме и опыте её создания.
image


Введение


2010 год. Тогда многие этим увлекались. Тема быстрых АЦП вдруг стала популярной. Кто-то раньше, кто-то позже, но сразу несколько российских компаний принялись вести разработки в этой области. Не стали исключением и мы. Словно нужно было дождаться, когда рассеется дым горящих вокруг Москвы торфяников, чтобы увидеть, что ниша отечественных скоростных аналого-цифровых преобразователей совершенно пуста. Отставание было гигантским, в несколько поколений. Из наших тогда можно было достать только старые добрые микросхемы серии 1108ПВ 10-14 разрядные АЦП с быстродействием 0,3-1,3 МГц, разработанные еще в советской Риге. Самым крутым считался вильнюсский биполярный 1107ПВ3, тоже родом из 80-х, который имел разрядность 6 бит и мог работать со скоростями до 100 МГц. В это же время западные микросхемы на таких скоростях достигали уже 16 бит! А при меньшей разрядности могли работать на нескольких сотнях мегагерц.

Столь привлекательным казалось попытаться наверстать отставание и заполнить этот вакуум отечественного сегмента АЦП. Было очевидно: кто первый создаст что-то более-менее современное, у того будет шанс монополизировать в дальнейшем весь сегмент. Ввязавшись в гонку тогда, мы смутно догадывались, что путь предстоит неблизкий, но никто не предполагал, что первый верстовой столб на нём будет стоять на отметке в 10 лет


Смог в Зеленограде 2010 г. Фото с сайта Graker.ru

Что за зверь?


Здесь мы на секунду прервёмся, чтобы сказать несколько общих слов об аналого-цифровых преобразователях вообще и о быстродействующих в частности.

Наверное, каждый человек, сам того не подозревая, ежедневно имеет дело с АЦП. Электроника окружает нас повсюду, и, если речь идёт о современном устройстве хоть чуточку сложнее штепсельной вилки, в нём наверняка трудится этот девайс. А уж такая привычная нам техника, как смартфоны, видеокамеры, аудиопроигрыватели, игровые станции, и пр. буквально напичканы ими. Аналого-цифровые преобразователи в их составе выполняют разную работу и имеют присущую этой работе архитектуру: это может быть SAR, Delta-sigma, Pipeline, Folded-interpolated, Flash, Dual-slope и т.д. Такое разнообразие видов обусловлено тем, что не существует оптимальной архитектуры для всех типов приложений. С точки зрения исполнения АЦП могут быть встроены в системы-на-кристалле или реализованы в виде отдельных микросхем.


В системах радиосвязи, радиолокации, телекоммуникации зачастую используются быстродействующие АЦП. Быстродействующими считаются преобразователи с частотой выборки более 10 Мвыб/c. Как правило, они имеют архитектуру Flash, Folded-Interpolated или pipeline, хотя в последнее время стали появляться и быстрые SAR.
У любого АЦП довольно много различных параметров. Для высокоскоростных преобразователей ввиду специфики их применения особенно важны динамические SFDR, SNR, IMD. Подробнее об этих и других параметрах можно прочитать здесь.

Первые шаги


Вернемся обратно в 2010 год. Какими наивными мы были! Сейчас уже невозможно сдержать улыбку, просматривая отчёты и презентации, что мы делали тогда. Только с аспирантской скамьи, мы строили честолюбивые планы, как через пару-тройку лет сделаем преобразователь, не менее быстрый и не менее точный, чем у них Ведь опыт разработки быстродействующих АЦП уже был. В нашем портфолио лежал аж 14-битный 100 МГц преобразователь! (Не миландровский.) Правда работал он так:

Вид кристалла и спектр после первой попытки

На выходе этого преобразователя вместо синусоиды был изрезанный резкими провалами меандр. Представляете, два года работы и такое фиаско! SNR 17 дБ вместо расчётных 68. Тем не менее никто не унывал, потому что такие провалы не редки в микроэлектронике. Такова уж специфика, что за каждой схемой, как бы хорошо она не работала на модели, скрывается вопрос а в железе будет работать? Ответить на этот вопрос, и то не наверняка, можно только с опытом.
Итак, мы перевернули страницу и принялись заново разрабатывать 14-разрядный 100 МГц АЦП. Вскоре параллельно с нами начала работать другая, более опытная команда, перешедшая к нам со своими разработками из другой компании. Мы недоумевали тогда, зачем двум командам решать, пусть и разными способами, но одну и ту же задачу? Зачем эта внутренняя конкуренция? Оказывается этим, сами того не подозревая, мы копировали в миниатюре великих мира сего

А как там у них?


Нам было любопытно, как развивалось направление быстрых АЦП у лидеров сегмента. Для примера мы взяли компанию Analog Devices, которая еще в 2010 году удерживала 48% рынка преобразователей, что больше, чем доля 8 последующих конкурентов вместе взятая. Проанализировав и сопоставив официальные даташиты и научные публикации, мы составили следующий таймлайн:



В таблице приведены примерный год выхода и технология выдающихся для своего времени АЦП, а также подразделение компании, занимавшееся разработкой. (У нас нет инсайда, поэтому эти данные отражают лишь наше виденье.)

Не разбирая всех причин такого успеха компании, отметим лишь две наиболее важные для нас, инженеров. Во-первых, это полувековое эволюционное развитие, позволившее накопить внушительный коллективный опыт. Во-вторых, большие финансовые и ресурсные вложения, свидетельствующие о приоритетности этого направления в компании. Над быстродействующими АЦП одновременно работают два подразделения, в Вилмингтоне и Гринсборо (США), причем в разработке каждой микросхемы может быть задействовано до нескольких десятков инженеров. Основной костяк каждой группы это инженеры, которые много лет занимаются исключительно этой тематикой. Иногда у обеих команд получались близкие по характеристикам преобразователи, хоть и шли они каждый своим путём. Зачастую и в этом случае обе микросхемы выводились на рынок. Супербыстрые преобразователи последнего поколения оказались неподъёмными для какого-то одного подразделения, поэтому обе команды вынуждены были объединить усилия.

Долгая дорога в дебрях


Отметка мы здесь на таймлайне вверху демонстрирует, что в области быстродействующих АЦП наше отставание от передовых разработок на сегодня составляет около 10 лет. И это после десятилетней работы! Наверняка кому-нибудь понадобилось бы меньше времени, но именно столько мы потратили, чтобы пробраться сквозь дебри разработки и получить результат, за который не стыдно.

В первое время недостаток опыта и схемотехнических навыков приводил к неоптимальным или даже ошибочным решениям. Учесть все нюансы и найти лучшее решение было затруднительно не только ввиду сложности системы, но и потому, что симуляторы того времени просто не позволяли промоделировать весь АЦП целиком.

Очень скоро выяснилось, что при таких скоростях на параметры влияет не только качество схемотехники самой микросхемы, но и того, что её окружает корпуса и печатной платы. Нужно было учиться разрабатывать платы для таких приложений: ведь сначала не получалось даже повторить демо-плату ADI так, чтобы параметры их же АЦП соответствовали даташиту. Индуктивности использовавшегося корпуса тоже пагубно отражались на характеристиках, поэтому пришлось разработать новый корпус с так называемым донным контактом (exposed pad), чтобы увеличить количество выводов земли.

Качество измерений при производстве ещё один фактор, ограничивающий достигаемые характеристики. При функциональном контроле используется своя оснастка из печатной платы и контактирующего устройства (коробочка, куда вставляется микросхема и прижимается к плате). Предназначенная для больших промышленных тестеров, эта оснастка громоздкая, а значит привносит дополнительные паразиты и губит параметры. К примеру, даже у последнего АЦП мы вынуждены ограничивать скорость и диапазон напряжения питания из-за того, что просто не можем подтвердить в условиях цеха параметры, достигаемые этой же микросхемой, но распаянной на компактной плате. Нечего и говорить о том, что достичь высоких характеристик невозможно без современного измерительного оборудования в первую очередь дорогих генераторов с низким уровнем шума и джиттера, а также высококачественных полосовых фильтров высокого порядка, чтобы отфильтровывать гармоники этих генераторов.


Таймлайн тестовых образцов в ходе разработки микросхемы

За время, что мы работали над этой микросхемой, было сделано 5 запусков. Будучи fabless компанией, каждый запуск обходился нам в копеечку, которую, к тому же, приходилось доставать из своего кармана (из кармана компании, а не из брюк инженеров), так как этот проект не связан с ОКР-ами и финансируется из собственных средств. Помимо цены есть ещё один минус для мелких fabless компаний. Ожидание кристаллов после запуска иногда затягивается до полугода, чем напрочь выбивает из рабочего ритма.
В 2014 году мы готовы были выводить имеющуюся разработку в свет, руководствуясь принципом на безрыбье и рак рыба. Микросхема была откровенно сырая, плохо калибровалась, поэтому хорошо, что к этому моменту вторая наша команда АЦП-шников сделала более хорошую микросхему её и стали производить под именем 5101HB015. Чтобы попробовать превзойти этот АЦП, нам пришлось перейти на новую архитектуру и даже другую фабрику.

И вот, наконец, новая микросхема увидит свет!

Коммерческий рынок. Почему высокоскоростные АЦП?


Прежде, чем говорить о получившейся микросхеме, поделимся своими соображениями относительно её возможных перспектив. Коммерческий рынок быстродействующих АЦП довольно специфичен и на нём, как бы это дерзко не звучало, можно попытаться сыграть.

A. Выход на мировой рынок
Наверняка, многие знают: чтобы сделать коммерчески выгодный продукт в микроэлектронике, необходим крупный рынок сбыта. Это связано с окупаемостью R&D, измерительного оборудования, запуска тестовых кристаллов и т.д. Влияет на цену микросхемы и тот факт, что фабрика даёт скидку на пластины при больших объёмах производства. В суровых реалиях российского приборостроения сложно сделать схему, которая бы обеспечила высокий спрос. Тем более, когда существуют такие гиганты как ST, TI, ADI, ну и китайские аналоги любых микросхем, которые можно купить за 3 копейки.

Один из способов решения проблемы искать высокомаржинальные направления, которые не требуют серьезных вложений в создание программной инфраструктуры. Скажем, FPGA, процессоры и другие цифровые решения помимо собственно выпуска микросхемы требуют создания среды разработки. На то, чтобы сделать её качественной и удобной для пользователя, может уйти гораздо больше времени и денег, чем на сам чип.

С высокоскоростными преобразователями всё иначе. На рынке существуют 3 основные компании, которые развивают направление высокоскоростных АЦП: TI, ADI и Maxim Integrated (последние две объявили о слиянии). Поэтому данный рынок сильно монополизирован. Цены на преобразователи с частотой дискретизации 80 Мвыб/c находятся в районе 80 долларов, что подразумевает серьезную наценку. На habr есть статья, в которой хорошо освещена проблема монополии в микроэлектронике.

Б. Ограничение поставки в Россию и Китай
С каждым годом вступают все более жесткие ограничения на поставки ЭКБ в Россию и Китай. Высокоскоростные точные преобразователи попадают в категорию ограничений. Даже потребители из европейских стран при заказе таких микросхем должны заполнять документацию, связанную с экспортным контролем продукции двойного назначения. Этот аспект тормозит развитие коммерческих устройств, которые могли бы достичь лучших параметров.
Фото с сайтов Mouser, Arrow

В. Улучшение качества собственных продуктов РЭА
На данный момент у нас разрабатывается система ADAS для помощи водителю. Для обработки данных с радара может использоваться новый АЦП, что позволит существенно поднять точностные параметры системы, а также уменьшить стоимость аппаратуры.


Обобщив все эти пункты, мы решили создать коммерческий вариант микросхемы (называться будет MDRA1A16FI), цена которой будет ниже, чем у зарубежных аналогов. Образцы в металлокерамическом корпусе можем предоставить всем заинтересованным уже сейчас, а в пластиковом корпусе QFN-48 в начале 2021 года. Кому интересно, здесь можно оставить заявку на получение образцов. Пластиковый корпус существенно меньше металлокерамического всего 7x7x0.85 мм против 11x11x2 мм, и, следовательно, легче и дешевле.

Что в итоге получилось




Теперь, наконец, о самой микросхеме что в итоге получилось. Микросхема, получившая название 5101HB045, представляет собой 16-разрядный АЦП с частотой дискретизации 80 Мвыб/c. Её характеристики следующие:

Разрядность, бит $N$ 16
Напряжение питания, В $V_{dd}$ 1.8
Полная шкала, В (п-п) $V_{FS}$ 2
Частота преобразования, МГц $f_{s}$ 80
Соотношение сигнал/шум, dBFS (при $f_{IN}$=10/75МГц) $SNR$ 75.0 / 73.1
Динамический диапазон, свободный от гармоник, dBc
(при $f_{IN}$=10/75МГц)
$SFDR$ 94 / 83
Интермодуляционные искажения 3-го порядка, dBc (при $f_{IN}$~10/75МГц) $IMD3$ -92 / -80
Интермодуляционные искажения 2-го порядка, dBc (при $f_{IN}$~10/75МГц) $IMD2$ -105 / -83
Интегральная нелинейность, LSB $INL$ 2.7
Дифференциальная нелинейность, LSB $DNL$ 0.75
Джиттер, пс $T_{j}$ 0.30
Full Power Bandwidth, МГц $BW$ 688
Рассеиваемая мощность (полная, в КМОП режиме), Вт $P_{sup}$ 0.56


Спектр, интегральная и дифференциальная нелинейность

Структурная схема преобразователя:



Микросхема представляет собой одноканальный АЦП конвейерного типа с разрядностью 16 бит. Процесс преобразования происходит в несколько этапов:
  1. Входной аналоговый дифференциальный сигнал подаётся через выводы VINP/VINN на входное устройство выборки-хранения (УВХ).
  2. Сигнал выборки, сохраненный на емкости УВХ, обрабатывается ядром 16-битного АЦП.
  3. Система цифровой постобработки получает цифровой эквивалент обрабатываемой выборки, осуществляет цифровую коррекцию и кодировку в нужный формат (двоичный код со смещением, дополнительный код, код Грея).
  4. Итоговый результат выдается на параллельную шину по LVDS или CMOS интерфейсу.


Схемотехническая реализация этого алгоритма с требуемой точностью потребовала значительной площади на кристалле. Поэтому, выполненный по стандартной 0,18 мкм КМОП технологии, чип получился не маленький:



Микросхема обладает множеством режимов работы, которые можно конфигурировать с помощью SPI интерфейса. Все подробности в спеке. Кстати, мы наконец-то сделали спецификацию по западному стандарту (правда англоязычную) без всяких запутанных ТУ-шных таблиц.

Стало лучше?


Во многом, да, если сравнивать с тем же 5101НВ015:
  • Здесь нет интерливинга. Это означает, что в выходном спектре данного АЦП не будут присутствовать искажения, характерные для преобразователей с интерливингом, что является существенным плюсом при построении, например, SDR систем.
  • Проще пользоваться. Не нужно тратить время на калибровку при запуске или перенастройке микросхемы. Все калибровочные коэффициенты уже записаны во внутреннюю память при производстве.
  • Расширенный список доступных интерфейсов вывода данных: LVDS/DDR (с двойной скоростью) и параллельный КМОП 1,8 / 2,5 / 3,3 В.
  • Улучшенные динамические показатели SNR [69.5 -> 75] и SFDR [81->94]
  • Хорошая статическая линейность: INL 3 (14 бит) -> 2,5 (16 бит), т.е. более, чем в 4 раза лучше.
  • Можно подключить внешний источник опорного напряжения 1,25 В и поднять SNR до 76,7 дБ.
  • Улучшенный софт для отладочного комплекта.


Что не лучше так это скорость преобразования (80 вместо 125 МГц) и потребление (560 против 115 мВт).

Отладочный комплект и софт


Для того, чтобы попробовать этот АЦП в действии, и при этом не заниматься проектированием печатной платы, мы разработали специальный отладочный комплект. В него входят две платы аналоговая (собственно АЦП и обвязка) и цифровая (сбор выходных данных). Обе платы соединяются разъемами и питаются от одного стандартного 5 В блока питания.



Используя этот отладочный комплект, можно легко и быстро проверять свои решения при разработке аппаратуры. Достаточно подключить к разъёму входной сигнал, всё остальное сделает комплект. На плате присутствует источник тактового сигнала и даже источник внешнего опорного напряжения, чтобы проверить, как работает система при опоре 1,25 В. При желании можно подать свой собственный тактовый сигнал через соответствующий разъем.
Самостоятельно собирать и обрабатывать выходные отсчёты с АЦП тоже не нужно. Мы написали новый софт быстрый и автономный. Предыдущая версия требовала, к примеру, предустанавливать matlab-библиотеки, что достаточно неудобно. Программа умеет конфигурировать АЦП, снимать и выгружать с него данные, строить спектр и вычислять по нему характеристики. Данное ПО поставляется в составе отладочного комплекта. Так же, его можно скачать здесь. Кому интересны комплекты, вот ссылка.

Скриншоты отладочного ПО

Работа над ошибками


Да, мы сделали большой рывок, но часть характеристик всё еще не дотягивает до параметров импортных микросхем. Сравним основные характеристики существующих 16 разрядных АЦП с частотой дискретизации 80 Мвыб/c.

Сравнение параметров
5101НВ045 AD9265 ADS5481 ADS5562 MAX19586 AD9266 LTC2163
Производитель МИЛАНДР ADI TI TI Maxim ADI Linear T. (ADI)
Разрядность, бит 16 16 16 16 16 16 16
Скорость, Мвыб/c 80 80 80 80 80 80 80
Интерливинг нет нет нет нет нет нет нет
Входной буфер нет нет да нет да нет нет
Один источник питания да (1.8В) да (1.8В) нет (5; 3В) да (3.3В) нет (1.8; 3.3В) да (1.8В) да (1.8В)
Дизеринг нет да да нет нет нет нет
Делитель тактовой частоты да да нет нет нет да нет
Входной размах 2 В(п-п) 2 В(п-п) 3 В(п-п) 3.56 В(п-п) 2.56 В(п-п) 2 В(п-п) 2 В(п-п)
SFDR @ 10 MHz тип 94 (>88) тип 88 тип 98 тип 85 (>75) тип 96 тип 94 тип 90
SFDR @ 70 MHz тип 83 (>72) (>92) тип 93 н/д тип 84 (>80) тип 93 тип 89 (>82)
SNR @ 10 MHz тип 75 (>74) тип 80 тип 81 тип 83.8 (>79) тип 80 тип 77.6 тип 77.1
SNR @ 70 MHz тип 73.1 (>71) (> 78.7) тип 80.1 н/д тип 79.2 (>77.5) тип 76.6 тип 76.9 (>75.3)
Потребляемая мощность, Вт 0.563 0.308 2.15 0.865 1.11 0.124 0.188
Совместимость одновременно с 1,8/2,5/3,3 В ПЛИС да нет нет нет нет да нет



Недостатком нашей микросхемы является деградация линейности и ухудшение шума при работе в т.н. undersampling режиме (информацию об этом добавили в предыдущую публикацию), т.е. когда полоса входного сигнала находится во второй и выше зоне Найквиста. Это требуется, например, в приложениях с непосредственной дискретизацией ПЧ. Эта деградация происходит из-за относительно высокого собственного джиттера и нелинейности входного УВХ, которая начинает проявляться примерно с 60 МГц.

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

Если, однако, вы обрабатываете сигналы с частотой до 60-70 МГц, то по динамическим параметрам 5101HB045 смотрится в этой таблице, на наш взгляд, вполне достойно.

Что будет дальше?


Поделимся планами по развитию наших высокоскоростных АЦП. Мы полны решимости сделать еще один цикл (надеемся, он пройдёт быстрее, чем за 10 лет) и дотянуть характеристики нашей микросхемы до уровня аналогов. Если конкретно, то:
  1. поднять SNR до 78 дБ, частоту дискретизации до 125 Мвыб/с.
  2. Уменьшить собственный джиттер, увеличить линейность УВХ, и улучшить таким образом SFDR и SNR на высоких частотах входного сигнала.
  3. Добавить дизеринг для работы с маленькими сигналами (более подробно можно узнать об этом в статье на habr).
Приоритетом для себя мы определили высокую линейность и низкий шум.

Вторая наша группа разработчиков приоритетом для себя видит высокую скорость преобразования. В её планах:
  1. В течение 2021 года вывести на рынок АЦП скоростью до 400 Мвыб/с в двух версиях: со встроенным входным буфером и без. Данный АЦП будет также работать в двухканальном режиме с частотой выборки до 200 Мвыб/с каждый.
  2. Этот же АЦП в двухканальном режиме оснастить последовательным выходным интерфейсом Serial LVDS. У схемы с таким интерфейсом существенно меньше выводов. Значит трассировка платы, снятие и обработка данных сильно упрощается. Это заметное преимущество, особенно для многоканальных АЦП.

Уже был запуск тестовых образцов, они показали хорошие параметры, однако потребовали доработки, которая сейчас активно проводится.

Заключение


Итак, за 10 лет мы существенно продвинулись, но впереди ещё много работы. Тяжело догонять столь быстро и давно развивающиеся компании, особенно когда в R&D схем вкладывают большие ресурсы. Как уже упоминалось, направление скоростных АЦП у нас финансируется за счет собственных средств, и они, увы, сильно ограничены. Но все мы видим большое будущее в этом направлении. Будем действовать, руководствуясь нашим негласным девизом: Таких гигантов как ADI в АЦП-строении нам не переплюнуть, но как следует плюнуть в этом направлении уже хорошо.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru