Альтиум проверка схемы на ошибки

Содержание

  • Компиляция проекта
  • Унифицированная модель данных
  • Изучение связности в панели Navigator
  • Верификация компонентов
  • Настройка верификации
    • Графические проверки
    • Проверки связности
  • Осмысление сообщений и поиск ошибок
    • Исправление предупреждений и ошибок
      • Использование директивы No ERC
  • Подробнее об ошибках компилятора

Полное содержание

Главная страница: Подробнее о схемах

Компиляция проекта

Что означает компиляция проекта? Зачем необходимо компилировать проект? Почему система не может просто отслеживать связность схемы в процессе ее создания?

Система управляет связанными данными на схеме и на плате.
Система управляет связанными данными на схеме и на плате.

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

Если проводить аналогию с разработкой программного обеспечения, то весь исходный код приложения хранился бы в одном файле, и программирование велось бы в среде разработки, которая компилировала бы приложение повторно при каждом изменении файла. Конечно, такой подход не устраивает программистов. Средства разработки позволяют разделить исходный код на множество файлов и разграничить процессы создания, анализа и компиляции. Это позволяет разработчику беспрепятственно создавать и редактировать исходный код, используя нужную структуру файлов. Они компилируют исходники для создания работающего кода только тогда, когда, по их мнению, это необходимо.

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

Когда проект готов к компиляции, выберите команду Compile PCB Project в меню Project.

Система:

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

Благодаря этому подходу, редактор схем становится интеллектуальным средством черчения, а не просто инструментом для определения связей. Когда вы соединяете два вывода с помощью провода, вы, по сути, фиксируете свой инженерный замысел, а не создаете цепь. Цепь не будет создана до момента компиляции проекта, и этот процесс управляется алгоритмами за пределами редактора схем. Как упоминалось ранее, существует ряд преимуществ этого подхода, самым большим из которых является то, что скомпилированная модель проекта находится вне редактора схем и редактора плат. Скомпилированная модель называется унифицированной моделью данных (Unified Data Model – UDM). Эта модель включает в себя подробное описание каждого компонента в проекте и его связь с другими компонентами.

Чтобы узнать подробнее о создании связности, перейдите на страницу Создание связности.

Унифицированная модель данных

В основе системы лежит унифицированная модель данных (Unified Data Model – UDM). При компиляции проекта происходит создание единой связанной модели, которая занимает центральное место в процессе проектирования. Данные этой модели затем можно открывать и изменять с помощью различных редакторов и служб системы. Вместо того, чтобы хранить данные каждого аспекта проектирования по отдельности, модель UDM структурирована для хранения всей информации о проекте, в том числе о компонентах и связи между ними.

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

Итак, как же взаимодействовать с унифицированной моделью данных, чтобы, например, отследить цепь в проекте? Это осуществляется через панель Navigator.

Изучение связности в панели Navigator

Справочная страница: Панель Navigator

Если проект большой и разбит на множество листов, может быть сложно отследить цепь и проверить связность проекта, просто взглянув на схему. Чтобы упростить этот процесс, используется панель Navigator. Панель отображает весь скомпилированный проект, поэтому она будет пустой, пока вы не скомпилируете проект (Project » Compile PCB Project). Панель Navigator можно открыть, нажав кнопку Panels в нижней правой части приложения и выбрав Navigator.

Чтобы использовать панель:

  • Задайте поведение просмотра, нажав кнопку  в верхней части панели – будет открыта страница System — Navigation диалогового окна Preferences, где вы сможете задать предпочитаемый метод подсветки (настройки области Highlight Methods). Либо щелкните ПКМ по интересующему объекту в панели и используйте команды контекстного меню для настройки поведения навигации.
  • Задайте область просмотра в первой области панели. Для просмотра всего проекта выберите Flattened Hierarchy.
  • Щелкните мышью по компоненту в области Instance панели, чтобы перейти к этому компоненту, или разверните компонент, чтобы найти вывод и перейти к нему.
  • Щелкните мышью по цепи или шине в области Net / Bus, чтобы перейти к этой цепи или шине, или разверните цепь или шину, чтобы найти вывод и перейти к нему.

    Щелкните по компоненту или цепи в панели Navigator, чтобы найти этот компонент или цепь и отследить связность в проекте. Щелкните ПКМ, чтобы показать варианты отображения.Щелкните по компоненту или цепи в панели Navigator, чтобы найти этот компонент или цепь и отследить связность в проекте. Щелкните ПКМ, чтобы показать варианты отображения.

Верификация компонентов

Главная страница: Подробнее о компонентах и библиотеках

Ключевым аспектом верификации проекта является проверка корректности компонентов. Как правило, это осуществляется при добавлении компонентов в библиотеки предприятия. Типовые ошибки в компонентах, которые вызывают ошибки на плате, включают в себя:

  • Некорректная ссылка на посадочное место – компонент ссылается на недоступное посадочное место. В процессе передачи проекта из редактора схем в редактор плат система ищет посадочное место в панели Components, в соответствии с настройками библиотеки, заданных для каждого посадочного места в диалоговом окне PCB Model.
  • Выводы не соответствуют контактным площадкам – номера выводов символа компонента не соответствуют номерам контактных площадок. Система предполагает однозначное отображение: например, вывод 4 схемного символа соответствует контактной площадке 4 посадочного места. Это не обязательно – если номера не соответствуют друг другу, соответствие выводов и посадочных мест должно быть задано в процессе создания компонента в диалоговом окне PCB Model.

Прочие нарушения в компонентах, которые могут вызвать ошибки в проектах, включают в себя:

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

Настройка верификации

Главная страница: Диалоговое окно Project Options

Существует обширный ряд графических и электрических проверок, которые можно осуществить для компилируемого проекта. Эти проверки настраиваются в параметрах проекта. Выберите команду Project » Project Options, чтобы открыть диалоговое окно Project Options (последовательность клавиш: C, O). Настройки по умолчанию не подойдут для всех проектов, поэтому важно ознакомиться с ними и понять, как их задавать в соответствии с вашим проектом.

Графические проверки

В ходе компиляции, общие ошибки графики и редактирования проверяются в соответствии с настройками на вкладке Error Reporting диалогового окна Project Options.

Настройка требуемых проверок.
Настройка требуемых проверок.

Проверки сгруппированы по категориям, например Violations Associated with Nets (Нарушения, связанные с цепями), Violations Associated with Documents (Нарушения, связанные с документами), Violations Associated with Components (Нарушения, связанные с компонентами) и т.д. Группы представлены в списке в алфавитном порядке.

Режим отчета для каждого нарушения задан в столбце Report Mode, и для него можно выбрать одно из четырех значений, щелкнув по нему и выбрав нужный вариант из выпадающего списка: Fatal Error (Критическая ошибка), Error (Ошибка), Warning (Предупреждение), No Report (Без отчета).

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

Одной из важных настроек является Nets with only one pin (Цепи только с одним выводом). Ее можно использовать для поиска цепей только с одним узлом, где вывод соединен с портом или меткой цепи, но не соединен с другим выводом. По умолчанию для этого нарушения не задан отчет, но его можно изменить на предупреждение для обнаружения таких цепей.

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

Проверка электрической связности осуществляется в соответствии с настройками на вкладке Connection Matrix диалогового окна Project Options.

Матрица соединений определяет допустимые и недопустимые электрические состояния.
Матрица соединений определяет допустимые и недопустимые электрические состояния.

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

Щелкайте по маленькому квадрату в матрице для изменения определенного правила. Каждое правило определяет уровень отчета для данного сочетания выводов/идентификаторов цепей. Для каждого правила существует четыре возможных значения: Fatal Error (Критическая ошибка), Error (Ошибка), Warning (Предупреждение), No Report (Без отчета).

Настройки на вкладках Error Reporting и Connection Matrix должны быть заданы в соответствии с требованиями текущего проекта.

Осмысление сообщений и поиск ошибок

Главная страница: Панель Messages

После компиляции проекта все предупреждения и ошибки приводятся в панели Messages. Обратите внимание, что панель Messages открывается автоматически, только если существуют ошибки. Чтобы проверить предупреждения, необходимо открыть панель. Нажмите кнопку Panels в нижней правой части приложения, чтобы открыть панель Messages. После того, как проект скомпилирован, в панели будут перечислены все найденные ошибки и предупреждения.

Панель Messages отображает найденные в проекте предупреждения и ошибки.
Панель Messages отображает найденные в проекте предупреждения и ошибки.

Панель Messages является центром управления, где отображаются нарушения компиляции. Следует иметь в виду следующее:

  • Nets with no driving source (Цепи без источника возбуждения, категория Violations associated with Nets) – если цепь не содержит вывод с электрическим типом Output или I/O, возникает эта ошибка. Это может произойти и в корректных состояниях, например, если цепь соединяет вывод соединителя со входным выводом.
  • Nets with multiple names (Цепи со множеством имен, категория Violations associated with Nets) – эта ошибка возникает, если вы изменяете имя цепи. Например, вы подключаете проименованную цепь ко входу в лист с другим именем (что допустимо), поскольку это имя входа в лист лучше отражает функцию цепи на листе более низкого уровня иерархии. Это также происходит в многоканальных проектах, где система должна назначить уникальное имя каждой повторяемой цепи.
  • Component Revision has Inapplicable State (Ревизия компонента в неприменимом состоянии, категория Violations associated with Components) – при этой проверке появляется сообщение Can't perform revision state validation (Невозможно провести валидацию состояния ревизии). Это нарушение возникает, когда ревизия компонента, размещенного с сервера управляемых данных, находится в неприменимом состоянии.
  • Панель Messages разделена на две области – в верхней части представлена таблица всех предупреждений/ошибок, в нижней – описание выбранного в данный момент предупреждения/ошибки.
  • Дважды щелкните по сообщению, чтобы перейти к этому предупреждению/ошибке. Дважды щелкните мышью по описанию, чтобы отобразить конкретный объект.
  • Вы можете щелкнуть по заголовку столбца в панели Messages (например, Class, Document, Message), чтобы отсортировать ошибки и предупреждения.
  • Щелкните ПКМ в панели Messages и выберите команду Clear, чтобы очистить сообщения, или Export, чтобы экспортировать их в отчет.
  • Панель включает в себя предупреждения и ошибки, обнаруженные в соответствии с настройками на вкладках Error Reporting и Connection Matrix.
  • Чтобы открыть диалоговое окно Place Specific No ERC, нажмите кнопку  в панели инструментов Wiring. В диалоговом окне представлен список текущих предупреждений/ошибок компиляции. Здесь поддерживается переход к ошибке и размещение предварительно настроенной специфичной директивы No ERC для выбранной ошибки.
  • При щелчке ПКМ по предупреждению/ошибке в панели Messages и выборе команды Place Specific No ERC for this violation вы автоматически перейдете к месту ошибки, и под курсором появится директива No ERC, готовая к размещению в месте ошибки. Нажмите клавишу Tab, чтобы отредактировать свойства директивы перед ее размещением, если необходимо.
    • Общая директива подавит все проверки ошибок в точке своего размещения.
    • Специфичная директива подавит только заданные проверки в точке своего размещения.

Исправление предупреждений и ошибок

Важно обращать внимание на все обнаруженные предупреждения и ошибки. Не все отчеты, заданные в настройках по умолчанию, могут быть проблемой на самом деле, но вы можете самостоятельно смягчить условия проверок. Например, в проекте может понадобиться, чтобы выводы входа-выхода были подключены ко входным портам, и для этого нужно настроить соответствующую ячейку на вкладке Connection Matrix. Другой проверкой, которую, как правило, нужно изменить, является Net has no driving source (Цепи без источника возбуждения), которую следует отключить на вкладке Error Reporting.

Могут быть ситуации, когда вам необходимо проверить весь проект на определенное условие, но вы хотите проигнорировать предупреждение/ошибку в определенном месте схемы. Например, вы хотите, чтобы цепь была переименована в определенном месте, но только в этом месте. Это можно сделать, разместив в этом месте директиву No ERC.

Использование директивы No ERC

Главная страница: Объект No ERC

Если необходимо, чтобы определенная точка схемы не формировала ошибку, разместите директиву No ERC (Electrical Rules Check – Проверка электрических правил) на этой точке (Place » Directives » Generic No ERC), что будет означать: «не помечать это место как предупреждение/ошибку«. Настройте стиль и цвет символа No ERC в соответствии с его предназначением на схеме в режиме No ERC панели Properties.

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

Обратите внимание, что директивы No ERC можно исключить из распечаток, если необходимо, включив соответствующие параметры в диалоговом окне Schematic Print Properties.

Вы можете разместить директиву Specific No ERC непосредственно в месте ошибки из панели Messages (щелкните ПКМ и выберите команду Place Specific No ERC for this violation, как показано на изображении ниже) или на нарушении.

Команда контекстного меню позволяет легко разместить специфическую директиву No ERC непосредственно в месте ошибки либо из панели Messages, либо из нарушения.
Команда контекстного меню позволяет легко разместить специфическую директиву No ERC непосредственно в месте ошибки либо из панели Messages, либо из нарушения.

Обратите внимание, что директивы No ERC нельзя использовать для подавления всех типов проверок. Когда диалоговое окно No ERC находится в состоянии Violation Types, в нем отображен список типов нарушений, которые можно подавить. Используйте его для изучения того, какие проверки можно подавить.

Подробнее об ошибках компилятора

Система может проверять большое количество состояний потенциальных ошибок. Информация о каждой проверке доступна в Справочнике по нарушениям компиляции проекта.

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

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

Перед
компиляцией следует выполнить настройки
функций контроля. Настройки выполняются
в диалоге, активизируемом командой
главного меню Project>>Document
Options. Открывается
диалоговое окно Options
for Project<имя
проекта>.PrjPcb
с десятью панелями-вкладками,
на которых перечислены все возможные
признаки, по которым выявляются ошибки
проекта.

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

На
вкладке Error Reporting назначается характер
реакции программы на обнаруженные
нарушения:

• No
Report – не включать обнаруженное нарушение
в отчет;


Warning – вывести
предупреждение;


Error – вывести
сообщение об ошибке;


Fatal Error – вывести
сообщение о фатальной ошибке, при которой
невозможно выполнение операции.

Чтобы
установить уровень всех нарушений в
значение Error следует
нажать правой кнопкой мыши в любом месте
окна и выбрать All Error.

Все
типы нарушений на вкладке Error
Reporting разбиты на группы,
по отношению к определенному типу
объектов, варианты их отображения и
рекомендуемые настройки:

1.
Violations Associated
with Buses —
предупреждения, связанные с шинами.

2.
Violations Associated
with Components –
предупреждения, связанные с компонентами.

3.
Violations Associated
with Configuration
Constrains – предупреждения,
связанные с ограничениями конфигурации.

4.
Violations Associated
with Documents –
предупреждения, связанные с документами.

5.
Violations Associated
with Harnesses –
предупреждения, связанные со жгутами.

6.
Violations Associated
with Nets –
предупреждения, связанные с цепями.

7.
Violations Associated with Others, Violations Associated with
Parameters – предупреждения,
связанные с
параметрами и
другие.

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

Вкладка
Class Generation
– правила формирования классов цепей
и компонентов. При желании можно отключить
формирование комнат и классов компонентов
согласно подлистам схемы.

На
вкладке Comparator настраиваются правила
проверки соответствия имен одинаковых
объектов, цепей на листах многолистового
проекта и целого ряда других возможных
ошибок.

Вкладка
ECO Generation –
настройки отчета о перечне изменений.
Выбираются те изменения, которые следует
включить в отчет; по умолчанию включены
все опции – изменять эти данные
нецелесообразно.

Вкладка
Options – группа дополнительных
настроек проекта. Здесь задаются
директории сохранения отчета о компиляции,
компарации и т.д. В группе Output
Options выбираются действия,
которые следует применить после
выполнения процесса компиляции.

Вкладка
Multi Channel –
задает порядок номерации компонентов
при реализации многоканальных и
иерархических проектов.

Вкладка
Default Prints –
настройки распечатки документации
проекта.

Вкладка
Search Puths –
расположение библиотек, в которых по
умолчанию будет проводиться поиск
компонентов.

Вкладка
Parameters – параметры проекта,
которые могут быть использованы для
составления текстовых надписей,
являющихся общими для всех документов
проекта.

Вкладка
Device Sheets –
расположение директорий, содержащих
схемы, которые используются в проекте
в качестве готовых решений (подсхем) в
иерархии нижних уровней.

Компиляция
проекта выполняется по команде главного
меню Project>> Compile Document <имя_схемы>.SchDoc.
Если при компиляции обнаружены ошибки,
сообщения об ошибках выводятся на панель
Messages. В этом случае следует проанализировать
сообщения, внести в схемный документ
необходимые изменения и повторить
компиляцию проекта. Схемный документ,
откомпилированный без ошибок, может
быть передан на проектирование печатной
платы.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

Содержание

  • Компиляция проекта
  • Унифицированная модель данных
  • Изучение связности в панели Navigator
  • Верификация компонентов
  • Настройка верификации
    • Графические проверки
    • Проверки связности
  • Осмысление сообщений и поиск ошибок
    • Исправление предупреждений и ошибок
      • Использование директивы No ERC
  • Подробнее об ошибках компилятора

Полное содержание

Главная страница: Подробнее о схемах

Компиляция проекта

Что означает компиляция проекта? Зачем необходимо компилировать проект? Почему система не может просто отслеживать связность схемы в процессе ее создания?

Система управляет связанными данными на схеме и на плате.
Система управляет связанными данными на схеме и на плате.

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

Если проводить аналогию с разработкой программного обеспечения, то весь исходный код приложения хранился бы в одном файле, и программирование велось бы в среде разработки, которая компилировала бы приложение повторно при каждом изменении файла. Конечно, такой подход не устраивает программистов. Средства разработки позволяют разделить исходный код на множество файлов и разграничить процессы создания, анализа и компиляции. Это позволяет разработчику беспрепятственно создавать и редактировать исходный код, используя нужную структуру файлов. Они компилируют исходники для создания работающего кода только тогда, когда, по их мнению, это необходимо.

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

Когда проект готов к компиляции, выберите команду Compile PCB Project в меню Project.

Система:

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

Благодаря этому подходу, редактор схем становится интеллектуальным средством черчения, а не просто инструментом для определения связей. Когда вы соединяете два вывода с помощью провода, вы, по сути, фиксируете свой инженерный замысел, а не создаете цепь. Цепь не будет создана до момента компиляции проекта, и этот процесс управляется алгоритмами за пределами редактора схем. Как упоминалось ранее, существует ряд преимуществ этого подхода, самым большим из которых является то, что скомпилированная модель проекта находится вне редактора схем и редактора плат. Скомпилированная модель называется унифицированной моделью данных (Unified Data Model – UDM). Эта модель включает в себя подробное описание каждого компонента в проекте и его связь с другими компонентами.

Чтобы узнать подробнее о создании связности, перейдите на страницу Создание связности.

Унифицированная модель данных

В основе системы лежит унифицированная модель данных (Unified Data Model – UDM). При компиляции проекта происходит создание единой связанной модели, которая занимает центральное место в процессе проектирования. Данные этой модели затем можно открывать и изменять с помощью различных редакторов и служб системы. Вместо того, чтобы хранить данные каждого аспекта проектирования по отдельности, модель UDM структурирована для хранения всей информации о проекте, в том числе о компонентах и связи между ними.

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

Итак, как же взаимодействовать с унифицированной моделью данных, чтобы, например, отследить цепь в проекте? Это осуществляется через панель Navigator.

Изучение связности в панели Navigator

Справочная страница: Панель Navigator

Если проект большой и разбит на множество листов, может быть сложно отследить цепь и проверить связность проекта, просто взглянув на схему. Чтобы упростить этот процесс, используется панель Navigator. Панель отображает весь скомпилированный проект, поэтому она будет пустой, пока вы не скомпилируете проект (Project » Compile PCB Project). Панель Navigator можно открыть, нажав кнопку Panels в нижней правой части приложения и выбрав Navigator.

Чтобы использовать панель:

  • Задайте поведение просмотра, нажав кнопку  в верхней части панели – будет открыта страница System — Navigation диалогового окна Preferences, где вы сможете задать предпочитаемый метод подсветки (настройки области Highlight Methods). Либо щелкните ПКМ по интересующему объекту в панели и используйте команды контекстного меню для настройки поведения навигации.
  • Задайте область просмотра в первой области панели. Для просмотра всего проекта выберите Flattened Hierarchy.
  • Щелкните мышью по компоненту в области Instance панели, чтобы перейти к этому компоненту, или разверните компонент, чтобы найти вывод и перейти к нему.
  • Щелкните мышью по цепи или шине в области Net / Bus, чтобы перейти к этой цепи или шине, или разверните цепь или шину, чтобы найти вывод и перейти к нему.

    Щелкните по компоненту или цепи в панели Navigator, чтобы найти этот компонент или цепь и отследить связность в проекте. Щелкните ПКМ, чтобы показать варианты отображения.Щелкните по компоненту или цепи в панели Navigator, чтобы найти этот компонент или цепь и отследить связность в проекте. Щелкните ПКМ, чтобы показать варианты отображения.

Верификация компонентов

Главная страница: Подробнее о компонентах и библиотеках

Ключевым аспектом верификации проекта является проверка корректности компонентов. Как правило, это осуществляется при добавлении компонентов в библиотеки предприятия. Типовые ошибки в компонентах, которые вызывают ошибки на плате, включают в себя:

  • Некорректная ссылка на посадочное место – компонент ссылается на недоступное посадочное место. В процессе передачи проекта из редактора схем в редактор плат система ищет посадочное место в панели Components, в соответствии с настройками библиотеки, заданных для каждого посадочного места в диалоговом окне PCB Model.
  • Выводы не соответствуют контактным площадкам – номера выводов символа компонента не соответствуют номерам контактных площадок. Система предполагает однозначное отображение: например, вывод 4 схемного символа соответствует контактной площадке 4 посадочного места. Это не обязательно – если номера не соответствуют друг другу, соответствие выводов и посадочных мест должно быть задано в процессе создания компонента в диалоговом окне PCB Model.

Прочие нарушения в компонентах, которые могут вызвать ошибки в проектах, включают в себя:

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

Настройка верификации

Главная страница: Диалоговое окно Project Options

Существует обширный ряд графических и электрических проверок, которые можно осуществить для компилируемого проекта. Эти проверки настраиваются в параметрах проекта. Выберите команду Project » Project Options, чтобы открыть диалоговое окно Project Options (последовательность клавиш: C, O). Настройки по умолчанию не подойдут для всех проектов, поэтому важно ознакомиться с ними и понять, как их задавать в соответствии с вашим проектом.

Графические проверки

В ходе компиляции, общие ошибки графики и редактирования проверяются в соответствии с настройками на вкладке Error Reporting диалогового окна Project Options.

Настройка требуемых проверок.
Настройка требуемых проверок.

Проверки сгруппированы по категориям, например Violations Associated with Nets (Нарушения, связанные с цепями), Violations Associated with Documents (Нарушения, связанные с документами), Violations Associated with Components (Нарушения, связанные с компонентами) и т.д. Группы представлены в списке в алфавитном порядке.

Режим отчета для каждого нарушения задан в столбце Report Mode, и для него можно выбрать одно из четырех значений, щелкнув по нему и выбрав нужный вариант из выпадающего списка: Fatal Error (Критическая ошибка), Error (Ошибка), Warning (Предупреждение), No Report (Без отчета).

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

Одной из важных настроек является Nets with only one pin (Цепи только с одним выводом). Ее можно использовать для поиска цепей только с одним узлом, где вывод соединен с портом или меткой цепи, но не соединен с другим выводом. По умолчанию для этого нарушения не задан отчет, но его можно изменить на предупреждение для обнаружения таких цепей.

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

Проверка электрической связности осуществляется в соответствии с настройками на вкладке Connection Matrix диалогового окна Project Options.

Матрица соединений определяет допустимые и недопустимые электрические состояния.
Матрица соединений определяет допустимые и недопустимые электрические состояния.

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

Щелкайте по маленькому квадрату в матрице для изменения определенного правила. Каждое правило определяет уровень отчета для данного сочетания выводов/идентификаторов цепей. Для каждого правила существует четыре возможных значения: Fatal Error (Критическая ошибка), Error (Ошибка), Warning (Предупреждение), No Report (Без отчета).

Настройки на вкладках Error Reporting и Connection Matrix должны быть заданы в соответствии с требованиями текущего проекта.

Осмысление сообщений и поиск ошибок

Главная страница: Панель Messages

После компиляции проекта все предупреждения и ошибки приводятся в панели Messages. Обратите внимание, что панель Messages открывается автоматически, только если существуют ошибки. Чтобы проверить предупреждения, необходимо открыть панель. Нажмите кнопку Panels в нижней правой части приложения, чтобы открыть панель Messages. После того, как проект скомпилирован, в панели будут перечислены все найденные ошибки и предупреждения.

Панель Messages отображает найденные в проекте предупреждения и ошибки.
Панель Messages отображает найденные в проекте предупреждения и ошибки.

Панель Messages является центром управления, где отображаются нарушения компиляции. Следует иметь в виду следующее:

  • Nets with no driving source (Цепи без источника возбуждения, категория Violations associated with Nets) – если цепь не содержит вывод с электрическим типом Output или I/O, возникает эта ошибка. Это может произойти и в корректных состояниях, например, если цепь соединяет вывод соединителя со входным выводом.
  • Nets with multiple names (Цепи со множеством имен, категория Violations associated with Nets) – эта ошибка возникает, если вы изменяете имя цепи. Например, вы подключаете проименованную цепь ко входу в лист с другим именем (что допустимо), поскольку это имя входа в лист лучше отражает функцию цепи на листе более низкого уровня иерархии. Это также происходит в многоканальных проектах, где система должна назначить уникальное имя каждой повторяемой цепи.
  • Component Revision has Inapplicable State (Ревизия компонента в неприменимом состоянии, категория Violations associated with Components) – при этой проверке появляется сообщение Can't perform revision state validation (Невозможно провести валидацию состояния ревизии). Это нарушение возникает, когда ревизия компонента, размещенного с сервера управляемых данных, находится в неприменимом состоянии.
  • Панель Messages разделена на две области – в верхней части представлена таблица всех предупреждений/ошибок, в нижней – описание выбранного в данный момент предупреждения/ошибки.
  • Дважды щелкните по сообщению, чтобы перейти к этому предупреждению/ошибке. Дважды щелкните мышью по описанию, чтобы отобразить конкретный объект.
  • Вы можете щелкнуть по заголовку столбца в панели Messages (например, Class, Document, Message), чтобы отсортировать ошибки и предупреждения.
  • Щелкните ПКМ в панели Messages и выберите команду Clear, чтобы очистить сообщения, или Export, чтобы экспортировать их в отчет.
  • Панель включает в себя предупреждения и ошибки, обнаруженные в соответствии с настройками на вкладках Error Reporting и Connection Matrix.
  • Чтобы открыть диалоговое окно Place Specific No ERC, нажмите кнопку  в панели инструментов Wiring. В диалоговом окне представлен список текущих предупреждений/ошибок компиляции. Здесь поддерживается переход к ошибке и размещение предварительно настроенной специфичной директивы No ERC для выбранной ошибки.
  • При щелчке ПКМ по предупреждению/ошибке в панели Messages и выборе команды Place Specific No ERC for this violation вы автоматически перейдете к месту ошибки, и под курсором появится директива No ERC, готовая к размещению в месте ошибки. Нажмите клавишу Tab, чтобы отредактировать свойства директивы перед ее размещением, если необходимо.
    • Общая директива подавит все проверки ошибок в точке своего размещения.
    • Специфичная директива подавит только заданные проверки в точке своего размещения.

Исправление предупреждений и ошибок

Важно обращать внимание на все обнаруженные предупреждения и ошибки. Не все отчеты, заданные в настройках по умолчанию, могут быть проблемой на самом деле, но вы можете самостоятельно смягчить условия проверок. Например, в проекте может понадобиться, чтобы выводы входа-выхода были подключены ко входным портам, и для этого нужно настроить соответствующую ячейку на вкладке Connection Matrix. Другой проверкой, которую, как правило, нужно изменить, является Net has no driving source (Цепи без источника возбуждения), которую следует отключить на вкладке Error Reporting.

Могут быть ситуации, когда вам необходимо проверить весь проект на определенное условие, но вы хотите проигнорировать предупреждение/ошибку в определенном месте схемы. Например, вы хотите, чтобы цепь была переименована в определенном месте, но только в этом месте. Это можно сделать, разместив в этом месте директиву No ERC.

Использование директивы No ERC

Главная страница: Объект No ERC

Если необходимо, чтобы определенная точка схемы не формировала ошибку, разместите директиву No ERC (Electrical Rules Check – Проверка электрических правил) на этой точке (Place » Directives » Generic No ERC), что будет означать: «не помечать это место как предупреждение/ошибку«. Настройте стиль и цвет символа No ERC в соответствии с его предназначением на схеме в режиме No ERC панели Properties.

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

Обратите внимание, что директивы No ERC можно исключить из распечаток, если необходимо, включив соответствующие параметры в диалоговом окне Schematic Print Properties.

Вы можете разместить директиву Specific No ERC непосредственно в месте ошибки из панели Messages (щелкните ПКМ и выберите команду Place Specific No ERC for this violation, как показано на изображении ниже) или на нарушении.

Команда контекстного меню позволяет легко разместить специфическую директиву No ERC непосредственно в месте ошибки либо из панели Messages, либо из нарушения.
Команда контекстного меню позволяет легко разместить специфическую директиву No ERC непосредственно в месте ошибки либо из панели Messages, либо из нарушения.

Обратите внимание, что директивы No ERC нельзя использовать для подавления всех типов проверок. Когда диалоговое окно No ERC находится в состоянии Violation Types, в нем отображен список типов нарушений, которые можно подавить. Используйте его для изучения того, какие проверки можно подавить.

Подробнее об ошибках компилятора

Система может проверять большое количество состояний потенциальных ошибок. Информация о каждой проверке доступна в Справочнике по нарушениям компиляции проекта.

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

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

Перед
компиляцией следует выполнить настройки
функций контроля. Настройки выполняются
в диалоге, активизируемом командой
главного меню Project>>Document
Options. Открывается
диалоговое окно Options
for Project<имя
проекта>.PrjPcb
с десятью панелями-вкладками,
на которых перечислены все возможные
признаки, по которым выявляются ошибки
проекта.

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

На
вкладке Error Reporting назначается характер
реакции программы на обнаруженные
нарушения:

• No
Report – не включать обнаруженное нарушение
в отчет;


Warning – вывести
предупреждение;


Error – вывести
сообщение об ошибке;


Fatal Error – вывести
сообщение о фатальной ошибке, при которой
невозможно выполнение операции.

Чтобы
установить уровень всех нарушений в
значение Error следует
нажать правой кнопкой мыши в любом месте
окна и выбрать All Error.

Все
типы нарушений на вкладке Error
Reporting разбиты на группы,
по отношению к определенному типу
объектов, варианты их отображения и
рекомендуемые настройки:

1.
Violations Associated
with Buses —
предупреждения, связанные с шинами.

2.
Violations Associated
with Components –
предупреждения, связанные с компонентами.

3.
Violations Associated
with Configuration
Constrains – предупреждения,
связанные с ограничениями конфигурации.

4.
Violations Associated
with Documents –
предупреждения, связанные с документами.

5.
Violations Associated
with Harnesses –
предупреждения, связанные со жгутами.

6.
Violations Associated
with Nets –
предупреждения, связанные с цепями.

7.
Violations Associated with Others, Violations Associated with
Parameters – предупреждения,
связанные с
параметрами и
другие.

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

Вкладка
Class Generation
– правила формирования классов цепей
и компонентов. При желании можно отключить
формирование комнат и классов компонентов
согласно подлистам схемы.

На
вкладке Comparator настраиваются правила
проверки соответствия имен одинаковых
объектов, цепей на листах многолистового
проекта и целого ряда других возможных
ошибок.

Вкладка
ECO Generation –
настройки отчета о перечне изменений.
Выбираются те изменения, которые следует
включить в отчет; по умолчанию включены
все опции – изменять эти данные
нецелесообразно.

Вкладка
Options – группа дополнительных
настроек проекта. Здесь задаются
директории сохранения отчета о компиляции,
компарации и т.д. В группе Output
Options выбираются действия,
которые следует применить после
выполнения процесса компиляции.

Вкладка
Multi Channel –
задает порядок номерации компонентов
при реализации многоканальных и
иерархических проектов.

Вкладка
Default Prints –
настройки распечатки документации
проекта.

Вкладка
Search Puths –
расположение библиотек, в которых по
умолчанию будет проводиться поиск
компонентов.

Вкладка
Parameters – параметры проекта,
которые могут быть использованы для
составления текстовых надписей,
являющихся общими для всех документов
проекта.

Вкладка
Device Sheets –
расположение директорий, содержащих
схемы, которые используются в проекте
в качестве готовых решений (подсхем) в
иерархии нижних уровней.

Компиляция
проекта выполняется по команде главного
меню Project>> Compile Document <имя_схемы>.SchDoc.
Если при компиляции обнаружены ошибки,
сообщения об ошибках выводятся на панель
Messages. В этом случае следует проанализировать
сообщения, внести в схемный документ
необходимые изменения и повторить
компиляцию проекта. Схемный документ,
откомпилированный без ошибок, может
быть передан на проектирование печатной
платы.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #
  • #

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

Производство и разработка электроники, Схемотехника, Блог компании Третий пин


Рекомендация: подборка платных и бесплатных курсов Python — https://katalog-kursov.ru/

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

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

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

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

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

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

  • R.Feranec “8 Steps Schematic Checking Procedure”
  • TI “Hardware Design Checklist”
  • AD “ Top 10 DFM Problems That Affect Every Design”
  • ohwr “Schematic review checklist”

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

Схематическая компиляция:

Схематический интерфейс Выберите строку меню: Project —-> Compile PCB Project

Затем вы можете нажать на панели —-> Сообщение в правом нижнем углу, вы можете открыть интерфейс сообщений.

                                                              

                                                             

Для работы схема успешна, и пользователю необходимо изменить письмо об ошибке панели сообщения (модификация означает изменение вашей схемы), знать коррекцию завершения схемы

Обычное обнаружение схемы:

Схематический выбор меню выбора интерфейса: проект —-> Инженерные варианты

                                                                    

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

СПЕЦИАЛЬНОЕ ПРИМЕЧАНИЕ. Пользователи не хотят модифицировать систему Check Check = Формат отчета пункта, если пользователь не знает этих тестовых элементов

Наконец, слушать общие схематические ошибки

1, Дублируйте дизайнеры деталей: есть повторяющийся компонентный битовый номер

2, плавающие чистые этикетки: сетевая подвеска

3, Объекты с плавающей напряжением: есть парящий порт источника питания

4, сети с лишь контактом: есть односторонняя сеть

5, сеть с нескольким именем: имя сети повторить

6, Off Grid Object: объект не находится в растровой точке

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

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

Мы сегодня не будем говорить про 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

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

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

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

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

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

  • R.Feranec “8 Steps Schematic Checking Procedure”
  • TI “Hardware Design Checklist”
  • AD “ Top 10 DFM Problems That Affect Every Design”
  • ohwr “Schematic review checklist”

Источник

Читайте также

4 часа назад

Сегодня в 11:01

Вчера в 16:25

Altium Designer обеспечивает гибкую среду для установки различных правил проектирования, что обеспечивает целостность проекта. Обычно, правила проектирования устанавливаются в начале работы, а затем проводится проверка соответствия проекта правилам при компиляции.

Часто правила изменяются или добавляются новые во время трассировки. Для проверки платы на предмет соответствия установленным правилам проектирования после трассировки, используется программа DRC (Design Rule Check -Контроль Правил Проектирования). Программа Design Rule Checker (DRC) представляет собой высокопроизводительный автоматизированный программный модуль, проверяющий как логическую, так и физическую целостность проекта печатной платы. Использование этого модуля при трассировке обязательно для контроля соблюдения минимальных зазоров и отсутствия других нарушений. Так как редактор печатных плат позволяет в любое время вносить изменения в проект, рекомендуется всегда выполнять проверку правил проектирования перед окончательным выводом чертежей.

Функция проверки правил проектирования в режиме реального времени активизируется на вкладке PCB > General диалогового окна Preferences (см.Рис.1).

6,5-1

Рис.1. Включение функции проверки правил в режиме реального времени

Включение этой функции в режиме ручной трассировки позволяет незамедлительно обнаружить и выделить ошибки. Для установки правил которые будут поверятся в реальном времени необходимо выполнить Tools > Design Rule Checkи перейти на вкладку Rule To Check (см.Рис.2).

6,5-2

Рис.2. Список правил постоянной и ручной проверки

Для включения правила в постоянную (online) или ручную (batch) проверку следует установить флаг в соответствующем столбце напротив данного правила (см. Рис. 2).

Чтобы включить/выключить все правила, следует нажать ПКМ на названии любого правила и в выпадающем списке выбрать соответствующее значение. Рекомендуется для постоянной проверки выключить все правила (OnlineDRCAllOff) и включить только проверку зазоров по металлизации и между компонентами (Clearance и Component Clearance). В ручную проверку желательно включить все правила, которые были созданы для данного проекта (Batch DRC-Used On).

Перед запуском ручной проверки можно указать дополнительные параметры на вкладке Report Options, которые позволяют:

  • Create Report File – автоматически создавать файл отчёта программы проверки правил проектирования с расширением .DRC, который затем открывается текстовым редактором;
  • Create Violations – подсвечивать нарушения; при включении этой настройки места нарушения правил (примитивы) будут выделяться заданным цветом;
  • Sub-Net Details – работать совместно с правилом проектирования Unrouted Net Rule. Включается в случаях, когда требуется просмотреть все детали неразведённых цепей. Правило проектирования Unrouted Net Rule должно включаться только после трассировки всех соединений, т.к. виртуальная линия связи соединений воспринимается программой проверки как разомкнутая цепь;
  • Verifyshortingcopper – проверка короткого замыкания;
  • ReportDrilledSMDpadsавтоматически создавать файл отчёта о сверлении SMDконтактных площадок;
  • Reportmultilayerpadswith 0 sizehole — автоматически создавать файл отчёта о прокладки «нулевых» отверстий в многослойных платах;
  • StopWhenXXViolationsfound– автоматически остановить процесс проверки правил проектирования при нахождении заданного числа нарушений.

Для запуска ручной проверки необходимо нажать кнопку Run Design Rule Check. Будетзапущен DRC иоткрытфайлотчёта Design Rule Verification Report. Результат всех обнаруженных в проекте нарушений будет отображён в панели Messages. Для перехода к ошибке на плате необходимо дважды нажать ЛК на ошибке в панели Messages. Места ошибок отмечаются стрелками и указывается невыполненный предел правила (если это касается правила зазора, см. Рис.3).

6,5-3

Рис.3. Обозначение ошибки правила зазора

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

Проверка печатных плат методом визуального контроля

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

Несмотря на это даже при проектировании простых печатных плат возникают ошибки, которые впоследствии могут значительно повлиять на работоспособность и функциональность электронного устройства. Рассмотрим, как избежать сбоев и дефектов печатных плат на примере системного подхода, применяемого специалистами «Третий пин».

Доверяй, но проверяй

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

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

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

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

Описание порядка проверки электрических схем и печатных плат

Пример сборки печатной платы

Как только печатная плата, по мнению инженера, полностью готова, проведена компоновка отдельных узлов ЭС, трассировка и оформление чертежей, выполняется верификация конструкции. Для этого в системе управления проектами (мы используем Redmine) другому разработчику ставится задача по проверке. Рецензент обязательно должен иметь опыт и знания в проектировании ПП. Так же ему необходимо будет изучить требования ТЗ и дополнительные материалы. Время на выполнение этой задачи должно быть заложено еще на стадии планирования проекта. При этом важно рецензенту не обрушиваться с критикой сразу на разработчика. Основная цель — помочь достигнуть результата и выполнения условий проекта.

Юмор на тему проверки

После ознакомления с заданием рецензент в комментарии к задаче копирует перечень проверок и оставляет пометки, используя следующее обозначение:

  • «+» или «-» при прохождении или невыполнении пунктов чек-листа;
  • курсив для рекомендаций и вопросов, которые возникают в ходе работ;
  • выделение жирным для пометки явных ошибок.

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

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

Как правило, при проектировании печатных плат мы используем иерархические многостраничные схемы, для которых на каждом листе рецензент проводит повторение пункта «Блок». Для простых ПП все этапы анализа размещаются на одном листе.

Новые компоненты

При проверке новых компонентов выполняется оценка электрической схемы по списку из задачи в Redmine и по Datasheet, где отслеживаются следующие компоненты:

  • назначение;
  • номера контактов;
  • посадочное место;
  • соответствие ссылок на описания.

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

Первый лист

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

На следующем этапе проверяются тип, распиновка и соответствие номеров разъемов данным на электрической схеме. Блоки должны отвечать охвату функционала, заявленному количеству и иметь синхронизацию выводов символов листов.

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

Проверка блоков

В определение правильности составления простых схем (чаще всего одной микросхемы с обвязкой) входит оценка прихода линий интерфейсов и подачи сигналов. При этом должно соблюдаться правило: питание нужного номинала, аналоговые контакты подаются к аналоговым, земля — к земле. Для любых микросхем требуется проверить по Datasheet назначение, толерантнось к 5B и другим напряжениям у выхода контроллера. На каждом листе рецензент оценивает перечень используемых питаний и максимальное потребление по ним. Помимо всего прочего, в проверку блоков входит обозначение классов цепей для выделения специфических мест, например, развязки.

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

В этом перечне проверяется используемые питания и их потребления. У каждого источника оцениваются:

  • выходное напряжение;
  • ток;
  • рассеиваемая мощность;
  • КПД.

Кроме этого, проверяется обозначение классов цепей (Power, HV). Для каждого источника рецензенту необходимо сверить схему включения по Datasheet.

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

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

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

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

В чек-лист по обнаружению ошибок проектирования конструкции печатной платы входит оценка:

  • формы на соответствие модели, ТЗ, чертежу;
  • толщины;
  • крепежа по достаточности, зазорам для головок винтов и шайб, попаданию в места на ПП;
  • разъемов по ориентации первых ножек, положению, распиновке с сочленяемыми платами;
  • высоты компонентов;
  • положения специфических элементов.

На следующем этапе рецензент проверяет связность проекта для оценки отсутствия разницы в электрической схеме и печатной плате. В перечень входит оценка ошибок в Design-Update Sch in PrjPcb, Design-Import Changes from PrjPcb, Project-Component Links. В Altium Designer между компонентами возможны потери связи из-за вставки элементов на плату, перенумерации и т. д.

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

В перечень данной части чек-листа входит следующие показатели:

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

Трехмерные модели в Altium Designer позволяют дополнительно оценить правильность посадочного места. Они участвуют в проверке и проработке конструкции, помогают получить красивые и наглядные рендеры печатных плат.

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

В данный пункт входит оценка:

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

В Altium Designer рецензент запускает DRC. В случае непрохождения этапа проверка прекращается.

Питание

Оценка включает определение общей логики расположения источников и нагрузок, а также проверку:

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

Для оценки источников питания необходимо открыть Datasheet и свериться с рекомендуемой топологией.

Шелкография

Блок оценки корректности размещения маркировки на печатной плате включает определение соответствия следующих параметров:

  • размещения надписей не на отверстиях и не под корпусами, не затрагивая друг друга;
  • шрифт Default высотой 1 мм и толщиной 0,2 мм;
  • ориентация любых подписей на одном листе только 0-90 или 0-270 градусов;
  • обозначение назначения разъемов и тестовых точек;
  • указание первого пина у разъемов и микросхем;
  • обозначение 5–10-кратных пинов и рядов у BGA для крупных схем;
  • четкая последовательность в группах компонентов и связей;
  • название платы, логотип, дата, ревизия SVN.

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

Пример печатной платы для заказчика

Разработка печатной платы

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

Читать статью

Оригиналы опубликованы на Хабре и Medium

$begingroup$

I’ve routed my PCB but had to change the minimum keepout rules which means I’ll now have a lot of DRC errors — most tracks are too closely placed together and that would violate the new keepout rule.

However, I can see the errors only when I route a track. altium violation

Is there a way to see all DRC violations at a glance? I’m sure there’s a better way of doing it than selecting each track individually.

asked Apr 28, 2016 at 16:54

Plesos's user avatar

$endgroup$

1

$begingroup$

If you have your rules set up properly, all you have to do is go to Tools —> Design Rule Check and click «Run Design Rule Check» at the bottom left of the pane. I tend to use the shortcut T-D-Enter and it does all of the above in just three keystrokes. This will list all of the design errors, provided you told the DRC to check them in the batch check. If you want to change what rules it looks for, go to Tools —> Design Rule Check (or shortcut T-D) and in the left-pane, under «Rules To Check», you can select your category and which rules you want the DRC to check.

answered Apr 28, 2016 at 19:12

DerStrom8's user avatar

DerStrom8DerStrom8

20.6k8 gold badges58 silver badges94 bronze badges

$endgroup$

$begingroup$

Go to Tools : DRC check. Make sure to enable all applicable errors in a long hierarchical list. Then run Batch DRC. It has to mark all violations in green color and make a list of violations in Messages window.

By the way, you can automatically change the width of certain traces using Altium scripts.

answered Apr 28, 2016 at 18:10

Master's user avatar

MasterMaster

1,2496 silver badges4 bronze badges

$endgroup$

$begingroup$

I’ve routed my PCB but had to change the minimum keepout rules which means I’ll now have a lot of DRC errors — most tracks are too closely placed together and that would violate the new keepout rule.

However, I can see the errors only when I route a track. altium violation

Is there a way to see all DRC violations at a glance? I’m sure there’s a better way of doing it than selecting each track individually.

asked Apr 28, 2016 at 16:54

Plesos's user avatar

$endgroup$

1

$begingroup$

If you have your rules set up properly, all you have to do is go to Tools —> Design Rule Check and click «Run Design Rule Check» at the bottom left of the pane. I tend to use the shortcut T-D-Enter and it does all of the above in just three keystrokes. This will list all of the design errors, provided you told the DRC to check them in the batch check. If you want to change what rules it looks for, go to Tools —> Design Rule Check (or shortcut T-D) and in the left-pane, under «Rules To Check», you can select your category and which rules you want the DRC to check.

answered Apr 28, 2016 at 19:12

DerStrom8's user avatar

DerStrom8DerStrom8

20.6k8 gold badges58 silver badges94 bronze badges

$endgroup$

$begingroup$

Go to Tools : DRC check. Make sure to enable all applicable errors in a long hierarchical list. Then run Batch DRC. It has to mark all violations in green color and make a list of violations in Messages window.

By the way, you can automatically change the width of certain traces using Altium scripts.

answered Apr 28, 2016 at 18:10

Master's user avatar

MasterMaster

1,2496 silver badges4 bronze badges

$endgroup$

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

Схематическая компиляция:

Схематический интерфейс Выберите строку меню: Project —-> Compile PCB Project

Затем вы можете нажать на панели —-> Сообщение в правом нижнем углу, вы можете открыть интерфейс сообщений.

                                                              

                                                             

Для работы схема успешна, и пользователю необходимо изменить письмо об ошибке панели сообщения (модификация означает изменение вашей схемы), знать коррекцию завершения схемы

Обычное обнаружение схемы:

Схематический выбор меню выбора интерфейса: проект —-> Инженерные варианты

                                                                    

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

СПЕЦИАЛЬНОЕ ПРИМЕЧАНИЕ. Пользователи не хотят модифицировать систему Check Check = Формат отчета пункта, если пользователь не знает этих тестовых элементов

Наконец, слушать общие схематические ошибки

1, Дублируйте дизайнеры деталей: есть повторяющийся компонентный битовый номер

2, плавающие чистые этикетки: сетевая подвеска

3, Объекты с плавающей напряжением: есть парящий порт источника питания

4, сети с лишь контактом: есть односторонняя сеть

5, сеть с нескольким именем: имя сети повторить

6, Off Grid Object: объект не находится в растровой точке

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

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

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

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

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

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

  • R.Feranec “8 Steps Schematic Checking Procedure”
  • TI “Hardware Design Checklist”
  • AD “ Top 10 DFM Problems That Affect Every Design”
  • ohwr “Schematic review checklist”

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

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


42.04%
Нет коллег, сижу один.
66

Проголосовали 157 пользователей.

Воздержались 42 пользователя.

  • Альтивар ошибка osf от чего возникает
  • Альтивар ошибка olf от чего возникает
  • Альтивар 71 ошибка tjf
  • Альтивар 71 ошибка phf
  • Альтивар 71 ошибка nst