реклама на сайте
подробности

 
 
> УГО компонента по ГОСТ'ам в Altium, Что можно и нужно и чего нельзя делать при создании УГО в Altium'е
anassia
сообщение Jan 18 2016, 07:59
Сообщение #1





Группа: Новичок
Сообщений: 3
Регистрация: 18-05-15
Пользователь №: 86 732



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

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

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

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

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

4. Может ли повлиять отсутствие пинов NC в УГО на корректное прикрепление ПМ (посадочного места) к данному УГО? например, если выводов меньше, чем контактных площадок, в итоге.
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
anassia
сообщение Jan 21 2016, 08:16
Сообщение #2





Группа: Новичок
Сообщений: 3
Регистрация: 18-05-15
Пользователь №: 86 732



Владимир, peshkoff, благодарю вас за ответы про шины - был наиболее интересующим в плане возможности реализации.

Теперь по поводу остальных пунктов:

БД берется не с неба, а является переделкой интегрированных библиотек, накопленных за 6 лет разными разработчиками в рамках одного предприятия. Поэтому все УГО, присутствующие в библиотеке, это именно то, чего когда-то заказывали разработчики, то, как они хотели использовать элемент на схеме. Поэтому все скрытые выводы - самодеятельность разработчиков, а не моя прихоть и не мои правила. Другое дело, когда кто-то начинает пользоваться уже созданным элементом и забывает посмотреть, есть ли скрытые выводы, а потом откуда-то берутся ошибки в схемах.

Т.к. планируется связать элементы с БД снабженцев, необходимо соотношение 1:1 в двух базах. А теперь представьте какой-нибудь элемент логики, который одним разработчиком использовался целиком, а другой захотел разделить его на несколько частей, т.е. по сути два УГО с похожими,но обязательно разными (иначе не будет уникальности, которая необходима индентификатору) названиями, с разным количеством частей и с одинаковыми ПМ. Возникает вопрос, какой из элементов оставлять, чтобы обоим разработчикам было удобно этим пользоваться?
Дискретизация добавляет маневренности и в итоге УГО меньше съедает места на схеме, когда часть выводов не используется. Это с одной стороны. С другой - кому-то проще поставить огромную микросхему на лист и уже с готовой одной работать.

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

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


Цитата(Владимир @ Jan 18 2016, 11:29) *
3 Не поможет от багов

Что вы имеете в виду? Пример можно привести?

И новый вопрос всем:
5. насколько удобно и корректно использовать разваленные УГО микросхем? т.е. каждый вывод рисуется отдельно с левым либо правым бортом корпуса на отдельной части (Part), а потом разработчик просто собирает УГО в той последовательности, как ему будет удобно.

В подобном подходе лично я вижу несколько проблем. Переубедите меня, если кто с таким сталкивался.
Итак:
1) кто-нибудь забудет какой-нибудь вывод поставить на схему
2) выходы и входы поставит вперемешку (иначе за всеми надо будет ПЛИС проверять, что занимает много времени и ничего не упрощает)
3) в принципе разработчик не захочет полусырое УГО, т.к. с ним много возни
4) в ручную необходимо будет дорисовать корпус УГО, скрыть позиционное обозначение, которое формируется автоматически, и добавлять ручками текстовый блок, куда и будет прописываться правильное позиционное обозначение без точки.

Сообщение отредактировал anassia - Jan 21 2016, 08:17
Go to the top of the page
 
+Quote Post
peshkoff
сообщение Jan 21 2016, 14:30
Сообщение #3


люблю бегать и орать
*****

Группа: Свой
Сообщений: 1 685
Регистрация: 28-04-07
Из: ЮБутово@Москва.ru
Пользователь №: 27 376



Цитата(anassia @ Jan 21 2016, 11:16) *
БД берется не с неба, а является переделкой интегрированных библиотек, накопленных за 6 лет разными разработчиками в рамках одного предприятия. Поэтому все УГО, присутствующие в библиотеке, это именно то, чего когда-то заказывали разработчики, то, как они хотели использовать элемент на схеме. Поэтому все скрытые выводы - самодеятельность разработчиков, а не моя прихоть и не мои правила. Другое дело, когда кто-то начинает пользоваться уже созданным элементом и забывает посмотреть, есть ли скрытые выводы, а потом откуда-то берутся ошибки в схемах.


А вы спросите их откуда взялись скрытые выводы? Вероятность 90% что это нормоконтроль их заставил так сделать, т.к. такой пример был приведен в ГОСТ.
В 17 веке, когда элементы рисовались вручную, конечно, это было актуально 300 раз на схеме не писать "+12V" (меньше не было)
Сейчас этой проблемы нет вовсе. Накопипастить можно хоть тыщу.

Но сейчас подобрался конкретный конец скрытым выводам, надеюсь их вообще скоро уберут из всех САПР.
Дело в том, что сейчас под потенциалом, например, +3.3В скрывается далеко не одна цепь!

Вот, например, три потенциала: 1В, 1.2В, 1.5В.

И что будете прописывать в скрытый вывод в библиотеке?

Цитата
Т.к. планируется связать элементы с БД снабженцев, необходимо соотношение 1:1 в двух базах. А теперь представьте какой-нибудь элемент логики, который одним разработчиком использовался целиком, а другой захотел разделить его на несколько частей, т.е. по сути два УГО с похожими,но обязательно разными (иначе не будет уникальности, которая необходима индентификатору) названиями, с разным количеством частей и с одинаковыми ПМ. Возникает вопрос, какой из элементов оставлять, чтобы обоим разработчикам было удобно этим пользоваться?
Дискретизация добавляет маневренности и в итоге УГО меньше съедает места на схеме, когда часть выводов не используется. Это с одной стороны. С другой - кому-то проще поставить огромную микросхему на лист и уже с готовой одной работать.


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

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

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


режимы отображения - зло!

Цитата
Что вы имеете в виду? Пример можно привести?

И новый вопрос всем:
5. насколько удобно и корректно использовать разваленные УГО микросхем? т.е. каждый вывод рисуется отдельно с левым либо правым бортом корпуса на отдельной части (Part), а потом разработчик просто собирает УГО в той последовательности, как ему будет удобно.

В подобном подходе лично я вижу несколько проблем. Переубедите меня, если кто с таким сталкивался.
Итак:
1) кто-нибудь забудет какой-нибудь вывод поставить на схему
2) выходы и входы поставит вперемешку (иначе за всеми надо будет ПЛИС проверять, что занимает много времени и ничего не упрощает)
3) в принципе разработчик не захочет полусырое УГО, т.к. с ним много возни
4) в ручную необходимо будет дорисовать корпус УГО, скрыть позиционное обозначение, которое формируется автоматически, и добавлять ручками текстовый блок, куда и будет прописываться правильное позиционное обозначение без точки.


Извините, но это треш невероятный.

17:41 peshkoff вспомнил, что имел дело с таким...

А да, вспомнил. Мы такое импользовали на разъемах. Дело еще в пикаде было. Если разъем состоял из 50 выводов, то элемент состоял из 50 вентилей по одному выводу.
Типа должно было сэкономить место на листах (кстати, нормоконтроль именно возникал, что нерациональное использование места).
В итоге получаем трудночитаемую схему. Чтобы понять куда поступает цепь физически в разъему нужно обязательно читать номер вывода.
+ гемеррой при установке этого разъема на плату. Чтобы шло быстрее дело, проще найти схему с таким же и скопировать. Фтопку
Go to the top of the page
 
+Quote Post



Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 27th July 2025 - 08:27
Рейтинг@Mail.ru


Страница сгенерированна за 0.01556 секунд с 7
ELECTRONIX ©2004-2016