Создание электрических схем и трассировка печатных плат становятся всё более простыми делами. Производители компонентов интегрируют в изделия всё больше функционала, выкладывают готовые модели, условные графические обозначения (УГО) и целые схемы, сайты автоматически генерируют источники питания, фильтры и многое другое. Тем не менее, даже при проектировании простых печатных узлов обнаруживаются ошибки, часто — глупые и очевидные.
Мы сегодня не будем говорить про DRC и ERC, их надо делать всегда и с ними всё более-менее понятно (если нет — напишите в комментариях). Будем говорить про проверку человеком.
Когда в очередной “последний” раз перед отправкой в производство листаешь слои в своей плате, картинка уже настолько знакома, что глаз упускает ошибки. Для проверки нужны “вторые глаза” — пора звать другого инженера.
Когда ты для кого-то и есть эти “вторые глаза” — схема и плата полностью новые, и всё необычное приковывает взгляд. Однако, бессистемная проверка не гарантирует тотального просмотра опасных мест, что может привести к затягиванию сроков отладки и к дополнительным итерациям, не предусмотренным бюджетом.
С осознанием этих ограничений мы ввели перечень проверок, который позволяет отсечь наиболее распространенные ошибки. Про него я сегодня и расскажу.
Узкоспециализированных пунктов в перечне почти нет — мы делаем много разнообразных проектов и список универсален. Для всех сложных мест в цифровой схемотехнике есть свои чек-листы, которые дают производители микросхем.
Порядок работы
Как только схема или плата, по мнению автора, готова, он ставит в Redmine задачу проверки другому инженеру (Рецензенту). Рецензент, помимо обладания знаниями и опытом, должен изучить ТЗ и все дополнительные материалы проекта. Всё это занимает немало времени, которое должно быть выделено на этапе планирования проекта.
Закончив ознакомление с документацией, надо настроиться на правильный лад. Проверка — это помощь в достижении наилучшего возможного результата. Прежде чем обрушиться с критикой, важно вспомнить, что инженер старался сделать свою работу превосходно, “от души”, и задача проверяющего — не нарушить это настроение.
Рецензент копирует текст перечня проверки из Базы знаний в комментарий к задаче, а затем двигается по списку, оставляя свои пометки. Используются обозначения:
- “+” и “-” для констатации прохождения или неприменимости пункта,
- выделение жирным для явных ошибок,
- курсив для рекомендаций и вопросов.
После рецензирования, как правило, происходит устное обсуждение комментариев, прояснение непонятных моментов, в результате замечания часто корректируются.
Далее текст перечня из нашей Базы знаний, комментарии для вас выделены курсивом. В перечне есть некоторые моменты, специфичные для Altium Designer.
Для многостраничных схем разбиение по листам, для одностраничных все пункты распространяются на один лист. (Как правило, мы используем иерархические многостраничные схемы, для таких схем для каждого листа надо повторить проверку “Блок”, переименовывая “Блок” в название листа схемы)
Проверка новых компонентов
- Проверка по списку из задачи (При постановке задачи на проверку автор создает список вновь созданных компонентов, чтобы Рецензент ничего не упустил. Считается, что остальные компоненты уже проверены нами ранее.)
- Проверить по Datasheet:
- Номера контактов
- Назначение
- Соответствие ссылок на описания (ссылка на описание компонента должна быть в свойствах компонента)
- Посадочное место (должно соответствовать указанному partnumber)
- Partnumber (достаточно полный, без ошибок)
Первый лист
- Проверка настроек проекта:
- ревизия (Поле revision в свойствах — используется впоследствии для генерации документации)
- настройки компилятора (д.б. настроено в проекте по умолчанию) (Настройки компиляции в Altium — что можно, что нельзя. Обычно мы создаём проект из внутреннего шаблона, в котором уже всё хорошо настроено)
- Компиляция проекта (есть ли ошибки)
- Разъемы: (опираемся на ТЗ и дополнительные пожелания в духе “как на плате ХХ”)
- тип
- распиновка
- соответствие номера номеру на схеме Э4
- Блоки на первом листе:
- охват функционала (Все функции описанные в ТЗ, реализованы)
- количество, если многоканальные
- синхронизация выводов символов листов
- Оформление (Оформление — это важно. Недооформленная схема проверку не проходит)
- Основная надпись
- Расположение блоков, подписи, связи
Блок
(Как правило, блок — это простая схема, часто из одной микросхемы с обвязкой)
- Правильность прихода линий интерфейсов
- UART Rx-Tx — перекрещено у "ведомых" (Эта легендарная ошибка заслужила отдельной строки, хотя в пункте проверяются все интерфейсы)
- Правильность подачи питаний (Питание нужного номинала, земля приходит на землю, аналоговые питания к аналоговым и т.д.)
- Для любых микросхем — проверить по Datasheet: (Здесь чаще всего апеллируем к типовой схеме включения)
- Назначение
- FT (толерантность к 5В и другим напряжениям у ног контроллера)
- Другое (плохой пункт)
- На каждом листе — перечень используемых питаний, максимальное потребление по ним (используется для обобщения требований к питаниям в устройстве)
- Обозначение классов цепей для выделения специфических мест (например, развязка)
Схема питания
- Перечень используемых питаний, потребление (взять со всех блоков и сложить)
Возле каждого источника: (В простых схемах требование не предъявляется)- Выходное напряжение
- Ток
- КПД
- Рассеиваемая мощность
- Обозначение классов цепей: HV, Power,… (Всё, что пригодится для трассировки)
- Для каждого источника сверить схему включения по Datasheet
Передача на проверку программистам
- Подготовить документацию (Генерация схемы и перечня в pdf)
- Создать задачу по проверке схемы программистам (У программистов — свой перечень проверок)
Конструкция
Если есть 3D модель для устройства, проверка производится по ней.(Чаще всего устройство собрано воедино в 3D САПР, там есть инструменты для проверки интерференций, выполнения сечений и пр.)
- Форма платы — Соответствие чертежу, модели, ТЗ
- Толщина платы
- Крепеж
- Достаточность (с точки зрения соответствия пункту ТЗ “внешние воздействующие факторы”)
- Попадание в места на плате
- Зазор для головок винтов, шайб...
- Разъемы
- Положение
- Ориентация первых ножек
- Сверить распиновку с сочленяемыми платами
- Положение специфических компонентов
- Высота компонентов
Проверка связности проекта
(Команды для Altium Designer, суть — проверить, что в плате и схеме отличий нет)
- Design-Import Changes from PrjPcb: Не должно быть отличий
- Design-Update Sch in PrjPcb: Не должно быть отличий
- Project-Component Links: Первые две колонки должны быть пустыми (В Altium Designer иногда компоненты теряют связи из-за перенумерации, вставки чего-то на плату и т.д.)
Проверка посадочных мест
- Наличие списка новых (обновлённых) посадочных мест. При повторной проверке список должен быть новый. (Принцип тот же, что и для УГО)
- Сверка посадочного места с описанием в Datasheet
- Порядок расположения выводов
- Количество
- Расстояния
- Форма площадок
- Шелкография 0.2, первая ножка круг толщина 0.5, диаметр 0.25 (оформление — это важно)
- Наличие 3D модели, совпадение ножек, шелкографии с ней (3D модели позволяют дополнительно проверить правильность посадочного места, участвуют в проработке и проверке конструкции, помогают получить красивые рендеры плат)
Правила проектирования
- Толщина слоя металлизации (В настройках стека всё должно соответствовать реальности)
- Соответствие правил проектирования технологическим нормам для выбранных толщин платы и металла (минимальные зазор/проводник, отверстия)
- Наличие специфических норм для классов цепей, выделенных на схеме (зазоры до высоких напряжений, минимальные толщины проводников и т.д.)
- Отступы от не металлизированных отверстий на внутренних слоях (отличаются от обычного зазора)
- Просмотреть все правила (Все правила просматриваются одно за другим, поиск всего необычного)
- DRC настройки (проверка, включены ли нужные проверки в DRC)
- DRC (Рецензент запускает DRC, при непрохождении — проверка прекращается)
Питание
- Общая логика расположения источников и нагрузок (Компоновка должна быть логична, не порождать усложнения платы)
- Питание сложных потребителей сквозь друг друга (Один источник на несколько потребителей, которые могут помешать друг другу)
- Непрерывность (узкие места) (Тонкие перемычки у полигонов, количество переходных отверстий при переходе со слоя на слой)
- Сечение проводников (Подсветка всех питаний по очереди, просмотр подводов к каждому потребителю)
- Земля (Земля это очень важно, если ток течёт по шине питания к потребителю — ему надо вернуться обратно)
- Наводки между питаниями, соседство источников
- Питание микросхем
- Наличие блокировочных емкостей у пинов
- Толщина проводников питания
- Отдельные Via на каждый потребляющий пин
- Via в ThermalPad (бывает нужно)
- Источники питания
- Открыть Datasheet, свериться с рекомендуемой топологией (когда её нет, обсуждаем оптимальную компоновку)
Сигналы
(Этот блок описывает последовательность, да и то не полно)
- Clocks
- Дифф-пары
- Быстрые сигналы
- Общие
Шелкография
- Шрифт Default, высота 1mm, толщина 0.2mm
- Правильное размещение надписей — не под корпусами, не на отверстиях, не друг на друге (Это удобно смотреть в 3D)
- Ориентация любых надписей на одном слое только 0-90 или 0-270 градусов
- Обозначение первого пина у микросхем и разъемов
- Обозначение 5-10 кратных пинов и рядов у BGA для крупных микросхем (поможет найти нужный пин при отладке)
- Обозначение назначения разъемов и тестовых точек (поможет при отладке)
- Грамотная последовательность в группах (когда обозначения выносятся группой в сторону из-за плотности расположения компонентов)
- Логотип, название платы, ревизия SVN, дата (Часто бывает требование заказчика по размещению своего логотипа, децимального номера и т.д. AD даёт возможность ставить текстовые поля, задаваемые переменными, мы это активно используем)
Другое
- В редакторе отверстий посмотреть все отверстия (на наличие аномалий)
Списки проверок постепенно эволюционируют, добавляются новые пункты, убираются ненужные.
Проверка по перечням позволяет нам находить много ошибок каждый день, а отправлять платы в производство стало не так страшно.
А как вы проверяете свои платы? Поделитесь в комментариях.
* Последняя картинка в тексте иллюстрирует, что даже тщательная проверка не спасёт от невнимательного заказчика.
Почитать по теме
- R.Feranec “8 Steps Schematic Checking Procedure”
- TI “Hardware Design Checklist”
- AD “ Top 10 DFM Problems That Affect Every Design”
- ohwr “Schematic review checklist”
Автор: Иван Ларионов
