Создание электрических схем и трассировка печатных плат становятся всё более простыми делами. Производители компонентов интегрируют в изделия всё больше функционала, выкладывают готовые модели, условные графические обозначения (УГО) и целые схемы, сайты автоматически генерируют источники питания, фильтры и многое другое. Тем не менее, даже при проектировании простых печатных узлов обнаруживаются ошибки, часто — глупые и очевидные.
Мы сегодня не будем говорить про 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 даёт возможность ставить текстовые поля, задаваемые переменными, мы это активно используем)
Другое
- В редакторе отверстий посмотреть все отверстия (на наличие аномалий)
Списки проверок постепенно эволюционируют, добавляются новые пункты, убираются ненужные.
Проверка по перечням позволяет нам находить много ошибок каждый день, а отправлять платы в производство стало не так страшно.
А как вы проверяете свои платы? Поделитесь в комментариях.
* Последняя картинка в тексте иллюстрирует, что даже тщательная проверка не спасёт от невнимательного заказчика.
Почитать по теме
Комментарии (53)
AnotherReality
13.03.2018 00:22Я обычно делаю так:
— схема оформляется как гибрид схемы и блок-схемы — удобно проверять и трассировать; схема сделана — сразу проверили; только после этого трассировка.
— трассировка по блокам, потом компоновка, вычищение всех мелочей, день перерыва, свежим взглядом проверка и тогда проверяет коллега.
— проверка компонентов (соответствие УГО футпринту и шагу между ножек).
— вывод герберов и проверка по ним.
Вот честно, никогда никаких траблов не было кроме шага между ножками и шириной корпуса. Например, SOIC есть узкий и широкий (а называются они одинаково) или QFN с шагом 0.5 и 0.65.Ioanlarionov Автор
13.03.2018 13:58— схема оформляется как гибрид схемы и блок-схемы — удобно проверять и трассировать; схема сделана — сразу проверили;
Вы имеете в виду иерархические схемы с первым листом в виде блоков?
— трассировка по блокам, потом компоновка,
Почему не сначала компоновка, потом трассировка?
— вывод герберов и проверка по ним.
Что и как проверяете по герберам?
Много ли разных устройств делаете?AnotherReality
13.03.2018 21:26Вы имеете в виду иерархические схемы с первым листом в виде блоков?
Проще на примере (блок — рамочка вокруг группы компонентов, с подписью функционального назначения блока). Схема читается слева направо, сверху вниз, все входы слева, выходы справа. 1й блок разъем питания, 2й блок преобразование 12В в 6В, 3й блок — 12В в 5В (очень условно). Блок с МК, блок с драйверами, блок с разъемами под моторы, например. Если в друг что-то случится с командой, то любой новый человек легко поймет что происходит =)
Почему не сначала компоновка, потом трассировка?
Часто есть рекомендуемая топология, сначала опираюсь на нее, потом корректирую в зависимости от габаритов и технологических требований.
Что и как проверяете по герберам?
Просматриваю на наличие лишних перегибов, как пролились полигоны, отверстия, маску (некоторые отверстия закрываю маской, некоторые нет), в принципе. Ну и плюс, правильность формирования герберов. Давно конечно, но было, что не совпали гербера и сверловка. Или что выводили гербера без меня, а овальные почему-то не вывелись (у альтиума они отдельно от круглых).
Много ли разных устройств делаете?
Много, самые разные (бытовая электроника, носимая, лед, мед, неразрушающий контроль, иот), мелкие и крупные партии, местное производство, Китай и Европа =)
potan
13.03.2018 01:40Я несколько лет назад работал программистом в институте, где разрабатывали микроэлектронику. Воркфлоу был примерно такой — программисты писали модель проектируемых модулей на Haskell, потом железячники реализовывали ее на Verilog, записывали в FPGA вместе с процессором LEON (свободный Spark-совместимый) и снова отдавали нам, что бы мы писали тесты (начали на C, но быстро перешли на ассемблер). Иногда к FPGA в соседнем отделе разрабатывали плату с дополнительным железом, например I2S. И с этими платами постоянно возникали проблемы, типа перепутанной полярности RESET. Программистов это очень расстраивало, и мы думали как бы статическую типизацию из Haskell прикрутить к описанию платы. Такого рода ошибки легко бы обнаружились. Но до реализации идеи руки так и не дошли.
NordicEnergy
13.03.2018 09:06+3Что-то не совсем понял суть статьи… Найдите себе рецензента — и это все?
Разрабатываю железо по 50-60 часов в неделю и даже с замыливается глазом ошибок в плате не видел уже года 2-3. Исключение, когда ошибка в даташита была, но и такое сейчас бывает только в совсем новых компонентах.
Чтобы не было ошибок — достаточно просто правильно реализовать проект и использовать нормальный САПР. Тот же Mentor Expedition или Altium никогда не даст тебе соединить, например, землю и vcc, ну и прочее. DRC полностью позволяет избежать ошибок при условии, что схематик правильный. Поэтому если по прежнему есть ошибки в простых проектах (аля stm и рассыпуха), то стоит повышать свою компетенцию, инструменты и менять подход к проектированию.dernuss
13.03.2018 10:36и даже с замыливается глазом ошибок в плате не видел уже года 2-3
Все зависит от сложности проекта. Ну и конечно от опыта ;)
Но в целом да, правильное использование сквозных систем проектирования устраняет ошибки даже если схема сложная (ну или сводит ошибки к минимуму), а разработчик один.
Ioanlarionov Автор
13.03.2018 11:19Могу только позавидовать вашей удаче! Если у вас появятся коллеги — как будете контролировать качество? САПР проверяет очень поверхностно, к сожалению.
NordicEnergy
13.03.2018 12:24Удачи только мелкая часть, скорее системный подход)) Вообще, работая в отделе где было 20+ схемотехников только, действительно давали друг другу проекты на проверку. Тоже метод, но к сожалению даже после изучения 3-4 людьми происходили ошибки, все таки человеческий фактор никуда не убрать пока.
Я для себя нашел спасение в сниппетах и использовании набора стандартных схемотехнических решений, которые у меня уже обкатаны на макете или других проектах. Опять же — человеческий фактор полностью не ушел, а значит и ошибки потенциально могут быть.unalacuna
13.03.2018 15:03Статья как раз о системном подходе. К сожалению (или к счастью), опытных и не ошибающихся инженеров нельзя заказать сразу пяток, с доставкой в офис. Они получаются из неопытных, путём совершения ошибок. Иногда — очень дорогих ошибок.
Проверяя чужую работу и давая пояснения Рецензент учится сам. А перечень — просто способ упорядочить процесс, облегчить передачу знаний. И немного сэкономить на переделках.
pesp
13.03.2018 11:30-1Вы или очень везучий, или очень талантливый человек! Я как ни стараюсь, даже понимая что личные деньги уходят на производство платы, окончательная версия только к третей плате созревает. Я даже с этим смирился…
Возможно 50-60 часов в неделю дают результат, потому как у меня получается 3-5 плат в год разводить, на большее число проектов времени не хватает.NordicEnergy
13.03.2018 12:20Думаю без доли везения однозначно никак, хотя не думаю, что это и особый талант, рука просто набивается. А вообще самое главное — давать мозгам отдыхать. Я обычно доделав проект, делаю перекур 1-2 дня просто переключившись на другой проект, после этого уже смотрю свежим взглядом и все конструктивные недочеты уходят. Все потенциально проблемные узлы желательно в том же LTspice просимулировать, а от косяков в плате САПР спасает.
Самый уязвимый этап — схема. Я, например, после каждого проекта делаю снипеты на удачный узлы схемы или трассировки и стараюсь использовать именно их. То есть у меня есть 3-4 решения для dc/dc преобразователя и в 99% использую опять их же, т.к. решение уже отлажено и не содержит ошибок, а еще это оооочень экономит время.
Кстати заказ плат за свои деньги меня как раз и приучил к сниппетам. Пару раз накосячил с многослойками по 600$ и поумнел))) Это как 2 типа людей: делают бекапы и пока не делают бекапы. Только тут применительно к электронике.pesp
13.03.2018 13:54У меня вся беда в том, что редко случаются проекты с узлами, которые можно дернуть из предыдущих проектов. А еще моя головная боль — Оркад 9.2, принятый за стандарт на нашей конторе. Там DRC просто вообще никакой.
Для остальных проектов использую Kicad — вот там ошибок на порядок меньше. Главным образом схемотехнические косяки. А по платам — только в плане размещения компонентов бывает. С виду вроде все хорошо, а по факту SMD конденсатор чтобы поменять нужно разъем снимать.
И да, почти всегда для аналоговых схем провожу моделирование а LTSpice. Он почему то больше всех приглянулся. Даже если работа схемы кажется очевидной, все равно моделирую. Вылазят интересные моменты по поводу устойчивости работы.stripe
13.03.2018 17:02А не подскажите, есть ли в KiCad что-то наподобие сниплетов? Задумывался над тем чтобы использовать части разведенных плат из предыдущих проэктов, но не очень понятно реализована ли такая возможность в кикаде вообще?
pesp
14.03.2018 09:22Я не встречал. Скорее всего нет. У меня даже не было необходимости таким инструментом воспользоваться.
sstasenco
13.03.2018 10:13Интересно было-бы почитать о том как отлаживать готовую плату.
nerudo
13.03.2018 10:32Берешь плату, берешь план тестирования, берешь подготовленные тесты (ПО и т.д.), берешь нужное оборудование. Идешь последовательно по плану. Если что-то не работает как ожидалось — первым делом осматриваешь визуально плату на случай некачественной сборки. Далее смотришь схему на наличие явных проблем. Потом вооружаешься тестером/осциллографом/спектроанализатором и пытаешься найти корень проблемы. Все очень индивидуально в зависимости от устройства, интерфейса и т.п.
dernuss
13.03.2018 10:38В больших конторах где разработчики и программисты разделены примерно так:
включаешь плату, если дыма нет, несёшь программисту, дальше это его проблема. Если дым есть, твоя проблема ;(NordicEnergy
13.03.2018 10:56Это в средних конторах, а в больших куда забавнее)) Есть hardware, который делится на схемотехника, конструктора плат, механика. Приходит плата. Пошел дым, дергают схемотехника. Он ковыряется и говорит, что со схемой все ок — косяк в трассировке. Дергают конструктора, чтобы он исправлял или боролся дальше. Дальше собирают железку в корпус, если что-то не влезло — карают механика, который 3D модели рисовал и компоновал устройство. Когда отдел hardware весь измучен и наказан, то железо переезжает к firmware…
Последние стартуют, смотрят, что что-то вроде работает и мигает. Натягивают RTOS или linux, библиотеки на голое железо и отдают в software. Последние начинают отгребать за всех: оказывается, что и ddr3 не стартует, и светодиоды не на тех ногах и вообще мало флеша поставили на плату.
Далее в рандомном порядке в полном безумии повторяется операция поиска виноватого и его нагиба. Все это ведет к хаосу. Поэтому сейчас даже большие компании отказываются от такого деления на отделы и уходят на рабочие группы. Например, в моей последней компании были группы: 1 схемотехник + 1 конструктор ПП и механик в одном лице + 3 фирмварщика + 3-4 софтописателя. В принципе и схему, и плату проверяли все вместе. Да еще и премия выдавалась не работнику, а на рабочую группу — даже не самым лучшим людям было выгодно помогать товарищам))
Ioanlarionov Автор
13.03.2018 11:31В общем, да, nerudo описал верно. У нас отладка новых плат начинается без софта — проверяются питания, соответствие диапазонов требованиям ТЗ, а затем, если у программиста что-то не поднимается — начинается совместное творчество. Самое интересное — локализация ошибок и выдвижение гипотез, тут вряд ли можно дать готовый план. У нас многие проекты совместные, когда заказчик проектирует свою часть(СВЧ), а мы — свою(управление и питание) — отладка крайне увлекательна, я вам доложу.
nerudo
13.03.2018 10:27Был свидетелем классической ошибки, доведенной до эпичности. Две больших сложных платы, стыкуются специальными многорядными разъемами через которые тащатся скоростные параллельные интерфейсы. Когда все изготовили, собрали и включили выяснилось что входы включены на входы, а выходы на выходы. Поскольку сигналы разъемов назывались *_in и *_out, но один разработчик имел system-centric, а другой board-centric взгляд на устройство. Ну а тщательно готовить и читать документацию никто не хотел.
lingvo
13.03.2018 11:07+1Ну и как-бы провода на картинках намекают не столько на проверку схем и плат, сколько на проверку схемотехнических решений, прежде чем рисовать свою схему с ними. То есть перед тем, как применять микросхему или модуль в своей схеме, посмотри на reference design, и если твой вариант применения хоть чуть-чуть от него отличается — не ленись, закажи пару семплов, или даже отладочную плату, проверь, поэкспериментируй, спаяй прототип на коленке, сделай демо и только потом переноси в свою схему.
Во первых стоимость ошибки по мере рисования и разводки платы возрастает многократно и все эти эволюционные платы и затраты на прототипирование будут стоить копейки на фоне последующего исправления косяков, а во-вторых всегда будет иметься в наличии референтная рабочая схема, с которой можно будет потом сравнить и проконсультироваться, если что-то не работает на своей плате. Без нее поиск ошибок иногда приводит к танцам с бубном и беганью по форумам.Ioanlarionov Автор
13.03.2018 11:23Действительно, так мы и поступаем! Не помогает! Отладка с одним дисплеем, вам надо другой, другое питание, куча всего ещё сверху, сборка таких макетов будет занимать очень много времени. Мы макетируем только рискованные узлы, дальше — экспериментальная плата.
starenergi
13.03.2018 11:19А не проще подключи питания и пусть плата сделает диагностику сама на каждый блок верифицирует, по возможности можно отрубить отдельно чтоб не кушал питание при выходе из строя. Ведь схема то всеравно отлажена и плата грамотно проработана и компонент лежит на своем посадочном месте
Ioanlarionov Автор
13.03.2018 11:20Плата может в принципе не включиться, до передачи программисту её надо протестировать.
pesp
13.03.2018 11:24Как говорит народная конструкторская мудрость «Сколько в первую плату не смотри, а косяки всегда найдутся»
Не страшно, если какую то цепь не провел, хуже когда с футпринтом ошибся, например графический компонент под DIP8, а присоединил SO-16 (микросхема бывает в двух корпусах).
Графический компонент нарисовал в одно время, а плату разводил через неделю, и корпус выбирал по распространенности в продаже.
А статья отличная! Все четко систематизировано. Автору большое спасибо.Ioanlarionov Автор
13.03.2018 11:33Спасибо!
У нас ключевым полем в базе компонентов является партномер, поэтому разные корпуса — разные компоненты.
Shpiler
13.03.2018 12:56И это все равно не спасет от ситуации, когда ставишь, например, силовой драйвер, потом начинаешь отлаживать, а он греется как сковородка на частотах ШИМ даже в 10 раз ниже разрешенных по ДШ. Начинаешь гуглить — ан нет, норм, у всех греется. Грустно вздыхаешь и идёшь перепроектировать с нормальным драйвером. Реальность — лучший проверяющий. Все равно версии 1.1.2 будут и никуда от них не деться
andreili
13.03.2018 14:48Сейчас для «тренировки» делаю так:
1) Всю схему моделирую в FPGA. Постоянно проверяю на наличие глитчей и прочего из-за асинхронных частей схемы;
2) Как модель ALL-IN-FPGA отлажена, выношу основные компоненты (память, интерфейсы) на макетную плату, подключаемую к FPGA и продолжаю отлаживать с реальными таймингами этих частей;
3) И только после этого рисую схему по проекту из FPGA, по которой потом рисуется и плата.
Но у меня и проекты не сильно-то и большие — укладываются в 2к ALM, на мелкой логике и старых процессорах получается около 100 корпусов. Сейчас, например, моделирую ретро-компьютер Орион-128, сейчас уже на этапе 2, часть схемы уже на этапе 3 (видео-подсистема, с выходом на VGA, с поддержкой 4-х видеорежимов (по разрешению, и ещё 8 по цветности).
Shpakov
13.03.2018 15:44Пару лет назад начальник отдела обещал премию тому разработчику, у кого уже после запуска платы в производство не всплывет какого-либо «нюанса». До сих пор никто не получил…
Alexeyslav
13.03.2018 16:43+1Слишком расплывчатое понятие «какой-либо ньюанс» так можно докопаться и до маркировки на 1мм правее. тоже ведь ньюанс. Критерием должно быть прохождения определённого набора тестов, в которые можно включить к примеру сборку самого устройства.
Shpakov
13.03.2018 17:53В данном случае имелась ввиду именно работа разработчика схемы и вновь разрабатываемые схемы, платы другой отдел разводит. Ну и последующие итерации схемы с учетом выявленных косяков в расчет уже не принимаются.
Vanellope
13.03.2018 19:15Когда делала свою вторую в жизни плату, сделала ее зеркальной. Вот обидно то было, столько времени потрачено. А ведь предварительно распечатала на бумажке, разложила все детальки и радуюсь, что удачно получилось. Раскладывать то надо было на зеркальной копии, а я под утюг и в продакшон.
lingvo
14.03.2018 17:20+1Не расстраивайтесь, я знаю не мало разработчиков, которые свои первые платы зеркалили, или, что почти одно и то же, перепутывали слой компонентов со слоем монтажа. Тоже было все так красиво, а платы в итоге только на стенку в рамочку.
Ioanlarionov Автор
15.03.2018 08:55Да что там первые, к нам на отладку приезжал заказчик с платой, оказалось, внутренние слои не заказали)
Karlson_rwa
14.03.2018 23:19В общих чертах: ERC, DRC, DFM + много опыта по личной сборке и наладке устройств.
Если что-то сложное, то блок-схема в yEd с уточнением интерфейсов и связей.
В схемах — проверенные макро блоки и предварительные консультации с программистами, смогут ли они сделать так, как я планирую.
Какие-то новые не совсем понятные схемы — макеты и отладки с доработками под себя.
Если что-то есть для того же LTSpice'а, то в нём, но и на старуху, как оказалось…
Если компоненты от TI — то обязательно изучение всех вопросов по компоненту в их e2e форуме. А то была чудесная микруха преобразователь pcie-4xUSB3 у которой в даташите и апноуте одно, в эррате чуток другое и на прямой вопрос техасу, дык, делать как в апноуте или эррате, был ответ вида «ну если у вас не работает, то сделайте как в эррате».
В плате после интенсивной трассировки и вылизывания денёк перерыва, потом свежий взгляд, потом зациклить до получения правильного результата.
После этого вывод в герберы и уже изучение герберов на предмет правильного вывода всего и вся. Не помню, где именно когда-то прочитал: «тополог не должен перекладывать на плечи инженера завода свои проблемы». Т.е. если в САПР правила настроены на 4 класс, а по герберам вдруг в некоторых местах получается 5-й, то нельзя лениться, надо корректировать.
Когда работал с коллегами, просил их рисовать блок-схемы будущих устройств. После создания схемы, перед трассировкой, проверяли друг у друга, но это тоже не панацея. Ну и топологию потом так же смотрели.
С механикой по-хорошему надо сначала компоновать, отдавать механику 3d, потом править и так до бесконечности. И только потом трассировка. Но чаще получается в виде «вот тебе объем, тут и тут у нас винты, размещай всё вот здесь». Особенно порадовало на новой работе делать односторонние платы из-за особенностей изделий.
Чтобы не было путаницы в компонентах — все посадочные именуются по IPC. Все УГО называются с учетом конкретного корпуса (это чтобы выводы не попутать). Фактически, один компонент, одно УГО, одно посадочное.
Как правило это помогает со второй итерации получить работоспособное устройство.
А вообще, как показала практика, гарантия хорошей работы почти без ошибок — это стабильная ситуация с зарплатой, отсутствие нервяков и постоянного дерганья. И тогда «состояние потока» проходит с очень большой пользой.Ioanlarionov Автор
15.03.2018 08:49+1Выделять TI как особый случай я бы не стал, это общая практика.
отсутствие нервяков и постоянного дерганья. И тогда «состояние потока» проходит с очень большой пользой
Верно подмечено! Жаль, что жизнь вносит свои корективы и подёргивать — таки приходится иногда.
Напишите, пожалуйста, подробнее о DFM
BigBeaver
15.03.2018 12:30Т.е. если в САПР правила настроены на 4 класс, а по герберам вдруг в некоторых местах получается 5-й, то нельзя лениться, надо корректировать.
Не подскажете подходящий инструмент для такого анализа?Karlson_rwa
15.03.2018 13:25Дык, CAM350.
lingvo
У меня проекты небольшие, поэтому проверяю сам. 3Д тоже нет.
Из того, что делаю обязательно перед отдачей платы на производство — распечатываю сторону компонентов в масштабе 1:1 с проводниками на бумаге и тупо пинцетом устанавливаю на нее все компоненты.
Очень помогает проверить футпринты и если компоненты мешают друг-другу.
dernuss
А если делать футпринты с 3d моделями, не надо будет потом на бумаге расставлять.
BigBeaver
Расклейка на бумагу более информативна, тк позволяет посмотреть, как куда подлезать инструментом, прокладывать кабель и тд. особенно, если присутствуют всякие штуки типа micro-usb, которые трудно рисовать с высокой точностью.
lelik363
На сложные детали можно посмотреть модели у производителя. Сейчас даже «китайцы» их начали поставлять.
unalacuna
Чаще всего рисовать самому ничего не надо, какой-нибудь добрый человек уже всё нарисовал и выложил, только качай
www.3dcontentcentral.com
grabcad.com/library
Если же нужной модели нигде нет — стоит потратить на неё время, заодно навык прокачать. А потом тоже поделиться с сообществом.
BigBeaver
Это все классно, если автор не ошибся и если китайцы отгрузили вам именно то, с чего рисовалась модель.
lingvo
То ж понятно, но, например, этап с бумагой отлично сработал, когда схемотехник (я) выдал перечень элементов снабженцу (мне) и он (то есть я) закупил все компоненты, а когда начал устанавливать их на бумаге, оказалось, что футпринты не совпадают. Те же SOPXX, или не помню какой тип, бывают разные — чуть, чуть шире, чуть чуть уже и на 3D модели фиг заметишь разницу, а компоненты сейчас обзываются чем-то вроде 74AC245NHBDTAMK — и тут легко проморгать разницу при заказе.
И это со мной, а если это два разных человека, то ошибка может возникнуть и 3D модель тут не поможет.
Ioanlarionov Автор
Смысл в дополнительной возможности проверки, абсолютной гарантии, конечно, нет даже с использованием 3D. Однако видно всё замечательно, любой сдвиг и несимметрия сразу бросаются в глаза.
Moog_Prodigy
Интересно, и кого же потом больше ругал шеф (Вы)? Подозреваю, премии лишили всех :)
Ioanlarionov Автор
Для того, чтобы снабженец не ошибся, партномер должен содержать все буквы, обозначающие корпус.
naviastro
Это хорошо и правильно, но не всегда оно есть лучшая альтернатива распечатке на бумаге (скорее дополняют друг друга).
Не всегда оправданно тратить на 3Д-модели время. Распечатка на бумаге и проверка занимают всего несколько минут.
В 3Д-модели можно тоже ошибиться. Например, сделать с небольшим смещением отверстия в радиаторе на плату, IGBT-модуле или в чём-то ещё достаточно крупном. На модели это не будет бросаться в глаза. Даже несколько проверяющих влёгкую пропускают иные баги. Иногда всплывают несоответствия чертежам размеры уже закупленных реальных деталей (сторонние модули, корпуса, например). Бумажка бывает очень быстрым и халявным дебаггером.
Мир несовершенен, люди тоже, нам часто приходится это учитывать)))
dernuss
Все зависит от сложности схемы. Вообще почти всегда оправданно, так как потом модель платы начнут вставлять в модель корпуса и вот тут то 3d очень и очень пригодится, чтобы свести к минимуму ошибки в модели корпуса.
Igler_U