ATname

Может кто в курсе этого: http://www.mspnews.com/news/2012/04/19/6269621.htm. И судя по анонсу на сайте ментора это первый подобный пакет из большой тройки (двух с половиной) Каденс/Синопсис/Ментор у кого пакет поддерживает многопроцессорные системы. Типа не так сильно будет отставать от конкурентов в плане быстродействия.

Во-первых, код не мой. Во-вторых, "детские ошибки" всего лишь иллюстрация "простой истины": наличие в кристаллах Xilinx специализированных ресурсов для сигналов синхронизации (клоковых ресурсов) НИЧЕГО НЕ ГАРАНТИРУЕТ! НЕТ НИКАКИХ способов ЖЕСТКО гарантировать трассировку сигналов клока по клоковым ресурсам в кристалле. Есть только надежда на то, что если удастся угадать (не больше, ни меньше) по каким критериям и как именно ту или иную языковую конструкцию синтезатор интерпретирует, то есть надежда, что сигнал будет тарссироваться по клоковым ресурсам. Вот этим самым: см. ug331.pdf стр.47 рис 2-2, если кто не понимает, о чем идет речь. Контролировать этот процесс явно (вплоть до выдачи синтезатором предупреждений или ошибок) такого инструмента (прямого действия) у разработчика нет. И в этом аспекте, подключать клоковые сигналы на контакты, специально выделенные для этих целей производителем кристалла - только лишняя головная боль. От которой, тем не менее, никуда не деться. Постить прописные истины (с целью потешить собственное самолюбие), оно конечно проще, чем отвечать на неудобные вопросы, смысл которых, еще и не всегда ясен для отдельных "знатоков". P.S. Если бы Вы соизволили внимательно прочитать прикрепленный отчет сиснтезатора, то вопросов о "перегрузке" клоковых ресурсов в Вашем посте не последовало. Ресурсов этих там более чем.

Многоуважаемый сэр! Упомянутые Вами документы мне известны. Как и используемый в проекте тип FPGA. А вынесенный на рассмотрение вопрос возник из процесса переноса ранее (успешно) реализованного проекта в иную (более старшую) версию ISE. И из всей этой "бадяги" можно сделать одно заключение. В обход ограничений проекта XST по своему разумению, в силу своих алгоритмов оптимизации процесса синтеза, может создавать специфические сигналы (в данном случае сигнал синхронизации) который ему не задавали. В данном случае XST подсунул в проект, то чего в нем раньше (в более младшей версии ISE) НЕ БЫЛО! И перегрузил ресурсы глобального клока, вчистую развалив работающий (в более младшей версии ISE) проект. Из Ваших содержательных ответов видно, что как бороться с этим явлением Вам неизвестно. Не сомневаюсь, что Вы истинный виртуоз в программирования на HDL, чего нам, за ...дцать лет работы в отрасли, достичь не довелось. P.S. Если Вас посылают... читать документацию, то главное в этом процессе это то, что Вас послали. А куда и зачем, значения не имеет.

Вы пропустили самое главное, вот это: "Заковыка как раз в том, что в данном отчете, в разделе "Clock Information:", нет сигнала cpu_ncs0...". То, что Вы так старательно описали, понятно и без столь пространных объяснений. Тут интересно другое: почему сигнал подключенный к контакту глобального клока (cpu_ncs0, а также и cpu_ncs1, не упомянутый XST вовсе) и имеющий (согласно кода) практически такой же путь прохождения как и cpu_nwe, клоковым не является (по мнению XST). Заметьте, что именно XST определяет кому быть клоковым сигналом, а кому нет. Ну и за каким тогда вообще нужно выделять клоковые контакты и специальные трассировочные ресурсы глобального клока, если работающий по непонятным критериям XST выделяет клоковый сигнал согласно своим алгоритмам оптимизации? Тут более глобальный вопрос: как заставить ISE тарссировать нужные мне сигналы именно по клоковым ресурсам, без "сюрпризов" со стороны ISE в стиле мелкогософта: типа нам лучше знать, что для вас лучше.

Тот факт, что "...Сигнал, которым тактируется хотя бы один тактовый вход, считается clock'ом..." я понимаю. Вопрос гораааааааздо интересней. В приведенном отчете сигнал cpu_nwe как раз и является тем самым сигналом, который не подключен к контакту глобального клока, но определен XST как клоковый. Заковыка как раз в том, что в данном отчете, в разделе "Clock Information:", нет сигнала cpu_ncs0, который, как раз в перечне клоковых редактора ограничений, стоит в полный рост. Наряду с имеющимися в отчете cpu_nwe и fpga_clk. И что с этим делать? Main.rar

Суть явления в следующем. Исходный код проекта VHDL, арибуты сигналов отсутствуют как класс. Файл *.UCF содержит только привязку к контактам (LOC and ect.) Файла *.XCF нет в принципе. И тем не менее XilinxISE (XST) умудряется часть сигналов определить как сигналы синхронизации, что видно в редакторе ограничений. Т.е. в соотвествтующем окне есть определенный набор сигналов. Вопрос: откуда сабж взял, что именно эти сигналы являются сигналами синхронизации? Что характерно, один из таких сигналов даже близко не подключен к контактам глобального клока...

При запуске PA он автоматически (в фоновом режиме) грузит Project Manager XilinxISE и работает через него. См. доку на PA.

Глицерин-гидрозин энд спирто-канифоль под корпус QFN это сильно! Плата протянет не более считанных недель. Проверенно. Особенно глицерин-гидрозиновая зараза порадовала. ИК станцией паять надо, с соответствующими расходными. Феном сдует все вокруг...

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

Собственно если не ориентироваться на "рекламные" выкладки упомянутые выше в изрядном количестве, то есть два главных отличия Expedition от PADS. 1. Expedition позволяет "развалить" разводку одной платы (разных её частей) на разные машины. Свойство используется как для корпоративной разработки, когда разные части одной платы делают разные разработчики, так и для ускорения разводки одной платы. 2. В Expedition есть возможность использования встроенных в плату (в структуру печатной платы) компонентов (резисторы, конденсаторы, индуктивности). Есть ещё и третье (на мой взгляд малозначительное) отличие: PADS лучше и быстрее выполняет трассировку на малом (2-4) числе слоев, Expedition на большем числе (опять же за счет параллельной работы нескольких машин). Объясню почему сие отличие малозначительно. В реальной жизни платы такого уровня сложности (где можно это уловить) встречаются крайне редко, поскольку для создания (разработки) подобных плат надо иметь и разработчика (*ов) соответствующей квалификации, это раз. Второе: а где вы (ваше предприятие) такую плату будете реально изготавливать? Вопрос отнюдь не праздный в российских реалиях... да и для почувствовать эту самую разницу в разводке надо иметь квалификацию отнюдь не начинающего юзера, а это дело опыта (читай времени). Что касается передачи разработки за рубеж, то выдать плату в формате Expedition из PADS проблем нет, есть конвертеры Ментора. Что касаемо "все работают в Expedition" то позвольте не позволить. Например эволюшин на BF538 от Analog Devices (далеко не простая штука) идет в PADS. Да и с точки зрения "всеядности" и возможности миграции с разных CAD'ов PADS на порядок более предпочтительней Expedition. Выбор последнего в качестве основного продукта оправдан исключительно для корпоративного сектора при наличии высококлассной команды разработчиков, но в условиях РФ - это фантастика.

ОТветы на Ваши вопросы: "Неправильную" форму "шарик" на рентгеновской засветке иметь не может по определению (в случае непропая). Степень засветки определяется прозрачностью для рентгеновских лучей препятствия на их пути. В данном случае это КОНТАКТ КОРПУСА BGA. И никаких "сидит в центре шарика" там быть не может ибо рентгеновское поглощение контакта и припоя одинаково. Если контакт BGA не запаян, то в этом случае силой поверхностного натяжения весь припой собирается на контакте BGA ибо адгезия припоя к материалу контакта на несколько порядков выше адгезии к материалу ПП (химсостав припоя и контакта BGA практически идентичны, с точки зрения физики процесса пайки). Откуда Вы взяли про "поясок вокруг контакта", для меня загадка, которая к практике рентгеновского контроля никакого отношения не имеет. Зато есть оптические методы контроля, где действительно ориентируются на показатели схожие с "пояском вокруг контакта". Но это древний способ, сейчас применяют лазерные методы контроля по форме кривой остывания контакта при его зондировании калиброванным тепловым воздействием (импульсом калиброванной мощности нагрева). Этот способ более точен (определяет наличие скрытых пустот, не обнаруживаемых рентгеновским контролем), но более дорог. Форму контакта ПП изменяют специально для того чтобы при пайке видеть именно изменение формы засветки отличной от формы контакта корпуса. Оптимальной (с технологической точки зрения), для этого, как раз и является форма капли с параметрами указанными в файле (т.е. удлинение на 1/2 от диаметра контакта). Вообще, капли на контактах SMD (и не только) микросхем делают совсем для других целей. Есть такая штука при изготовлении ПП, которая называется застой кислоты. Этому эффекту наиболее подвержены углы. Особенно углы при входе связи в контактную площадку. Вот для нейтрализации этого эффекта, который особенно опасен на платах класса 5+ (где ширина трассы 75 мкм и менее), и применяют каплю на контакте. Или если у изготовителя совсем древняя технология травления, что в РФ тоже имеет место быть.

Мнение профессионалов изложено на стр.86. Резать файл не стал, там ещё много полезного для заинтересованной публики. Seminar_PCBtech_061215.pdf

Если контакт ПП в форме капли, то при рентген-контроле сразу видно есть пайка контакта или её там нет. Судят об этом по затемнению места пайки - в случае нормальной пайки затемнение в форме капли, а при отсутствии пайки затеняется только сам контакт BGA (т.е. тень в форме шарика).

Это все замечательно, только проблема в том, что мне необходима капля ТОЛЬКО у контакта BGA, а опция Generate Teardrops создает каплю и на другом конце связи. Сие приводит к тому, что для фонаутов BGA формируется капля у переходного отверстия, а мне её там не надо. Контролировать пайку в этом месте нет надобности, поскольку ее там нет.

Господа, кто в курсе как сделать каплю в PADS на контакте BGA для ренгенконтроля пайки? Заранее спасибо.