Доверяй и проверяй: подход к проверке схем и печатных плат

  • Tutorial

image 1


Создание электрических схем и трассировка печатных плат становятся всё более простыми делами. Производители компонентов интегрируют в изделия всё больше функционала, выкладывают готовые модели, условные графические обозначения (УГО) и целые схемы, сайты автоматически генерируют источники питания, фильтры и многое другое. Тем не менее, даже при проектировании простых печатных узлов обнаруживаются ошибки, часто — глупые и очевидные.


Мы сегодня не будем говорить про DRC и ERC, их надо делать всегда и с ними всё более-менее понятно (если нет — напишите в комментариях). Будем говорить про проверку человеком.


Когда в очередной “последний” раз перед отправкой в производство листаешь слои в своей плате, картинка уже настолько знакома, что глаз упускает ошибки. Для проверки нужны “вторые глаза” — пора звать другого инженера.


Когда ты для кого-то и есть эти “вторые глаза” — схема и плата полностью новые, и всё необычное приковывает взгляд. Однако, бессистемная проверка не гарантирует тотального просмотра опасных мест, что может привести к затягиванию сроков отладки и к дополнительным итерациям, не предусмотренным бюджетом.


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


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


Порядок работы



Как только схема или плата, по мнению автора, готова, он ставит в Redmine задачу проверки другому инженеру (Рецензенту). Рецензент, помимо обладания знаниями и опытом, должен изучить ТЗ и все дополнительные материалы проекта. Всё это занимает немало времени, которое должно быть выделено на этапе планирования проекта.


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



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


  • “+” и “-” для констатации прохождения или неприменимости пункта,
  • выделение жирным для явных ошибок,
  • курсив для рекомендаций и вопросов.

После рецензирования, как правило, происходит устное обсуждение комментариев, прояснение непонятных моментов, в результате замечания часто корректируются.
Далее текст перечня из нашей Базы знаний, комментарии для вас выделены курсивом. В перечне есть некоторые моменты, специфичные для Altium Designer.


Проверка схем электрических принципиальных

Для многостраничных схем разбиение по листам, для одностраничных все пункты распространяются на один лист. (Как правило, мы используем иерархические многостраничные схемы, для таких схем для каждого листа надо повторить проверку “Блок”, переименовывая “Блок” в название листа схемы)


Проверка новых компонентов


  1. Проверка по списку из задачи (При постановке задачи на проверку автор создает список вновь созданных компонентов, чтобы Рецензент ничего не упустил. Считается, что остальные компоненты уже проверены нами ранее.)
  2. Проверить по Datasheet:
    • Номера контактов
    • Назначение
    • Соответствие ссылок на описания (ссылка на описание компонента должна быть в свойствах компонента)
    • Посадочное место (должно соответствовать указанному partnumber)
    • Partnumber (достаточно полный, без ошибок)

Первый лист


  1. Проверка настроек проекта:
    • ревизия (Поле revision в свойствах — используется впоследствии для генерации документации)
    • настройки компилятора (д.б. настроено в проекте по умолчанию) (Настройки компиляции в Altium — что можно, что нельзя. Обычно мы создаём проект из внутреннего шаблона, в котором уже всё хорошо настроено)
  2. Компиляция проекта (есть ли ошибки)
  3. Разъемы: (опираемся на ТЗ и дополнительные пожелания в духе “как на плате ХХ”)
    • тип
    • распиновка
    • соответствие номера номеру на схеме Э4
  4. Блоки на первом листе:
    • охват функционала (Все функции описанные в ТЗ, реализованы)
    • количество, если многоканальные
    • синхронизация выводов символов листов
  5. Оформление (Оформление — это важно. Недооформленная схема проверку не проходит)
    • Основная надпись
    • Расположение блоков, подписи, связи

Блок


(Как правило, блок — это простая схема, часто из одной микросхемы с обвязкой)


  1. Правильность прихода линий интерфейсов
    • UART Rx-Tx — перекрещено у "ведомых" (Эта легендарная ошибка заслужила отдельной строки, хотя в пункте проверяются все интерфейсы)
  2. Правильность подачи питаний (Питание нужного номинала, земля приходит на землю, аналоговые питания к аналоговым и т.д.)
  3. Для любых микросхем — проверить по Datasheet: (Здесь чаще всего апеллируем к типовой схеме включения)
    • Назначение
    • FT (толерантность к 5В и другим напряжениям у ног контроллера)
    • Другое (плохой пункт)
  4. На каждом листе — перечень используемых питаний, максимальное потребление по ним (используется для обобщения требований к питаниям в устройстве)
  5. Обозначение классов цепей для выделения специфических мест (например, развязка)

Схема питания


  1. Перечень используемых питаний, потребление (взять со всех блоков и сложить)
    Возле каждого источника: (В простых схемах требование не предъявляется)
    • Выходное напряжение
    • Ток
    • КПД
    • Рассеиваемая мощность
  2. Обозначение классов цепей: HV, Power,… (Всё, что пригодится для трассировки)
  3. Для каждого источника сверить схему включения по Datasheet

Передача на проверку программистам


  1. Подготовить документацию (Генерация схемы и перечня в pdf)
  2. Создать задачу по проверке схемы программистам (У программистов — свой перечень проверок)

Проверка печатных плат

Конструкция


Если есть 3D модель для устройства, проверка производится по ней.(Чаще всего устройство собрано воедино в 3D САПР, там есть инструменты для проверки интерференций, выполнения сечений и пр.)


  1. Форма платы — Соответствие чертежу, модели, ТЗ
  2. Толщина платы
  3. Крепеж
    • Достаточность (с точки зрения соответствия пункту ТЗ “внешние воздействующие факторы”)
    • Попадание в места на плате
    • Зазор для головок винтов, шайб...
  4. Разъемы
    • Положение
    • Ориентация первых ножек
    • Сверить распиновку с сочленяемыми платами
  5. Положение специфических компонентов
  6. Высота компонентов

Проверка связности проекта


(Команды для Altium Designer, суть — проверить, что в плате и схеме отличий нет)


  1. Design-Import Changes from PrjPcb: Не должно быть отличий
  2. Design-Update Sch in PrjPcb: Не должно быть отличий
  3. Project-Component Links: Первые две колонки должны быть пустыми (В Altium Designer иногда компоненты теряют связи из-за перенумерации, вставки чего-то на плату и т.д.)

Проверка посадочных мест


  1. Наличие списка новых (обновлённых) посадочных мест. При повторной проверке список должен быть новый. (Принцип тот же, что и для УГО)
  2. Сверка посадочного места с описанием в Datasheet
    • Порядок расположения выводов
    • Количество
    • Расстояния
    • Форма площадок
    • Шелкография 0.2, первая ножка круг толщина 0.5, диаметр 0.25 (оформление — это важно)
    • Наличие 3D модели, совпадение ножек, шелкографии с ней (3D модели позволяют дополнительно проверить правильность посадочного места, участвуют в проработке и проверке конструкции, помогают получить красивые рендеры плат)

Правила проектирования


  1. Толщина слоя металлизации (В настройках стека всё должно соответствовать реальности)
  2. Соответствие правил проектирования технологическим нормам для выбранных толщин платы и металла (минимальные зазор/проводник, отверстия)
  3. Наличие специфических норм для классов цепей, выделенных на схеме (зазоры до высоких напряжений, минимальные толщины проводников и т.д.)
  4. Отступы от не металлизированных отверстий на внутренних слоях (отличаются от обычного зазора)
  5. Просмотреть все правила (Все правила просматриваются одно за другим, поиск всего необычного)
  6. DRC настройки (проверка, включены ли нужные проверки в DRC)
  7. DRC (Рецензент запускает DRC, при непрохождении — проверка прекращается)

Питание


  1. Общая логика расположения источников и нагрузок (Компоновка должна быть логична, не порождать усложнения платы)
  2. Питание сложных потребителей сквозь друг друга (Один источник на несколько потребителей, которые могут помешать друг другу)
  3. Непрерывность (узкие места) (Тонкие перемычки у полигонов, количество переходных отверстий при переходе со слоя на слой)
  4. Сечение проводников (Подсветка всех питаний по очереди, просмотр подводов к каждому потребителю)
  5. Земля (Земля это очень важно, если ток течёт по шине питания к потребителю — ему надо вернуться обратно)
  6. Наводки между питаниями, соседство источников
  7. Питание микросхем
    • Наличие блокировочных емкостей у пинов
    • Толщина проводников питания
    • Отдельные Via на каждый потребляющий пин
    • Via в ThermalPad (бывает нужно)
  8. Источники питания
    • Открыть Datasheet, свериться с рекомендуемой топологией (когда её нет, обсуждаем оптимальную компоновку)

Сигналы


(Этот блок описывает последовательность, да и то не полно)


  1. Clocks
  2. Дифф-пары
  3. Быстрые сигналы
  4. Общие

Шелкография


  1. Шрифт Default, высота 1mm, толщина 0.2mm
  2. Правильное размещение надписей — не под корпусами, не на отверстиях, не друг на друге (Это удобно смотреть в 3D)
  3. Ориентация любых надписей на одном слое только 0-90 или 0-270 градусов
  4. Обозначение первого пина у микросхем и разъемов
  5. Обозначение 5-10 кратных пинов и рядов у BGA для крупных микросхем (поможет найти нужный пин при отладке)
  6. Обозначение назначения разъемов и тестовых точек (поможет при отладке)
  7. Грамотная последовательность в группах (когда обозначения выносятся группой в сторону из-за плотности расположения компонентов)
  8. Логотип, название платы, ревизия SVN, дата (Часто бывает требование заказчика по размещению своего логотипа, децимального номера и т.д. AD даёт возможность ставить текстовые поля, задаваемые переменными, мы это активно используем)

Другое


  1. В редакторе отверстий посмотреть все отверстия (на наличие аномалий)

image


Списки проверок постепенно эволюционируют, добавляются новые пункты, убираются ненужные.


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


А как вы проверяете свои платы? Поделитесь в комментариях.


* Последняя картинка в тексте иллюстрирует, что даже тщательная проверка не спасёт от невнимательного заказчика.


Почитать по теме


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

Проверяете ли вы работу коллег?

Третий пин
42,00
Контрактная разработка электроники
Поделиться публикацией

Похожие публикации

Комментарии 67

    0
    У меня проекты небольшие, поэтому проверяю сам. 3Д тоже нет.
    Из того, что делаю обязательно перед отдачей платы на производство — распечатываю сторону компонентов в масштабе 1:1 с проводниками на бумаге и тупо пинцетом устанавливаю на нее все компоненты.
    Очень помогает проверить футпринты и если компоненты мешают друг-другу.
      +2

      А если делать футпринты с 3d моделями, не надо будет потом на бумаге расставлять.

        +1
        Расклейка на бумагу более информативна, тк позволяет посмотреть, как куда подлезать инструментом, прокладывать кабель и тд. особенно, если присутствуют всякие штуки типа micro-usb, которые трудно рисовать с высокой точностью.
          0
          На сложные детали можно посмотреть модели у производителя. Сейчас даже «китайцы» их начали поставлять.
            +2
            Чаще всего рисовать самому ничего не надо, какой-нибудь добрый человек уже всё нарисовал и выложил, только качай

            www.3dcontentcentral.com
            grabcad.com/library

            Если же нужной модели нигде нет — стоит потратить на неё время, заодно навык прокачать. А потом тоже поделиться с сообществом.

              0
              Это все классно, если автор не ошибся и если китайцы отгрузили вам именно то, с чего рисовалась модель.
            0
            То ж понятно, но, например, этап с бумагой отлично сработал, когда схемотехник (я) выдал перечень элементов снабженцу (мне) и он (то есть я) закупил все компоненты, а когда начал устанавливать их на бумаге, оказалось, что футпринты не совпадают. Те же SOPXX, или не помню какой тип, бывают разные — чуть, чуть шире, чуть чуть уже и на 3D модели фиг заметишь разницу, а компоненты сейчас обзываются чем-то вроде 74AC245NHBDTAMK — и тут легко проморгать разницу при заказе.

            И это со мной, а если это два разных человека, то ошибка может возникнуть и 3D модель тут не поможет.
              +1
              Смысл в дополнительной возможности проверки, абсолютной гарантии, конечно, нет даже с использованием 3D. Однако видно всё замечательно, любой сдвиг и несимметрия сразу бросаются в глаза.
                0
                Интересно, и кого же потом больше ругал шеф (Вы)? Подозреваю, премии лишили всех :)
                  0
                  Для того, чтобы снабженец не ошибся, партномер должен содержать все буквы, обозначающие корпус.
                  0
                  Это хорошо и правильно, но не всегда оно есть лучшая альтернатива распечатке на бумаге (скорее дополняют друг друга).

                  Не всегда оправданно тратить на 3Д-модели время. Распечатка на бумаге и проверка занимают всего несколько минут.
                  В 3Д-модели можно тоже ошибиться. Например, сделать с небольшим смещением отверстия в радиаторе на плату, IGBT-модуле или в чём-то ещё достаточно крупном. На модели это не будет бросаться в глаза. Даже несколько проверяющих влёгкую пропускают иные баги. Иногда всплывают несоответствия чертежам размеры уже закупленных реальных деталей (сторонние модули, корпуса, например). Бумажка бывает очень быстрым и халявным дебаггером.
                  Мир несовершенен, люди тоже, нам часто приходится это учитывать)))
                    +1
                    Не всегда оправданно тратить на 3Д-модели время. Распечатка на бумаге и проверка занимают всего несколько минут.

                    Все зависит от сложности схемы. Вообще почти всегда оправданно, так как потом модель платы начнут вставлять в модель корпуса и вот тут то 3d очень и очень пригодится, чтобы свести к минимуму ошибки в модели корпуса.
                    0
                    А если делать футпринты с 3d моделями, не надо будет потом на бумаге расставлять.
                    «Помогает проверить футпринты», если Вы ошиблись с футпринтом (взяли не тот, или ошиблись с размерами при создании) — поставив на него реальный компонент ошибка обнаружится наглядно.
                  0
                  Я обычно делаю так:
                  — схема оформляется как гибрид схемы и блок-схемы — удобно проверять и трассировать; схема сделана — сразу проверили; только после этого трассировка.
                  — трассировка по блокам, потом компоновка, вычищение всех мелочей, день перерыва, свежим взглядом проверка и тогда проверяет коллега.
                  — проверка компонентов (соответствие УГО футпринту и шагу между ножек).
                  — вывод герберов и проверка по ним.
                  Вот честно, никогда никаких траблов не было кроме шага между ножками и шириной корпуса. Например, SOIC есть узкий и широкий (а называются они одинаково) или QFN с шагом 0.5 и 0.65.
                    0
                    — схема оформляется как гибрид схемы и блок-схемы — удобно проверять и трассировать; схема сделана — сразу проверили;
                    Вы имеете в виду иерархические схемы с первым листом в виде блоков?
                    — трассировка по блокам, потом компоновка,
                    Почему не сначала компоновка, потом трассировка?
                    — вывод герберов и проверка по ним.
                    Что и как проверяете по герберам?
                    Много ли разных устройств делаете?
                      0
                      Вы имеете в виду иерархические схемы с первым листом в виде блоков?
                      Проще на примере (блок — рамочка вокруг группы компонентов, с подписью функционального назначения блока). Схема читается слева направо, сверху вниз, все входы слева, выходы справа. 1й блок разъем питания, 2й блок преобразование 12В в 6В, 3й блок — 12В в 5В (очень условно). Блок с МК, блок с драйверами, блок с разъемами под моторы, например. Если в друг что-то случится с командой, то любой новый человек легко поймет что происходит =)
                      Почему не сначала компоновка, потом трассировка?
                      Часто есть рекомендуемая топология, сначала опираюсь на нее, потом корректирую в зависимости от габаритов и технологических требований.
                      Что и как проверяете по герберам?
                      Много ли разных устройств делаете?
                      Просматриваю на наличие лишних перегибов, как пролились полигоны, отверстия, маску (некоторые отверстия закрываю маской, некоторые нет), в принципе. Ну и плюс, правильность формирования герберов. Давно конечно, но было, что не совпали гербера и сверловка. Или что выводили гербера без меня, а овальные почему-то не вывелись (у альтиума они отдельно от круглых).
                      Много, самые разные (бытовая электроника, носимая, лед, мед, неразрушающий контроль, иот), мелкие и крупные партии, местное производство, Китай и Европа =)
                    +3
                    Я несколько лет назад работал программистом в институте, где разрабатывали микроэлектронику. Воркфлоу был примерно такой — программисты писали модель проектируемых модулей на Haskell, потом железячники реализовывали ее на Verilog, записывали в FPGA вместе с процессором LEON (свободный Spark-совместимый) и снова отдавали нам, что бы мы писали тесты (начали на C, но быстро перешли на ассемблер). Иногда к FPGA в соседнем отделе разрабатывали плату с дополнительным железом, например I2S. И с этими платами постоянно возникали проблемы, типа перепутанной полярности RESET. Программистов это очень расстраивало, и мы думали как бы статическую типизацию из Haskell прикрутить к описанию платы. Такого рода ошибки легко бы обнаружились. Но до реализации идеи руки так и не дошли.
                      +3

                      Что-то не совсем понял суть статьи… Найдите себе рецензента — и это все?
                      Разрабатываю железо по 50-60 часов в неделю и даже с замыливается глазом ошибок в плате не видел уже года 2-3. Исключение, когда ошибка в даташита была, но и такое сейчас бывает только в совсем новых компонентах.
                      Чтобы не было ошибок — достаточно просто правильно реализовать проект и использовать нормальный САПР. Тот же Mentor Expedition или Altium никогда не даст тебе соединить, например, землю и vcc, ну и прочее. DRC полностью позволяет избежать ошибок при условии, что схематик правильный. Поэтому если по прежнему есть ошибки в простых проектах (аля stm и рассыпуха), то стоит повышать свою компетенцию, инструменты и менять подход к проектированию.

                        +3
                        и даже с замыливается глазом ошибок в плате не видел уже года 2-3

                        Все зависит от сложности проекта. Ну и конечно от опыта ;)

                        Но в целом да, правильное использование сквозных систем проектирования устраняет ошибки даже если схема сложная (ну или сводит ошибки к минимуму), а разработчик один.
                          0
                          Могу только позавидовать вашей удаче! Если у вас появятся коллеги — как будете контролировать качество? САПР проверяет очень поверхностно, к сожалению.
                            0
                            Удачи только мелкая часть, скорее системный подход)) Вообще, работая в отделе где было 20+ схемотехников только, действительно давали друг другу проекты на проверку. Тоже метод, но к сожалению даже после изучения 3-4 людьми происходили ошибки, все таки человеческий фактор никуда не убрать пока.

                            Я для себя нашел спасение в сниппетах и использовании набора стандартных схемотехнических решений, которые у меня уже обкатаны на макете или других проектах. Опять же — человеческий фактор полностью не ушел, а значит и ошибки потенциально могут быть.
                              0
                              Статья как раз о системном подходе. К сожалению (или к счастью), опытных и не ошибающихся инженеров нельзя заказать сразу пяток, с доставкой в офис. Они получаются из неопытных, путём совершения ошибок. Иногда — очень дорогих ошибок.

                              Проверяя чужую работу и давая пояснения Рецензент учится сам. А перечень — просто способ упорядочить процесс, облегчить передачу знаний. И немного сэкономить на переделках.
                            0
                            Вы или очень везучий, или очень талантливый человек! Я как ни стараюсь, даже понимая что личные деньги уходят на производство платы, окончательная версия только к третей плате созревает. Я даже с этим смирился…
                            Возможно 50-60 часов в неделю дают результат, потому как у меня получается 3-5 плат в год разводить, на большее число проектов времени не хватает.
                              0
                              Думаю без доли везения однозначно никак, хотя не думаю, что это и особый талант, рука просто набивается. А вообще самое главное — давать мозгам отдыхать. Я обычно доделав проект, делаю перекур 1-2 дня просто переключившись на другой проект, после этого уже смотрю свежим взглядом и все конструктивные недочеты уходят. Все потенциально проблемные узлы желательно в том же LTspice просимулировать, а от косяков в плате САПР спасает.

                              Самый уязвимый этап — схема. Я, например, после каждого проекта делаю снипеты на удачный узлы схемы или трассировки и стараюсь использовать именно их. То есть у меня есть 3-4 решения для dc/dc преобразователя и в 99% использую опять их же, т.к. решение уже отлажено и не содержит ошибок, а еще это оооочень экономит время.

                              Кстати заказ плат за свои деньги меня как раз и приучил к сниппетам. Пару раз накосячил с многослойками по 600$ и поумнел))) Это как 2 типа людей: делают бекапы и пока не делают бекапы. Только тут применительно к электронике.
                                0
                                У меня вся беда в том, что редко случаются проекты с узлами, которые можно дернуть из предыдущих проектов. А еще моя головная боль — Оркад 9.2, принятый за стандарт на нашей конторе. Там DRC просто вообще никакой.
                                Для остальных проектов использую Kicad — вот там ошибок на порядок меньше. Главным образом схемотехнические косяки. А по платам — только в плане размещения компонентов бывает. С виду вроде все хорошо, а по факту SMD конденсатор чтобы поменять нужно разъем снимать.
                                И да, почти всегда для аналоговых схем провожу моделирование а LTSpice. Он почему то больше всех приглянулся. Даже если работа схемы кажется очевидной, все равно моделирую. Вылазят интересные моменты по поводу устойчивости работы.
                                  0
                                  А не подскажите, есть ли в KiCad что-то наподобие сниплетов? Задумывался над тем чтобы использовать части разведенных плат из предыдущих проэктов, но не очень понятно реализована ли такая возможность в кикаде вообще?
                                    0
                                    Я не встречал. Скорее всего нет. У меня даже не было необходимости таким инструментом воспользоваться.
                            0
                            Интересно было-бы почитать о том как отлаживать готовую плату.
                              0
                              Берешь плату, берешь план тестирования, берешь подготовленные тесты (ПО и т.д.), берешь нужное оборудование. Идешь последовательно по плану. Если что-то не работает как ожидалось — первым делом осматриваешь визуально плату на случай некачественной сборки. Далее смотришь схему на наличие явных проблем. Потом вооружаешься тестером/осциллографом/спектроанализатором и пытаешься найти корень проблемы. Все очень индивидуально в зависимости от устройства, интерфейса и т.п.
                                +2
                                В больших конторах где разработчики и программисты разделены примерно так:
                                включаешь плату, если дыма нет, несёшь программисту, дальше это его проблема. Если дым есть, твоя проблема ;(
                                  +3
                                  Это в средних конторах, а в больших куда забавнее)) Есть hardware, который делится на схемотехника, конструктора плат, механика. Приходит плата. Пошел дым, дергают схемотехника. Он ковыряется и говорит, что со схемой все ок — косяк в трассировке. Дергают конструктора, чтобы он исправлял или боролся дальше. Дальше собирают железку в корпус, если что-то не влезло — карают механика, который 3D модели рисовал и компоновал устройство. Когда отдел hardware весь измучен и наказан, то железо переезжает к firmware…
                                  Последние стартуют, смотрят, что что-то вроде работает и мигает. Натягивают RTOS или linux, библиотеки на голое железо и отдают в software. Последние начинают отгребать за всех: оказывается, что и ddr3 не стартует, и светодиоды не на тех ногах и вообще мало флеша поставили на плату.
                                  Далее в рандомном порядке в полном безумии повторяется операция поиска виноватого и его нагиба. Все это ведет к хаосу. Поэтому сейчас даже большие компании отказываются от такого деления на отделы и уходят на рабочие группы. Например, в моей последней компании были группы: 1 схемотехник + 1 конструктор ПП и механик в одном лице + 3 фирмварщика + 3-4 софтописателя. В принципе и схему, и плату проверяли все вместе. Да еще и премия выдавалась не работнику, а на рабочую группу — даже не самым лучшим людям было выгодно помогать товарищам))
                                0
                                В общем, да, nerudo описал верно. У нас отладка новых плат начинается без софта — проверяются питания, соответствие диапазонов требованиям ТЗ, а затем, если у программиста что-то не поднимается — начинается совместное творчество. Самое интересное — локализация ошибок и выдвижение гипотез, тут вряд ли можно дать готовый план. У нас многие проекты совместные, когда заказчик проектирует свою часть(СВЧ), а мы — свою(управление и питание) — отладка крайне увлекательна, я вам доложу.
                                +1
                                Был свидетелем классической ошибки, доведенной до эпичности. Две больших сложных платы, стыкуются специальными многорядными разъемами через которые тащатся скоростные параллельные интерфейсы. Когда все изготовили, собрали и включили выяснилось что входы включены на входы, а выходы на выходы. Поскольку сигналы разъемов назывались *_in и *_out, но один разработчик имел system-centric, а другой board-centric взгляд на устройство. Ну а тщательно готовить и читать документацию никто не хотел.
                                  +1
                                  Ну и как-бы провода на картинках намекают не столько на проверку схем и плат, сколько на проверку схемотехнических решений, прежде чем рисовать свою схему с ними. То есть перед тем, как применять микросхему или модуль в своей схеме, посмотри на reference design, и если твой вариант применения хоть чуть-чуть от него отличается — не ленись, закажи пару семплов, или даже отладочную плату, проверь, поэкспериментируй, спаяй прототип на коленке, сделай демо и только потом переноси в свою схему.
                                  Во первых стоимость ошибки по мере рисования и разводки платы возрастает многократно и все эти эволюционные платы и затраты на прототипирование будут стоить копейки на фоне последующего исправления косяков, а во-вторых всегда будет иметься в наличии референтная рабочая схема, с которой можно будет потом сравнить и проконсультироваться, если что-то не работает на своей плате. Без нее поиск ошибок иногда приводит к танцам с бубном и беганью по форумам.
                                    0
                                    Действительно, так мы и поступаем! Не помогает! Отладка с одним дисплеем, вам надо другой, другое питание, куча всего ещё сверху, сборка таких макетов будет занимать очень много времени. Мы макетируем только рискованные узлы, дальше — экспериментальная плата.
                                    0
                                    А не проще подключи питания и пусть плата сделает диагностику сама на каждый блок верифицирует, по возможности можно отрубить отдельно чтоб не кушал питание при выходе из строя. Ведь схема то всеравно отлажена и плата грамотно проработана и компонент лежит на своем посадочном месте
                                      0
                                      Плата может в принципе не включиться, до передачи программисту её надо протестировать.
                                        0
                                        Привет Пьеру Жаке Дро или кремнию в схемотехнике
                                      0
                                      Как говорит народная конструкторская мудрость «Сколько в первую плату не смотри, а косяки всегда найдутся»
                                      Не страшно, если какую то цепь не провел, хуже когда с футпринтом ошибся, например графический компонент под DIP8, а присоединил SO-16 (микросхема бывает в двух корпусах).
                                      Графический компонент нарисовал в одно время, а плату разводил через неделю, и корпус выбирал по распространенности в продаже.
                                      А статья отличная! Все четко систематизировано. Автору большое спасибо.
                                        0
                                        Спасибо!
                                        У нас ключевым полем в базе компонентов является партномер, поэтому разные корпуса — разные компоненты.
                                        +1

                                        И это все равно не спасет от ситуации, когда ставишь, например, силовой драйвер, потом начинаешь отлаживать, а он греется как сковородка на частотах ШИМ даже в 10 раз ниже разрешенных по ДШ. Начинаешь гуглить — ан нет, норм, у всех греется. Грустно вздыхаешь и идёшь перепроектировать с нормальным драйвером. Реальность — лучший проверяющий. Все равно версии 1.1.2 будут и никуда от них не деться

                                          0
                                          Сейчас для «тренировки» делаю так:
                                          1) Всю схему моделирую в FPGA. Постоянно проверяю на наличие глитчей и прочего из-за асинхронных частей схемы;
                                          2) Как модель ALL-IN-FPGA отлажена, выношу основные компоненты (память, интерфейсы) на макетную плату, подключаемую к FPGA и продолжаю отлаживать с реальными таймингами этих частей;
                                          3) И только после этого рисую схему по проекту из FPGA, по которой потом рисуется и плата.
                                          Но у меня и проекты не сильно-то и большие — укладываются в 2к ALM, на мелкой логике и старых процессорах получается около 100 корпусов. Сейчас, например, моделирую ретро-компьютер Орион-128, сейчас уже на этапе 2, часть схемы уже на этапе 3 (видео-подсистема, с выходом на VGA, с поддержкой 4-х видеорежимов (по разрешению, и ещё 8 по цветности).
                                            +1
                                            Пару лет назад начальник отдела обещал премию тому разработчику, у кого уже после запуска платы в производство не всплывет какого-либо «нюанса». До сих пор никто не получил…
                                              +1
                                              Слишком расплывчатое понятие «какой-либо ньюанс» так можно докопаться и до маркировки на 1мм правее. тоже ведь ньюанс. Критерием должно быть прохождения определённого набора тестов, в которые можно включить к примеру сборку самого устройства.
                                                0
                                                В данном случае имелась ввиду именно работа разработчика схемы и вновь разрабатываемые схемы, платы другой отдел разводит. Ну и последующие итерации схемы с учетом выявленных косяков в расчет уже не принимаются.
                                              +1
                                              Когда делала свою вторую в жизни плату, сделала ее зеркальной. Вот обидно то было, столько времени потрачено. А ведь предварительно распечатала на бумажке, разложила все детальки и радуюсь, что удачно получилось. Раскладывать то надо было на зеркальной копии, а я под утюг и в продакшон.
                                                +1
                                                Не расстраивайтесь, я знаю не мало разработчиков, которые свои первые платы зеркалили, или, что почти одно и то же, перепутывали слой компонентов со слоем монтажа. Тоже было все так красиво, а платы в итоге только на стенку в рамочку.
                                                  0
                                                  Да что там первые, к нам на отладку приезжал заказчик с платой, оказалось, внутренние слои не заказали)
                                                +3
                                                В общих чертах: ERC, DRC, DFM + много опыта по личной сборке и наладке устройств.

                                                Если что-то сложное, то блок-схема в yEd с уточнением интерфейсов и связей.

                                                В схемах — проверенные макро блоки и предварительные консультации с программистами, смогут ли они сделать так, как я планирую.
                                                Какие-то новые не совсем понятные схемы — макеты и отладки с доработками под себя.
                                                Если что-то есть для того же LTSpice'а, то в нём, но и на старуху, как оказалось…
                                                Если компоненты от TI — то обязательно изучение всех вопросов по компоненту в их e2e форуме. А то была чудесная микруха преобразователь pcie-4xUSB3 у которой в даташите и апноуте одно, в эррате чуток другое и на прямой вопрос техасу, дык, делать как в апноуте или эррате, был ответ вида «ну если у вас не работает, то сделайте как в эррате».

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

                                                После этого вывод в герберы и уже изучение герберов на предмет правильного вывода всего и вся. Не помню, где именно когда-то прочитал: «тополог не должен перекладывать на плечи инженера завода свои проблемы». Т.е. если в САПР правила настроены на 4 класс, а по герберам вдруг в некоторых местах получается 5-й, то нельзя лениться, надо корректировать.

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

                                                С механикой по-хорошему надо сначала компоновать, отдавать механику 3d, потом править и так до бесконечности. И только потом трассировка. Но чаще получается в виде «вот тебе объем, тут и тут у нас винты, размещай всё вот здесь». Особенно порадовало на новой работе делать односторонние платы из-за особенностей изделий.

                                                Чтобы не было путаницы в компонентах — все посадочные именуются по IPC. Все УГО называются с учетом конкретного корпуса (это чтобы выводы не попутать). Фактически, один компонент, одно УГО, одно посадочное.

                                                Как правило это помогает со второй итерации получить работоспособное устройство.

                                                А вообще, как показала практика, гарантия хорошей работы почти без ошибок — это стабильная ситуация с зарплатой, отсутствие нервяков и постоянного дерганья. И тогда «состояние потока» проходит с очень большой пользой.
                                                  +1
                                                  Выделять TI как особый случай я бы не стал, это общая практика.
                                                  отсутствие нервяков и постоянного дерганья. И тогда «состояние потока» проходит с очень большой пользой

                                                  Верно подмечено! Жаль, что жизнь вносит свои корективы и подёргивать — таки приходится иногда.
                                                  Напишите, пожалуйста, подробнее о DFM
                                                  0
                                                  Т.е. если в САПР правила настроены на 4 класс, а по герберам вдруг в некоторых местах получается 5-й, то нельзя лениться, надо корректировать.
                                                  Не подскажете подходящий инструмент для такого анализа?
                                                    0
                                                    Дык, CAM350.
                                                      0
                                                      Спасибо, выглядит неплохо. А под линкс ничего нет?
                                                        0
                                                        Не знаю. У меня всё под виндой :)
                                                    +1
                                                    Фактически, один компонент, одно УГО, одно посадочное.

                                                    Вот кстати, я как на фирме работала, так отвечала за всю библиотеку. Когда каждый инженер ведет свою, друг другу проект футболят, то такая каша. Особенно улыбало, когда у компонента вручную правят параметры.
                                                    У меня каждый номинал — отдельный компонент, даже в резисторах/кондерах. Исключаем по максимуму человеческий фактор.
                                                    0
                                                    Создание электрических схем и трассировка печатных плат становятся всё более простыми делами.


                                                    Распространение такого мнения не может не пугать. «Копипаст решения от производителя» и «разработка уникального устройства» — немного разные по сути задачи.

                                                    Так что фразу следует читать так: «сегодня все больше задач получают готовые решения, которые достаточно всего лишь аккуратно скопировать».

                                                    А как вы проверяете свои платы?


                                                    Поскольку у меня не стоит задача разрабатывать триста шестьдесят пять устройств в год (решения в основном штучно-специального плана), я даю каждому проекту «вылежаться» дня три перед тем, как отправлять его в производство, даже если к концу всех проверок непосредственно после окончания трассировки стопроцентно уверен, что ошибок нет. Далее снова проверяю плату. Если мне все еще кажется, что ошибок нет, то отправляю ее в производство.

                                                    А так все стандартно — DRC, ERC, проверка соответствия платы схеме, проверка электрического соединения цепей, ручная проверка топологии.
                                                      0
                                                      Так что фразу следует читать так: «сегодня все больше задач получают готовые решения, которые достаточно всего лишь аккуратно скопировать».

                                                      Всё верно, это и имелось в виду. Для большинства задач в промышленной/потребительской электронике этого достаточно.
                                                      Вы в одиночку делаете штучно-специальное?
                                                        0
                                                        В некотором смысле да. Мной «усиливают» в плане разработки электроники команду, состоящую из специалистов в предметной области (физиология/физика). Они понимают, что нужно сделать, а я — как. :) Разумеется, разработкой занимаюсь не я один; кроме меня есть конструкторы механики, это отдельные люди; при необходимости к нам присоединяются программисты Android и т.д. Но схемы/платы/прошивки электроники на мне.

                                                        Да, забыл сказать. Я тоже практикую распечатывание на бумаге макета платы в размере 1:1 и примерку критичных (или тех, которые использую впервые) компонентов. Выглядит не супер-профессионально, зато такой способ, при своей простоте, может сэкономить деньги на перезаказе плат. :)
                                                      0
                                                      Поскольку часто при проверке таких вещей мозг упускает 1 из 20-30 пунктов я для себя составил список проверок, такой как бы человеческий DRC, такой же как в САПР, но составленный в том числе из правил которые нельзя или сложно заскриптовать в DRC САПР.

                                                      1) Проверка удовлетворения системными решениями
                                                      — Требований ТЗ
                                                      — Параметров выбранных электронных компонентов, влияющих на требуемые в ТЗ характеристики
                                                      — Удовлетворяемости системы и ее составляющих условиям эксплуатации
                                                      — Соображений целесообразности
                                                      — Соображений экономичности и выгоды
                                                      — Удовлетворения себестоимости
                                                      — Общих правил проектирования электронных систем
                                                      2) Проверка схемы
                                                      — Проверка наличия всех названий и каких-либо комментариев на схеме
                                                      — Проверка соответствия подписей выводов их номерам
                                                      — Проверка правильности установленных типов выводов (Input, Output PushPull, Opendrain, HiZ, Analog, etc...)
                                                      — Проверка проводниковых соединений всех УГО между собой согласно их даташитам и согласно ТЗ
                                                      — Проверка на непреднамеренные соединения, недосоединения и КЗ
                                                      — Проверка удовлетворения рабочих параметров элементов после соединения их между собой
                                                      — Проверка удовлетворения ограничений рассеяния мощности из даташитов компонентов
                                                      — Проверка согласования импедансов если нужно
                                                      3) Проверка платы
                                                      — Общая проверка DRC по выбранным нормам завода-изготовителя
                                                      — Проверка коллизии компонентов
                                                      — Проверка на баланс термосопротивлений паяемых площадок компонентов
                                                      — Проверка на способность окружающей обстановки (полигонов, радиаторов, корпуса и т.д.) теплорассеивающих элементов эффективно рассеивать их тепло согласно данным даташита
                                                      — Проверка контура платы на наличие участков неоптимальной формы, либо легколомких участков
                                                      — Проверка правильности заливки полигонами платы
                                                      — Проверка правильности разводки земель
                                                      — Проверка согласования импедансов если нужно
                                                      — Проверка выравнивания высокоскоростных цепей если нужно
                                                      — Проверка целостности сигналов (если необходимо — SI симуляция) и качества разводки сигнальных цепей
                                                      — Проверка целостности питания и качества разводки шин питания
                                                      — Проверка возможности монтажа и удовлетворения правилам монтажа выбранного изготовителя
                                                      — Проверка эргономичности расположения управляющих и электроустановочных элементов
                                                      — Проверка возможности порчи легкоплавких частей компонентов при запайке рядом с ними компонентов с тугоплавким припоем с высокой температурой

                                                      Кажется, ничего не упустил. Берите, нахаляву.
                                                        0
                                                        Спасибо! А что вы проектируете, если не секрет?
                                                          0
                                                          Все что угодно, в данный момент работаю там где нужно заниматься поддержкой и модификацией встраиваемого ПО комплектов контроллера входа-выхода и бортового компьютера для управления гидроприводными системами устанавливаемыми на грузовиках и тракторах наподобие бульдозерного трала или мусоровозной камеры, всего что можно навесить на грузовик.
                                                        +1
                                                        Тебе просто дают схему и печатку нарисованную в кореле или спринт лайотуе и тебе хочется всех убить.
                                                          0
                                                          В такие моменты не надо себя сдерживать
                                                            0
                                                            Я боюсь Брейвик тут ребенком покажется. А в наших тюрьмах интернеты не дают, даже ограниченно. А Я видел целые конструкторские отделы, работающие ТАК.
                                                              0
                                                              Ну надо менять работу тогда. Если же люди не задумывались о сохранении возможности сменить работу, или как то повлиять на текущий ход работы, то сочувствую, потому что довольно часто в начальстве (да и среди коллег) сидят люди которым пофиг на работников. То есть это эгоисты. Это означает необходимость каждодневного слежения и планирования жизни, куда входит и создание возможности смены работы/пассивного дохода и т.д. Просто потому что среди нас подлые эгоисты, для которых покушение на другого либо наплевательство на другого если он не имеет защиты — каждодневная привычка. Поэтому когда «хочется всех убить» — то значит, на вас кто-то наварился.
                                                                0
                                                                Ну мне работу сменить сложно. Я сам на себя работаю. А поддерживать приходится проекты которые беру на доработку. Я конечно за такое говно заряжаю конский ценник. Но от этого всех убить мне меньше не хочется.

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

                                                        Самое читаемое