УГО компонента по ГОСТ'ам в Altium, Что можно и нужно и чего нельзя делать при создании УГО в Altium'е Опции

[anassia]

Доброго времени!

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

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

2. Правильно ли скрытым выводам присваивать номер части, которой они принадлежат, равный 0? просто в таком случае скрытые выводы можно найти на всех частях, а не на конктретной.

3. Связанный с предыдущим вопросом. Если создается несколько режимов отображения частей УГО, есть совет, чтобы одинаковые пины находились в одних и тех же частях УГО. Если один режим со скрытым питанием, а втором с отображаемым, это правило нарушается. Какие могут быть проблемы в связи с этим?

4. Может ли повлиять отсутствие пинов NC в УГО на корректное прикрепление ПМ (посадочного места) к данному УГО? например, если выводов меньше, чем контактных площадок, в итоге.

[Владимир]

то, как они хотели использовать элемент на схеме.

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

А теперь представьте какой-нибудь элемент логики, который одним разработчиком использовался целиком, а другой захотел разделить его на несколько частей, т.е. по сути два УГО с похожими,но обязательно разными (иначе не будет уникальности, которая необходима индентификатору) названиями, с разным количеством частей и с одинаковыми ПМ. Возникает вопрос, какой из элементов оставлять, чтобы обоим разработчикам было удобно этим пользоваться?

Формально это вы такой же дали ответ, что я привел ранее. Раз УГО разные, то и компонеты разные и записи в базе отдельные

Режимы отображения являются выходом в том случае, когда разные разработчики требуют разные УГО на один и тот же элемент. Но в режимах появляется проблема тогда, когда один вид - одна часть (Part), другой вид - 4 части, т.к. в итоге будут видны все 4 части, только в одном режиме три будут пустыми, что ОЧЕНЬ нехорошо и чревато некорректным использованием и ошибками.

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

3 Не поможет от багов
Что вы имеете в виду? Пример можно привести?

в библиотеке нет проблем. Проблемы начнутся на схеме.
Поставить на схему, например счетвереный усилитель. Первая часть подключена на первом листе и требует подключения например к -5 вольтам.
Разработчик ставит 3 часть на 41 листе и там нужно подключение к -12 вольт, что он и делает. Потом они попадают в 1 Footprint и имеем конфликт. оба усилителя будут подключены к одному из указанных напряжений--- Кто это будет разгребать в автоматичсеком режиме?

насколько удобно и корректно использовать разваленные УГО микросхем?

Не удобно. Только при крайней необходимости советую

Итак

вы сами и ответили. Список можно расширить