КБ "Схематика" открывает в тестовом режиме новый бесплатный сервис
для российских разработчиков печатных плат, осваивающих пакет САПР Cadence Allegro.

Если вы встретились с проблемой, решение которой не смогли найти
в системе помощи САПР и в предыдущих темах данного форума,
вы можете обратиться к нашему специалисту по Cadence Allegro по e-mail :

database
@schematica.ru


В письме необходимо изложить суть проблемы,
и при необходимости приложить скриншоты или BRD-файл.

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

Вероятно (надеюсь) для легальных и так есть техподдержка, и дополнительно их об этом информировать не нужно.

А вот для не легальных, ну например студент или аспирант, профессор в конце-концов, может на что рассчитывать?
А "коммерческий" не легальный пользователь?

Мы отвечаем на вопросы по возможностям пакета и особенностям интерфейса.
Например, если кто-то столкнулся с трудностями в реализации какой-то определенной операции,
подсказываем, "где искать кнопку". Чтобы человек не тратил полдня там, где
достаточно спросить у более опытного.
Или, например, кто-то выбирает САПР из нескольких вариантов и хочет понять
какие-то конкретные особенности Cadence Allegro - тоже можно задать вопрос.

Регистрация для пользования сервисом не требуется,
но желательно представляться, хотя и необязательно.

Вопросы нелегального использования софта не обсуждаются.

Для тех, кто приобрел пакет Cadence Allegro именно у компании PCB technology,
есть отдельный, более оперативный сервис технической поддержки -
по скайпу и телефону.

Забавно звучит:
Горячая линия по САПР Cadence Allegro, Онлайн-поддержка от КБ печатных плат "Схематика"




Как будто писали разные люди, имеющие разные цели...

Уважаемый Алексей,

Если Вас что-то смущает, не стесняйтесь, опишите суть своей проблемы подробнее.

Мы все разъясним.

Делаю проект в CIS 16.3-S018
Как сделать шину в иерархическом проекте?
И в блоках, и в корневой схеме шины Bus_name[0..15], такие же имена и у портов блоков. Уже все имена одинаковые, но в PCB Editor не соединяются.
Сигналы, выведенные в виде не шин, а одиночных сигналов, соединяются, а шины - нет.
В PCB Editor сигналы шин называются в виде Bus_name[15]_HB5 для сигналов одного блока и Bus_name[15]_HB6 для другого, одинаково называться почему-то не хотят. Что я делаю не так?

Вот фрагмент корневой схемы

вот фрагмент одного иерархического блока

вот фрагмент другого иерархического блока


ADC_ADC_D[0]_n не соединены
ADC_OR_n соединены

Я, правда, не PCB Tech, но отвечу.
1. Мне никогда не удавалось объединить в шину разноименные сигналы. Работают только имена вида ХХХХХХХ[0..15]. Цифры, понятно, любые требуемые.
2. Скобочки с цифрами должны быть последним элементом названия. Ваши _n могут не восприниматься.
Я не уверен, что п.2 требуется обязательно.

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

Пользуйте 16.5 - там реализован механизм объединения, несколько специфически - но вроде работает.
(На текущем проекте не пробовал, по понятным причинам)

Выдержка из OrCAD Capture User Guide

To make connections to a bus, you label the bus, label the
signals that are members of the bus, and assign an alias to
each signal entering and leaving the bus. Each signal bears
an alias that is within the bus range. For example, if the busalias is ADDR[0..3], the four bus members must bear aliases
ADDR0, ADDR1, ADDR2, and ADDR3.

Take the example of the following alias name prefix and
number range:
AD [9-0]
The net aliases will be named AD9, AD8, AD7 through to
AD0.

Naming conventions for a bus

A bus name must have the form basename[x..y] where x..y
specifies a range of decimal integers representing the signal
numbers of bus members. There are (y - x + 1) wires in the
bus. You can use two periods (..), a colon (, or a dash (-)
between m and n.

Examples:
ADDR[0..31] (32 members)
DATA[16:31] (16 members)
CONTROL[4-1] (4 members)
A[100..190] (91 members)

Do not add any space between the basename and the left
bracket ([), as this can cause problems during the netlist
operations.
Also, note that you should not end a bus name with a numeric
character (0-9), as this can cause problems during the netlist
operations. Numeric characters can occur in other places in
the bus name, however. For example, BUS2A will work, but
BUSA2 could cause problems when you generate the netlist.

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

по Вашему совету получилось сделать так:

• убрал квадратные скобки в именах цепей Bus_name[N] -> Bus_nameN
• убрал имя цепи после номера Bus_name[0..N]_p -> Bus_name_p[0..N]
• разделил шины:
  

  Bus_name_n[0..N],Bus_name_p[0..N] ->
  

  Bus_name_n[0..N]
  Bus_name_p[0..N]
  

объединить шины у меня тоже не получилось
когда _n на конце, в netlist к шине добавляется имя иерархического блока, соединить иерархические блоки у меня не получилось

Всем спасибо!

Я предлагаю использовать все таки OffPageConnector.

Надо бы так, чтобы можно было блок размножить

Не могли бы вы прислать мне проект по e-mail для решения вопроса

Спасибо,
у меня этот вопрос, можно сказать, что решился.
По крайней мере в том виде, в каком я описал в посте от Jun 28 2011, 02:10

Доброго времени. Вопрос такой - можно ли в Design Entry CIS сделать так, чтобы отображались метрические значения координат (правый нижний угол) для схем и для Parts? И тот же вопрос по OrCAD Capture... Следующий вопрос - возможно ли работать в схемных редакторах в шаге 2.5 мм, 1.25 мм и т.д.?

Можно сделать шаг сетки 1/2 или 1/5 от шага выводов.
Шаг выводов можно сделать 5 мм.
Метрические значения координат отображаются при вводе соответствующих настроек
при создании нового дизайна.
Сделать компонент с шагом выводов, кратным 2.5 мм, тоже можно, но не средствами Design Entry CIS,
а средствами отдельной утилиты. Впрочем, лучше так не поступать.

См. прилагаемые скриншоты с иллюстрациями.

С уважением,
Александр Акулин

Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла
Нажмите для просмотра прикрепленного файла

Спасибо. Я так понял в Parts редакторе символов - условные единицы (еквивал. дюймам), которые трансформируются потом в схеме с использованием коэффициента при установке выбора единиц измерений (мм или дюймов). Чтобы получить круглые значения шага выводов в самой схеме надо установить этот коэфф. равным 2.54 (при 1.27 измениться масштаб символов вдвое (уменьшится) и т.д.).

Извините за простой вопрос - но он уже убил день.

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

Очень было бы странно перерисовывать компонент с нуля!

Спасибо

В режиме удаления всё получается - сначала включить CTRL+D, потом проверить установлены ли Pins на закладке Find.
Видео делать не умею, но открыл компонент и проверил - все работает.

Спасибо.
Первый проект в Алегро, дело было в фильтре - все не привыкну.

Подскажите пожалуйста как заполняется ,Part Table File .ptf, файл, копи паст не работает, а в ручную набирать нереально, у меня есть файл сделанный в экселе с данными применяемых компонентов... Может есть какие-то специализированные средства!?

Самое простое и удобное средство - хороший текстовый редактор. Лично я использую Notepad++.
Создайте файл непосредственно в Part Manager, закройте не редактируя(он правильно создаст начало-конец-имя_парта в файле, а если перечень атрибутов задан в сэтапе то и их список сразу вставит), а потом открывайте редактором и вперед.
Из экселя можно сразу копи-пастом в Нотпад втягивать, только потом лучше ТАВ-ы заменить пробелами. Уже не помню какая проблема, но что-то не то было с ТАВ-ами в ПТФ-е.

Огромное спасибо, что откликнулись и помогли. Вообщем немного помучавшись, что-то у меня получилось, но такой метод работы с системой мне не по душе и решил я завязать с Cadence.
При переходе на новую систему проектирования для меня было самым важным умение этой системы работать с ADS и AWR. Поработав недельку с Mentor Graphics путь (DxD-Exp) я понял что наконец-то выбрал лучшую и оптимальную, для себя, систему. Спасибо за помощь, ухожу в соседнюю ветку.

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

Да действительно, Вы совершенно правы возможности Allegro PCB ни в чём не уступают, а может и превосходят конкурентов по удобству и возможностям использования.Значит будем использовать оба продукта. В Cadence не понравился схемный ввод и библиотекарь, в Менторе на мой взгляд удобней. Но вот вопрос, использование лицензионного программного обеспечения всётаки заставит сделать выбор того или иного продукта, две лицензии это уж слишком... Ну да ладно, это уже не по теме... Спасибо за помощь!

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

Скажите, пожалуйста, как сделать видимыми номера выводов при создании компонентов?

На вкладке options включить видимость package_geometry pin_number

Спасибо

В Layot после создания так называемых obstacles (рисунка шелкографии, outline и т.д.) возможно было их редактировать, перемещая отдельные сегменты относительно друг друга (это делалось при нажатой кнопке S). Скажите, пожалуйста, возможно ли и в PCB Design также оперировать отдельными сегментами, а не всем контуром сразу?

add vertex - контур можно изменить в любой точке. Потом можно двигать отдельные сегменты при включенном фильтре other segs.

Спасибо

При редактировании REF DES я хочу изменить ширину линии шрифта. Для этого в options я изменяю параметр ширина линии (Line Width), однако визуально не наблюдаю никаких изменений (утолщение ширины линии в редакторе не происходит). Скажите, пожалуйста, что я неправильно делаю?

В каком именно редакторе?

ЗЫ Если речь о РСВ, то менять нужно свойства блока текста:

Нажмите для просмотра прикрепленного файла

а потом, если необходимо, менять номер блока(стиля) текста на выбранных рефдезах(меню Edit -> Change):

Нажмите для просмотра прикрепленного файла

Pcb Editor

Спасибо. Я ступил , полез зачем-то в options. Хотя,интересно, на что именно воздействует параметр Line Width.

Этот параметр меняет именно ширину линий, отдельных линий, не в составе текста.

Понятно!

У меня есть библиотека фотопринтов в формате LLB (Layout). Скажите, пожалуйста, можно ли её как-нибудь транслировать в фотопринты формата PCB Editor (psm или dra)?

Да. Но делается это довольно извращенным путем. Сначала Вы открываете Layout в режиме lsession, и там в какой-то менюшке, забыл как называется (вроде Options), вторая справа, кажется, Находите подменю Create Part Catalog. После чего нужно будет выбрать библиотеку (LLB), и Layout создаст проект (MAX), в котором все футпринты библиотеки. Затем Вы открываете PCB Editor и создаете проект новой платы, после чего вызываете команду File->Import->Orcad Layout и втаскиваете проект в PCB Editor. Далее, делаете File->Export->Libraries... и выбираете, что и куда сохранять. В указанном каталоге как раз и получите кучу psm и dra.

Добрый день!
Возникла загвоздка при создании package symbol, а может дело в чём то другом. Помогите разобраться!
Получил схему от разработчика, выполненную в OrCad. Наши базы элементов не объедены поэтому столбец PCB Footprint заполнил руками. При импорте в Board всплыли ошибки связанные с тем, что разработчики используют не все выводы микросхем. Вот здесь и заключается загвоздка. Аллегро у нас не давно, база элементов только создаётся. Для уменьшения базы, элементы называются по типу корпуса. На данный момент, для устранения описанных выше ошибок, создаётся новый package symbol в котором неиспользуемые, в данной схеме, pin'ы меняются на механические. Таким образом проблема решается, но в базе появляются элементы с именами, например, SO-8 (оригинал) и его "уродцы" SO-8_2_7 (что означает, что выводы 2 и 7 механические).
Помогите разобраться, может быть есть ещё какой нибудь способ устранения данных ошибок?

И если позволите ещё один маленький вопрос! Элементы создаём в package symbol, но может быть в аллегро есть утилита для создания Footprint, наподобие Pattern Editor у P-Cad'а?

Немного не так это делается. Корпус должен быть один, а неиспользованные пины нужно на уровне схемы описать как not connected(NC):

Нажмите для просмотра прикрепленного файла

Аналогичным образом можно описывать выводы питания, когда их очень много, либо какие-нибудь пины заземления разъемов, которые не хочется показывать на схеме - посмотрите хелп, раздел "Using Capture with PCB Editor" и в нем "Assigning properties in Capture for use in PCB Editor". Там расписано как можно определять NC и Power пины.

Никакой дополнительной утилиты для создания футпринтов в Аллегро нет. Все необходимое уже есть в PCB Editor-e. Если Вам хочется визарда для создания, то это другое дело - при создании нового файла выберите опцию Package symbol(Wizard) - получите визард для быстрого создания футпринта. Всего в нем не сделаешь, но стандартные корпуса и все для них необходимое там предусмотрено.

Спасибо! Но помогло только от части. Разработчики упёрлись, что не станут в УГО вводить выводы, если в справочных материалах к микросхеме они указаны как не используемые. Почитаю ветки, что там народ пишет =)

P.S. Uree на изображении, в строке PCB Footprint, записан элемент с большим количеством символов в названии... Подскажите пожалуйста где можно указать количество допустимых символов? У нас, при импортировании в Board, выдаёт ошибку, если количество символов превышает 17 знаков. При этом он считает и символы PCB Footprint и символы Name.

Так в том и дело, что описание пинов через NC позволяет не рисовать их в символе. Собственно для того и придумано. Получается есть пины на символе, используемые(могут быть не подключены), есть пины в корпусе(этих больше), а разницу между ними описываем как NC. Тогда они в пэкейдже тоже описаны как NC и аллегро "кушает" такой пэкейдж не поперхнувшись, потому как у него все совпадает: кол-во_пинов_на_символе + кол-во_пинов_NC = кол-во_пинов_футпринта.
Нумерация естественно тоже должна совпадать, т.е. пин может быть либо на символе, либо описан как NC. Двойное описание - ошибка, схема не упакуется.

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

Нажмите для просмотра прикрепленного файла

- установка длины имен в самом PCB Editor-e:

Нажмите для просмотра прикрепленного файла

ХМ! ????? NC - это не No pin connect? Просто строки NC у меня нет, но во вкладке пин (таблицы свойств элемента) есть No pin connect, в которой, при установки галочки соответствующему пину, вывод на УГО помечается как неиспользуемый (аналог клавиши Х). Но в данном случае вывод обязательно должен присутствовать на УГО. По тому как описываете Вы, насколько я понял, идёт просто перечисление выводов, которые помечаются как NC, при этом они могут быть не указаны на УГО?

А это не их, пардон, собачье дело, ИМХО, используются выводы или не используются. В документации производителя вывод присутствует? Да, присутствует. Тогда - рисуй и не умничай.

Пример из недавней практики. Работал с GSM-модулем. В одной ревизии доки пара выводов обозначались как NC, в более поздней у них появились какие-то описания. Да, это дела служебные и, скорее всего, пользователю никогда не понадобятся. А если все-таки понадобятся?

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

Теперь вообще непонятно - то Вам нужно было рещить проблему с пинами, которых НЕТ на схеме, но присутствуют в футпринте. Это решается через атрибут NC(No Connect), который нужно добавить как атрибут компонента и сделать это можно непосредственно на схеме:

Нажмите для просмотра прикрепленного файла

Теперь Вы пишите, что вывод обязательно должен присутствовать на УГО. Если на УГО присутствуют ВСЕ выводы, то никаких проблем при упаковке схемы быть в принципе не может.
Еще раз - описание пинов через атрибут NC позволяет не рисовать на УГО ненужные пины:

2 Tahoe

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

Нажмите для просмотра прикрепленного файла

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


Хотя приведенный пример не типичен, а скорее исключение, но все равно, отобразил бы все пины, разумеется. Вопрос только в том, как именно. В данном случае, создал бы гетерогенный part, в одну из частей которого отправил все NC.

Нда... знаете, когда-то УГО для больших компонентов в BGA тоже пытались нарисовать единым целым. Со всеми сотнями его ног. Как думаете, почему отказались от такого подхода?
Кстати на многие компоненты производитель не приводит изображение УГО. Рисуйте как хотите. Что будет делать такой разработчик в этом случае?

Сравнивать теплое с мягким не есть правильно. Я же не случайно оговорил, что в приведенном примере, УГО будет создано, как гетерогенное. Думаю, понятно, почему.


Не имеет значения, в каком виде предоставлено описание. В виде картинки, в виде текста или ещё как-то. В любой документации на компонент будут описаны все пины. В этом смысле, описание "NC" ничем не отличается от описания "VCC".

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

Кстати. Есть отличный пример, к чему приводит подход "не отображать все пины". Если пробежаться по форуму FPGA > Altera, то любимое развлечение там "не прошивается Циклон в QFP корпусе". Затем выясняется, что практически во всех этих случаях, "забыли" exposed pad на землю посадить. Ну и далее весь букет - деньги за многослойку заплачены, времени в обрез, заказано сразу стопицот экземпляров... Это прямое следствие того, что кто-то, когда-то поумничал/поленился/сэкономил и не отобразил пин в УГО.

Если не обращать внимания на манеру изложения Tahoe, то в реальности вопрос, что отображать, а что нет, должен решать разработчик, ибо он рисует схему и отвечает за соединения цепей.
Если он решил, что чего-то рисовать не надо, значит, так и надо.
Другое дело, что легко ошибиться.
От ошибок же страховаться можно по-разному.
Можно создать набор правил, пользоваться проверкой DRC в схематике и процессами (формализованными последовательностями) проверки схем.
А можно и тупо лепить все выводы на УГО, загромождая схему по самое "не могу".
Выбор каждый делает сам в соответствии с уровнем культуры разработки...