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

Спасибо, Александр
У Вас в обоих маршрутах результат правильный.
У меня в обоих неправильный.
Буду разбираться. Может кто-нибудь ещё сообщит о своих результатах.

Разобрался!
Оказывается надо было в поле "configure>preferences>advenced" выбрать %.16f вместо стоящих по умолчанию %.10f
Всем спасибо

А у меня там стоит %g (уж и не помню, само или ставил)


Tip: If you are unable to find a
property value in DxDataBook
using search or verify, type %g
into the Fraction Format menu
text field (ensures that numerical
data in the relational database is
set to the appropriate fractional
format and numerical values are
not rounded).

Спрошу и я в этой теме, т.к. тоже по DxD. (EE791)
Cуществует атрибут Global Signal Name (NETNAME). Он назначается символу. А возможно ли назначение подобного атрибута отдельным пинам? К примеру есть интерфейсный разъём (с собственным, отдельным символом разумеется), на котором имена цепей всегда однозначно определены. Можно ли исхитриться так, чтобы подключаемые к этому разъёму цепи автоматически получали некое предустановленное значение?

Это атрибут SIGNAL=<имя>;<список номеров пинов> очевидно (на символе).

Боюсь что нет.
Но можно реализовать по другому - при размещении этого символа на схему включите галочки Add_Nets и Add_Net_Names - в результате к пинам добавятся отрезки цепей с именами взятыми из имен пинов. Подключая новые цепи к этим отрезкам вы получите и эти имена для полных цепей.

Предложенный способ с атрибутом SIGNAL в данном случае не применим, т.к. он используется для неявно заданных пинов (а у вас как я понял они как раз явные - т.е. есть на символе) + данный атрибут не используется в маршруте iCDB.

Не работает. Это немного другое.


Да! Получилась такая последовательность:
- символ нужен с именованными пинами, т.е. специально подготовленный. Что впрочем для стандартных интерфейсов вполне приемлемо.
- плюхнуть на схему символ с указанными галочками
- загрузить его (или как там правильно по терминологии?) в DxDB
- аннотировать атрибуты из DxDB в схему
- удивиться, как быстро получилось именовать три-четыре дюжины (а то и больше!) проводников

Спасибо за советы!!!

ЭЭЭ, а что мешает сразу из DxDB ставить, с тем же результатом?

хмм, "буратино был тупой" (С) песенка )) во вкладках Part View и Symbol View галочки "Add Nets" и "Add Net Names" нашел, а во вкладке DxDB кнопочки "N" и "L" потоптать не догадался!

Господа-товарищи, друзья и коллеги!

Вопрос по ЦЕС.

Постановка проблемы.
Есть две микрухи, соединенные двумя цепями через резисторы друг с другом, дополнительно две эти цепи соединены между собой через конденсатор (типовый РЦ-фильтр с выхода ОУ на вход АЦП).
Оказалось, что при таком включении ЦЕС объединяет все четыре эти физических цепи в ОДНУ электрическую, при этом не дает объединить никакую из двух входящих пар физ. цепей в одну дифф. связь (слайды ниже).
Если кондер убрать (или вместо него включить резистор, например), эта эл. цепь естественным образом разывается на две эл. цепи и ЦЕС уже дает создать диф. пару на базе любой пары физ. цепей (слайды ниже).

Вопрос: what's собственно up???

Note: пассивуха выполнена в ЦБ типом "Misc".

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

Откуда такая дискриминация по конденсаторному признаку??!!1

дай картинку из CES_Setup_Setting_DesignConfiguration_Discrete.......

В CES закладка Parts, снимите галочку Series у конденсатора.

В данном случае CES понимает что резистор может служить (по теории) параллельным согласованием диф. пары, а вот конденсатор нет

Фредерик, картинку не прилагаю, потому что...



И это фантастика, потому что это работает! Ни за что бы сам не догадался. Благодарствую.

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

Ещё. Может кому пригодится.
От компа был отлучён второй монитор (вместе с двухголовой видяхой). И на нём осталось окно OutputLogControl. Никакими штатными средствами у меня не получилось выцепить его в видимую область основного экрана. Пришлось грохнуть файлик DxDesigner.wsp в каталоге, указанном во wdir. После чего спрятавшееся окно появилось, а файл возродился аки Феникс. Естественно настройки расположения окон - тю-тю.

Есть вопрос к опытным пользователям пакета - есть ли смысл делать проект изначально сетевым и работать с ним через сеть, если над его созданием будут работать несколько человек? К чему может привести нестабильность в работе сети?
Либо все же проще передавать файлы проекта друг другу и затем отслеживать в них изменения? Дело в том, что "поимев" опыт с открытием чужих проектов у себя на рабочей машине, я понял, что прелести в этом нет никакой))

и как Вы это собираетесь делать в iCDB?

Эм..что вы имеете ввиду?)
Вы хотите сказать, что невозможно будет передать целостный проект на другую машину с тем, чтобы потом работать в нем в режиме прямой/обратной аннотации? Импорт в Foreign Database не для этого существует?
Я потому и спрашиваю, что этот вопрос для меня - темный лес. У меня был опыт только в открытии чужих проектов у себя на машине, изменить и аннотировать я их не мог поскольку как правило для них отсутствовала ЦБ.

1. Foreign Database создавалась для людей которые работают "оторвано друг от друга". Т.е. например схемотехник и тополог находятся в разных сетках и не имеют общедоступного для них обоих места.
2. Если в схему ( а значит и плату) не надо добавлять новые (т.е. подобных нет в этом проекте) компоненты. То схему\плату можно изменять, т.к. локальная библиотека платы содержит все нужные для аннотаций компоненты. Т.е. можете подключить любую ЦБ только для того чтобы "система больше не спрашивала".
3. Проблем с общим проектом (т.е. лежащем в общедоступном месте) быть не должно. Но при организации таких проектов (как впрочем и проектов "копируемых") нужно задуматься о правильности организации путей. Если путь с разных машин одинаков, то и проблем нет (ни в том ни в другом случае).
Организовать это можно разными способами.
Самый продвинутый способ - использовать переменные окружения в пути, тогда:
- на каждом месте достаточно определить в переменной жесткий путь (возможно, разный на каждой машине) и проект работоспособен
- при перемещении проекта в другое место, опять же достаточно изменить жесткий путь в переменной, а не править во множестве мест в проекте.

Наберите в хелпе поиск по LOCATION MAP и увидите подробное описание.

Спасибо, сейчас буду разбираться. В принципе вариант с тем, чтобы задать одинаковый путь при организации проекта заманчив)) Однако нужно изучить все варианты.

Если при работе с проектом по сети внезапно она "легла", чем это может быть чревато кроме потери несохраненных данных?

Вопрос в догонку - насколько я понял, дабы разрешить конфликт путей, мне нужно указать единственную переменную в файле locmap.cfg? Скажем, я скопировал сделанный на др машине проект себе в папку D:\Work\new_editing_project - мне нужно указать именно этот путь в качестве значения некой переменной?

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

Да.

Прекрасно, спасибо)

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

Нет-нет, все не настолько интерактивно)) вариант fill'а гораздо ближе к истинному положению вещей))

а у меня обратный вопрос - как включить эту галочку у серийного резюка. ДхД не принял что он серийный (refdes - RN**)
В CES пытаюсь указать (setup-settings-discrete component prefixes) что RN относится к классу резисторов. Жму ОК, окно закрывается, изменения не сохраняются. Ну и любые другие изменения в этом окошке замечать не хочет

Определите последовательность соединений внутри рез. сборки.

Задал следующие пути в файле locmap.cfg
Path=D:\WORK\6112\61150403100\Lib\
Project_File=D:\WORK\6112\61150403100\Project\
Layout_Template=D:\WORK\6112\61150403100\Lib\LayoutTemplates\4 Layer Template\
Configuration_File=D:\WORK\6112\61150403100\Project\

Тем не менее чужой проект открыть не смог, DxD все так же ругается на чужой путь при открытии документа. С одной переменной произвольного вида тоже ничего не получилось. Пришлось по старинке перебить пути руками в самих файлах. Что делаю не так?

поясните пожалуйста, что имелось ввиду? Pin mapping в центральной библиотеке? Сейчас сборка разбита на элементарные резисторы, каждый из которых обозначен гейтом.

см.

Объясняю популярно.
Например:
У меня есть папка с проектами:
С:\mentor\designs
есть папка с ЦБ
С:\mentor\libs
Через Dashboard меню Tools > Manage Location Map (в нем проще т.к. можно использовать ГИП с проводником) я создал файл locmap.cfg ( и сохранил его в первой папке прописанной в WDIR) в котором задал переменные:
designs=С:\mentor\designs
libs=С:\mentor\libs
выше показан вид как внутри файла, если вводите\изменяете в диалоге Manage Location Map, то перед переменными надо добавить $

Создавая новый проект (test_project) я ввожу пути к проекту и ЦБ через переменные:
$designs\test_project
$libs\my_lib.lmc

Теперь, если я перемещаю проект(ы) и\или ЦБ в другое место, я просто изменю пути в файле locmap.cfg и DxD их найдет.

Фредерик, опция Edit -> Pin Pairs -> Add Pin Pairs... неактивна при выборе резисторной сборки во вкладке Parts.

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

как вижу по картинке ты делаешьв DxD
сделай упаковку и FA, и пробуй в Ехр

Ты имеешь в виду открыть ЦЕС из Экспедишна? Попробовал так, картинка та же самая.

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

моя привычка работать в CES из Ехр
стань на компанент
правая клавиша мышки
выбери Greate Pin Pairs

Ничего не выходит.


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


Прожект выложить?

В новом проекте все работает.
Settings->Discrete Component Prefixes прописывается RN, появляется галочка Series во вкладке Parts напротив сборки, становится активной опция Create Pin Pairs, после чего все физ. цепи включаются в состав общей эл. цепи и она разводица. В исходном большом проекте пока вообще нельзя сохранить произвольный префикс в настройках. Разбираемся.

Вот такая картина префиксов рефдесов CES->Setup->Settings->Discrete Component Prefixes в реальном проекте:

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

Префиксы с буквой "А", видимо, связаны с тем, что в проекте используются реюзаблы с префиксами А. Но почему в таком странном виде: A2A1, A1A2 и т.п. И почему нельзя внести никакие изменения в эти настройки? Они тупо не сохраняются...

Выложите Проект+ЦБ - для разбирательства.

Разобрался.

Во-1-х, ибо сказано:

You can only modify discrete component prefixes when in a CES session launched from the front-end (i.e. schematic capture), or standalone CES.

Т.е., редактировать данные поля префиксов можно только лишь вызвав ЦЕС из ДхД либо ЦЕС как таковой (не из Экспа).

Во-2-х, при попытке править какое-либо поле префиксов (даже если ЦЕС был вызван из ДхД), в окне Output появлялось следующий ворнинг:
The discrete component prefixes may not contain any of the following characters: space, ~!@$%^&*()+`1234567890-=
Т.е., сама система прописала эту хрень в префиксы и сама же на нее ругается. Скорее всего, ругается на цифры в составных рефдесах.
Короче, проблемы решилась полным удалением всей этой хрени и прописыванием с нуля всех префиксов рефдесов (без префиксов функциональных повторяющихся блоков A1, A2 и т.д., как система сама пыталась это сделать) - С, VD, R, RN и т.д. В итоге после нажатия ОК ЦЕС перегенерил электрические цепи, появились галки Series напротив резисторных сборок и стало возможным назначить пары пинов. Все работает.

Да здравствует напильник.

Выкладываю тестовый проект, потому что с данным повторяющимся блоком проблема повторяется. Независимо от префиксов реюзаблов система прописывает в ЦЕС хрень типа A1A2C, A2A1R и т.д. Хотелось бы понять, откуда рога торчат.

Note: проблема вылазит только с данным реюзаблом, с другим - гораздо реже, почти никогда.

Измените префикс B9 на блоке на просто 9. И в префиксах дискретов добавьте #C и #R и т.п.
Возможные вариации префиксов блоков например:
BA BC BD и т.д
1 2 3 и т.д
Но не смесь букв и цифр, которая и приводит к проблеме распознавания. Естественно, количество букв (или цифр) может быть и большим, например BLOCK_A BLOCK_B и т.п.
Нажмите для просмотра прикрепленного файла

Разработчики закладывались на вариант:
Rule: When your design uses reference designators that are of the format YYYRNN (i.e. schematic sheet, reference designator prefix, unique instance), append a # to each discrete component prefix that you define here. For example, instead of using just C to define the discrete component prefix for capacitors, use #C.

Товарищи, подскажите такую вещь:
Начал разбираться, как "работают" Reusable Block в DxD-Exp 7.9.1upd10. Всё бы хорошо, но когда в DxD добавляю в в схеме блока к именованной цепи иерархический пин, то ему присваивается имя. И это имя (атрибут Name) располагается слева вверху над символом. Как отредактировать символ пина, чтобы имя появлялось в том месте, где я хочу (по центру символа пина к примеру)?

Подскажите правильный синтаксис для атрибута Supply Pin. Пытаюсь изменить название цепи на пине атрибутом 1=0VD но реакции нетлиста на это не вижу, цепь называется как и прежде - GND (по умолчанию).

Мда...DxD в плане эргономики инструмент, конечно, никудышный. Второй день вожусь с переименованием Supply цепей для Xilinx. Мало того, что атрибут Supply Pin работать отказывается по непонятным мне причинам, так теперь и в графе Supply Rename обнаружилась проблема. Ввожу туда данные для трех групп пинов "GND=0V Vcco=5V Vcci=3V" - получаю на выходе в нетлисте NET : '0V' .... NET : '3V' ... NET : '5V Vcci=3' ... Почему имя третьей цепи выводится в таком виде? Для любых двух напряжений все в порядке, но как только добавляешь третье - получаешь вот такую картину. Помогите разобраться в чем дело - перелопатил поиск по хэлпу и форуму.

К этой цепи подключены какие-либо пины других компонентов? Если в цепи только один пин, то естественно ничего и не увидите.



1. Неонятно причем здесь эргономика?
2. Невидя проекта трудно сказать что вы там наворотили.
3. Внутри IOD такие вещи как изменения имен неявных сигналов земли\питания делаются парой щелчков и т.к. PDB пере-генерируется автоматом, то и не приходится что-либо переделывать руками на уровне схемы.

Естественно подключены. Я попытался аннотировать схему с проблемным элементом в Exp - вот что выдает лог ошибки:

Pin 1 of DD10 has default net \GND\ assigned to it
in the Parts DataBase for Part XC2S200-5PQG208I which
would have had its net renamed to \0VD\ if the pin
did have a SupplyPinPhrase in the schematic. It is being
reassigned to net 0VBS in the schematic. A supply pin
may not be assigned to a net other than the one to which
it would have been renamed. Please adjust the
supply rename property or the assignment in the schematic
and rerun Packager.

Как это понимать? Я не могу переназвать группу пинов 0VD и выделить из нее несколько пинов, принадлежащих к другой цепи? Поясните пожалуйста.

1. Неонятно причем здесь эргономика?

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

2. Невидя проекта трудно сказать что вы там наворотили.

Да ничего особенного, вобщем-то. Обычный FPGA на схеме задан одним УГО. Часть пинов занесена в группу Supply и разбита на три подгруппы (GND, Vcci, Vcco). переименование с помощью Supply Rename работает отлично для любых двух подгрупп, если переименовывать сразу три - одна из цепей получается обозвана некорректно.

3. Внутри IOD такие вещи как изменения имен неявных сигналов земли\питания делаются парой щелчков и т.к. PDB пере-генерируется автоматом, то и не приходится что-либо переделывать руками на уровне схемы.

Охотно верю. Но на данный момент у меня нет времени погружаться еще и в тонкости работы с IOD. Не все ведь сразу, хотя бы DxD-Exp освоить более-менее.

Поэтому я и написал что не видя что вы там наворотили сказать трудно.
Судя по диагностике у вас получается двойное переопределение цепи, могу только продположить что все пины GND переопределяются сначала через Supply_Rename и затем еще отдельные из них через Supply_Pin. Т.е. получается масло-маслянное что и не нравится упаковщику.
Собственно говоря тогда какие проблемы изменить название цепи в локальном PDB (если не хотите изменить в ЦБ) и применить Supply_Pin для отдельных пинов?

"Карфаген должен быть разрушен"...

Ну никак не получается у меня Лезем в Special Symbol и ставим на схему или PORT, или LINKS. ПОЧЕМУ у этого символа на схеме атрибуты ставятся, извините, раком? Нет, конечно я их потом подвину как мне надо, но тем не менее. Подключаем LINKS к именованной цепи. Получаем атрибут Name в том месте, которое DxD считает правильным. А если в символе УЖЕ имеется атрибут Name, ручками определённый в Library manager, тогда вообще цирк. В свойствах символа на схеме оказывается ДВА одинаковых свойства с именем Name и с одним реальным атрибутом на схеме. Причем если снять галочку отображения у любого из них, то соответствующий атрибут становится невидимым. Но почему же это свойство вдобавок перемещается, хотя в символе уже задано его положение?!

Александр, Вы правы - именно так. Я хочу переименовать всю группу и выделить из нее несколько пинов для повторного переименования. Это запрещенная операция? Я считал, что аттрибут Supply Pin для того и предназначен.
Проблем с изменением PDB никаких, но хотелось достичь результата исключительно с помощью схемотехнического редактора - без изменения компонента.

Двойное переименование запрещено.
Так используйте только Supply Pin для обеих групп пинов.
Формат же позволяет:
<pin number>=<netname> <pin number>=<netname> <pin number>=<netname>
Например:
2=GND 4=VCC 1=VDD
единственная проблема если их много, то вбивать придется долго.