Никогда не пользовался этим, проверил, работает. Даже не знаю, скиньте Ваш целл, что ли...

Вот такой селл. Это наверняка тривиальные вещи, но т.к. я пару недель назад начал изучение HDL, трудности возникают на каждом шагу. Даже в этом файле , могли бы вы мне подсказать, как отдельному package добавить отдельный свой symbol. А то либо они все добавляются, либо (если использовать разные для каждого Package) выскакивает ошибка, что пины применены только в одном Package а не во всех.

1. Добавьте к значениям единицы изменения. Я добавил буквы Ohm в каждую строку и все заработало. В запросе тоже их надо писать (<50Ohm). Откуда столько резисторов, если не секрет?
2. Вы хотите каждому пекеджу своё УГО? Не мучайтесь, нарисуйте один резистор и забудьте. Вместо разных пекаджей (и, соответственно, разных разделов в ptf) задайте несколько PACK_TYPE внутри одного корпуса. Ваш исходный вопрос содержится в предыдущих постах топика, я в свое время тоже хотел сделать что-то подобное, но в итоге отказался от этого и не жалею.

Прекрасно! Премного благодарен, все получилось))!! Резисторы - из даташита http://www.yageo.com/documents/recent/PYu-...51_RoHS_L_1.pdf - делаю на будущее, и опыт заодно набиваю... В дальнейшем добавлю пару колонок с аналогами.
2. Т.е. я добавляю колонку "Pack_Type" в файл ptf, прописываю там названия для "корпусов" и оставляю один гигантский PART? Допустим они как-то коррелируют с "Pack_Type", созданными в Package(Physical_Parts). А дальше я что-то опять не могу понять, каким образом сделать так, чтобы для резисторов 0,5Вт отображался один символ(с продольной чертой), а для резисторов в 1 Вт отображался другой(с поперечной чертой).

1. В смысле, неужто вручную столько понасоздавали? Колонки с аналогами я, все-таки, не советую делать.
2. Да. Но при этом УГО будет единое. Если хотите именно разные УГО, скачайте целл, который ранее выкладывал Uree. Но как по мне, это тоже не идеальное решение.

1. Не, тут немало Эксель помог. Сначала составил ряд номиналов для e24 и для е96, манипулируя ячейками, из этого ряда вытянул список парт номеров, расположил нужные колонки(свойства для part.ptf) в нужном порядке, и перенес их в птф файл. Если есть желание, могу и по подробнее этот процесс описать.
2. Изучил прошлые посты, и селл от Uree. Для каждого пэкаджа создал по паре пинов с уникальными названиями, и подцепил к ним символы(похоже что раньше тоже такие попытки делал). Может я что-то упустил? Все равно верификацию не проходит, ошибки те же: "пины 1,2,3,4 - не представлены в корпусе 5". Хотя это не мешает посмотреть на результат через ComponentBrowser, и увидеть разные УГО для разных пэкаджей. Может эти ошибки при верификации не так и критичны?

1. Да нет, мне просто показалось, что это экспорт из какой-то старой базы.
2. Внимательнее изучайте. Я там писал ровно об этом же. Это было одной из причин, по которым я отказался от такой организации. Ошибки при верификации могут вылезти боком значительно позже.

Ну у нас они так и не вылезли Но мы таким образом делали только разъемы, остальные компоненты делались стандартным образом, без всяких хитростей. А заморачиваться так с резисторами из-за черточек в них... имхо перебор. Хотя я уже писал об этом - DE HDL как по мне вообще перебор в качестве редактора схем, все реально необходимое можно делать в Capture. А в DE HDL сложностей больше, отдачи столько же, совместимость с остальным миром практически нулевая. Не стОит оно того...

с PAck_TYPE кое-как разобрался, возник еще один момент который просто поставил в тупик. Прочитав описание к этому маршруту, да и просто окинув взглядом project_manager, можно сделать вывод, что в него встроены инструменты для администрирования библиотеки. Кто-нибудь использовал встроенные возможности этого пакета для проверки(валидации) компонентов и библиотек?. А то создал я компонент, или библиотеку, пропустил его через ряд этих проверок (verify_rules, verify_package_flow), а это нигде не отобразилось. То есть я хочу спросить, почему можно использовать библиотеки и компоненты, которые не прошли все эти проверки, ? В мануалах я не смог найти понятное мне описание этого процесса. там написано про build и reference library, но какой смысл от этой reference-библиотеки, если она при создании сразу заполняется всяким мусором из build-библиотеки?

Кажется начинаю понимать. Cadence задумывали так, что "простые смертные" схемотехники(designers) не могут создавать reference Library (так же как и добавлять в нее новые компоненты). А библиотекарь обладает всей полнотой власти, и самостоятельно принимает решение - добавлять новый компонент в reference library или нет, уверен он в нем просто так, или эта уверенность основана на проведении всевозможных проверок и тестов (встроенных в маршрут). Т.е. проверки и check's - не являются неотъемлемой частью маршрута, а используются библиотекарем по усмотрению, я правильно понял? Ну и пока не смог разобраться с тем, что создав build библиотеку в Library Explorer(с лицензией Librarian), она (не утвержденная и не проверенная) тут же доступна для рисования схемы в DE HDL (без лицензии Librarian). - это же не правильно

Вообще эти библиотеки должны быть расположены в разных местах(на диске/в сети и т.п.). И только референс-библиотека должна быть подключена к маршруту создания схем/плат, а билд-библиотека должна быть локальным рабочим местом библиотекаря.

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

Но тут процедуру можете придумать сами, таким образом, как это будет удобно в вашем процессе разработки.

Уважаемый Uree, спасибо за пояснения. Т.е. это выглядит таким образом? На общем диске(в сети, или репозитории) лежит reference-библиотека(утвержденная). Дизайнер, начиная работу над новым проектом(при создании "нового проекта" в project_manager), руками прописывает в файле cds.lib путь к этой утвержденной библиотеке? Или проект создается в общем месте(в сети), файл cds.lib защищается от записи (и его может редактировать только библиотекарь, который опять руками прописывает в нем путь к reference-библиотеке)? как логичнее?
И еще один момент
Т.е. процедура утверждения подразумевала обязательное использование компонента в проекте? или достаточно просто присвоить компоненту "внутренний" партнамбер и экспортировать в референс-либу? Я понимаю, что все можно организовать на свой вкус, но хочется не наступать на грабли, на которые кто-то уже наступил, и перенять хороший опыт.

Защищать cds.lib не вижу смысла, когда сами либы уже защищены. У нас описание путей к либам обходилось несколькими строками и одной переменной окружения(насколько помню...), поэтому на любом компе в любом проекте cds.lib был идентичным.

Да, именно использование в проекте. Пока новый компонент не проходил проверку в работающей плате - не утверждался.
Т.е. процесс примерно выглядел так:
- создание новых компонентов
- проектирование ПП (пробные версии, инженерные)
- подтверждение "правильности" использованного компонента от инженера
- подтверждение нового компонента прокурментом(поставщик / кол-ва / приписание внутреннего партнамбера)
- апдейт библиотек
- проектирование ПП (пре-продакшн, на целевом производстве)
- подписи всех святых
- масс-продакшн.

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

Подниму старый вопрос по JEDEC_TYPE и PACK_TYPE.

Вопрос в общем простой. Как сделать чтобы в схематехническом редакторе Allegro Entry HDL отображался JEDEC_TYPE для компонента?

Простой пример.

Вот библиотечный символ диода.



Для него созданы несколько packages и 3 символа (ну это не важно допустим 1 символ).
Как видите из свойств кроме и NAME и $LOCATION ничего не введено.

Вот так выглядит этот символ при добавлении на схему



То есть, все прекрасно выбирается и показывает JEDEC_TYPE и PACK_TYPE.


Вот свойства символа установленного на на схему.


На схеме в свойствах видно свойство PACK_TYPE, хоть я об этом не просил но это хорошо.
Как сделать чтобы было видно свойство JEDEC_TYPE?
Сам я его указать в свойствах могу, но оно не будет переменным, оно будет как текст. Почему нельзя задать свойство символа которое автоматом бралось из chips.prt. Для PACK_TYPE он же это сделал автоматом.


Этот же вопрос, когда компонент имеет всего 1 package как задать поля JEDEC_TYPE и PACK_TYPE в свойствах символа которые будут заполняться автоматом из chips.prt. Я же задаю ему их в part developer, в чем проблема то?





Сообщение отредактировал spooki - May 1 2016, 12:26

Добрый день.
Подскажите а чем можно открыть структуру папок подобную присланной вами? Чтобы увидеть символы, посадочные места и таблицы и редактировать их.
PCB librarian открывает только файл библиотеки *.cpm

Заранее спасибо.