[SM 0]

Я же даже в своем видео это отразил.

Там две галки:

- Первая - сохранить в виде HKP

- Вторая - в Local_PDB_File

Что-то я видео где-то пропустил... Внимательно вроде просмотрел две предыдущие страницы...

Галки-то я и сам через хелп нашел. Я не пойму, что сделать надо, чтобы hkp появился. Поставил галку, сохранил проект, а hkp не сохранился в результате.

[fill 2]

Что-то я видео где-то пропустил... Внимательно вроде просмотрел две предыдущие страницы...

Галки-то я и сам через хелп нашел. Я не пойму, что сделать надо, чтобы hkp появился. Поставил галку, сохранил проект, а hkp не сохранился в результате.

 

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

[Asb 1]

IOD не видит и категорически не желает импортировать из Schematic Design'a (Design Capture) результаты свопинга диф.пар в Expedition.

Маршрут DC/EE2007.7 - IOD 8.1.

Не претендуя на истину в последней инстанции пришел к выводу, что для того, чтобы результаты свопинга диф. пар импортировались в IOD, необходимо чтобы PCB имя сигнала во внутренней базе данных IOD (.fpc) было заключено в кавычки, т.е содержало какой нибудь разметочный символ (ну там '>', '<' или '+').

Блин, ну нельзя же так, ведь чуть крышу не снесло - шина свопируется нормально, а отдельные сигналы - нет, хоть тресни. :maniac:

 

Нет все еще хуже: без угловых скобок в названии не работает. В общем похоже из DC в IOD импортировать диф. пары не судьба. Обиднооо :(

[SM 0]

Хочу повозмущаться. Очень!

 

Запускаю одновременно IOD, DxD и Exp. IOD в режиме с локальной pdb. Разумеется на трех разных рабочих столах, чтобы удобно было.

Делаю что-то в IOD. Довольно серьезное. К примеру unravel nets с use unused pins, ну и питания докучи перекидываю, так как меняю банки. Делаю синхронизацию. Он мне открывает еще один DxD. Зачем? У меня же и так открыт один DxD с этой схемой! Он что, в нем не может сделать нужные действия?! Ну или хотя бы потом самозакрыться за собой, если не может... Потом перехожу на р/стол с Exp, жму FA (и PDB изменился, и схема). Этот товарищ вообще говорит Errors и типа смотри лог. Смотрю лог, и что я вижу? А то, что Exp не увидел изменений в локальной PDB (режим FA - обновления нового из ЦБ, оставление всего остального старого), но увидел изменения в схеме! В результате одно дургому не соответствует, ясно, еррор. Закрываю Exp, сохраняя все, что он хочет. Заново делаю экспорт символа в IOD, чтобы он переписал еще раз эту злополучную pdb, потому что ее зачем-то Exp переписал обратно на старую, а "Export->pdb" нету. Он мне еще раз запускает DxD :) который я просто закрываю. Заново запускаю Exp и открываю плату в Exp, делаю FA, все отлично! Теперь запускаю LM, не закрывая DxD и Exp. Чуть правлю один символ и меняю конфигурацию одного пада. Делаю в Exp FA - тут все ОК. А что DxD? А в DxD приходится извращенно переключать ЦБ с текущей на другую, но ту же текущую, просто лежащей в "якобы другом месте" через символическую связь в файловой системе, чтобы он увидел изменение в ЦБ. В результате на все эти запуски-перезапуски, открытия-закрытия убил времени раза в четыре больше, чем на полезную работу. И нахрена тогда вообще нужны все эти навороченные базы данных, ЦБ, и прочее, если софт через них не может нормально на уровне транзакций работать?

 

Ну неужели нельзя подружить все продукты друг с другом, чтобы было удобно работать в одновременно запущенных всех частях тулчейна? Хотя бы на одной машине, не говоря о запуске нескольких частей на разных. Пусть выполнить несколько действий в разных программах. Пусть даже не единообразных. Но не закрывать-открывать их, и не лезть в глубины сетапов. Просто одной-двумя кнопками!

 

ЗЫ. Но во всем есть и что-то полезное... Это, например, поддерживает словарный запас в части матерных слов и умение им пользоватьтся :)

[Frederic 0]

Хочу повозмущаться. Очень!

 

Запускаю одновременно IOD, DxD и Exp. IOD в режиме с локальной pdb. Разумеется на трех разных рабочих столах, чтобы удобно было.

Делаю что-то в IOD. Довольно серьезное. К примеру unravel nets с use unused pins, ну и питания докучи перекидываю, так как меняю банки. Делаю синхронизацию. Он мне открывает еще один DxD. Зачем? У меня же и так открыт один DxD с этой схемой! Он что, в нем не может сделать нужные действия?! Ну или хотя бы потом самозакрыться за собой, если не может... Потом перехожу на р/стол с Exp, жму FA (и PDB изменился, и схема). Этот товарищ вообще говорит Errors и типа смотри лог. Смотрю лог, и что я вижу? А то, что Exp не увидел изменений в локальной PDB (режим FA - обновления нового из ЦБ, оставление всего остального старого), но увидел изменения в схеме! В результате одно дургому не соответствует, ясно, еррор. Закрываю Exp, сохраняя все, что он хочет. Заново делаю экспорт символа в IOD, чтобы он переписал еще раз эту злополучную pdb, потому что ее зачем-то Exp переписал обратно на старую, а "Export->pdb" нету. Он мне еще раз запускает DxD :) который я просто закрываю. Заново запускаю Exp и открываю плату в Exp, делаю FA, все отлично! Теперь запускаю LM, не закрывая DxD и Exp. Чуть правлю один символ и меняю конфигурацию одного пада. Делаю в Exp FA - тут все ОК. А что DxD? А в DxD приходится извращенно переключать ЦБ с текущей на другую, но ту же текущую, просто лежащей в "якобы другом месте" через символическую связь в файловой системе, чтобы он увидел изменение в ЦБ. В результате на все эти запуски-перезапуски, открытия-закрытия убил времени раза в четыре больше, чем на полезную работу. И нахрена тогда вообще нужны все эти навороченные базы данных, ЦБ, и прочее, если софт через них не может нормально на уровне транзакций работать?

 

Ну неужели нельзя подружить все продукты друг с другом, чтобы было удобно работать в одновременно запущенных всех частях тулчейна? Хотя бы на одной машине, не говоря о запуске нескольких частей на разных. Пусть выполнить несколько действий в разных программах. Пусть даже не единообразных. Но не закрывать-открывать их, и не лезть в глубины сетапов. Просто одной-двумя кнопками!

 

ЗЫ. Но во всем есть и что-то полезное... Это, например, поддерживает словарный запас в части матерных слов и умение им пользоватьтся :)

не вижу больших проблем. просто нужно принять это и спокойно работать. да Ехр нужно закрывать, чтобы освободить локальную базу для обновления сделанных в IOD. Закрытие DxD производится одной кнопкой :) , а при экспорте из IOD DxD открывается автоматом.

[fill 2]

У меня новое окно DxD не стартует если есть уже открытый DxD. Более того в DxD открыт этот проект и единственное, что требует IOD, это закрыть в редакторе саму схему.

Чтобы обновилась локальная PDB тоже не обязательно закрывать Exp - достаточно закрыть саму топологию. Если Exp открыт, то тоже самое, при нажатии внутри DxD иконки ExpeditionPCB в уже открытом Exp загружается данная плата.

Т.е. процесс выглядит достаточно просто:

- перед экспортом из IOD закрываем схему и топологию (не закрывая сами редакторы)

- далее при экспорте последовательно загружаются схема и топология в уже открытые редакторы.

 

Что касается обновления содержания ЦБ внутри DxD, то к сожалению, не видел в Mentor Ideas чтобы кто-то из пользователей софрмулировал данное предложение по улучшению, видимо это сильно напрягает пока только вас :laughing:

[SM 0]

Возвращаюсь к питательному вопросу.

 

- В IOD задал для разных групп пинов питания 3.3V, 3.3V_0 и 3.3V_1 (так как у пинов разный TYPE, то IOD мне не дает назначить одно и то же питание на все пины сразу)

- В DxD сделал шину с именем "B" (без bus contents), к которой подвел цепь питания с выхода БП и из которой вывел три глобальных сигнала 3.3V, 3.3V_0 и 3.3V_1

Теперь что я вижу в Exp. Все цепи, которые подведены внутри DxD к 3.3V на всех листах явным образом, действительно подключены куда надо, к БП. А вот цепи, которые подключены через pdb - увы. Возникает риторический вопрос "что делать?".

[Frederic 0]

Возвращаюсь к питательному вопросу.

Теперь что я вижу в Exp. Все цепи, которые подведены внутри DxD к 3.3V на всех листах явным образом, действительно подключены куда надо, к БП. А вот цепи, которые подключены через pdb - увы. Возникает риторический вопрос "что делать?".

а что написано про эти пины в Integration/AugmentedPins.txt

[SM 0]

а что написано про эти пины в Integration/AugmentedPins.txt

Да с виду все в порядке там...

 Part lfxp2-8e-5mn                     |
       U1                              |  A12| 3.3V
       U1                              |  B11| 1.2V
       U1                              |   B5| 3.3V
       U1                              |   B7| 3.3V
       U1                              |  C11| 3.3V_0
       U1                              |  C14| 3.3V
       U1                              |   C3| 3.3V
       U1                              |   C4| 1.2V
       U1                              |  F13| 3.3V
       U1                              |   F2| 3.3V
       U1                              |  J13| 1.2V
       U1                              |  J14| 3.3V_0
       U1                              |   J2| 3.3V_0
       U1                              |   J3| 1.2V
       U1                              |  K12| 3.3V_1
       U1                              |   M1| 1.8V
       U1                              |  M12| 3.3V
       U1                              |   M3| 1.8V
ну и т.д.

 

Я недопояснил - соотв. пины подключены и к цепи "3.3V", и к "3.3V_0", но эти цепи ничего не имеют общего с той "сложной" цепью из DxD, т.е. пины соединены между собой согласно названиям из IOD, но к БП не подключены.

 

PS. Нашел один ракообразный выход - если все цепи подключить к БП через 0-омные резисторы, а не напрямую, тогда все ОК. Но у меня места на плате нету даже на три резюка 0201...

 

PPS. Нашел еще один ракообразный выход - поправить руками в PDB, заменив 3.3V_* на 3.3V и убрав из DxD ту самую шину-разветвитель. Но не хочу ничего руками, не удобно, надо чтобы оно все без ручных правок.

[Frederic 0]

Да с виду все в порядке там...

Я недопояснил - соотв. пины подключены и к цепи "3.3V", и к "3.3V_0", но эти цепи ничего не имеют общего с той "сложной" цепью из DxD, т.е. пины соединены между собой согласно названиям из IOD, но к БП не подключены.

 

PS. Нашел один ракообразный выход - если все цепи подключить к БП через 0-омные резисторы, а не напрямую, тогда все ОК. Но у меня места на плате нету даже на три резюка 0201...

выведи к название цепи "B" еще и название рипера цепи В

и еще название шины, что в нее включено

[SM 0]

выведи к название цепи "B" еще и название рипера цепи В

все риперы без названий. Я понял, к чему вопрос - но там все ОК. Иначе бы подключения к "3.3V" с других листов схемы тоже бы к БП не подключены были бы. Однако проблемы только с через-PDB-шным подключением, и, кстати, не только с IOD-ным pdb, а и с другими компонентами, где подключение через Supply Rename.

 

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

 

Вот попробовал через иерархию. Внутри блока просто все порты соединены друг с другом. Стало лучше - 3.3V соединились все между собой, включая pdb-шные, а вот 3.3V_0 и 3.3V_1 - нет.

[fill 2]

1. В случае шины получилась составная цепь с именем 3.3V,3.3V_0,3.3V_1 соответственно все компоненты которые через PDB должны подключится к ней (вместо ранее задуманной 3.3V) должны иметь Supply_Rename c этим именем (а не 3.3V)

2. Я не понял вы для плис, пины питаний вывели на символ или в PDB? Если в PDB, то естественно придется добавить и к символу *_pcb атрибут

Supply_Rename.

3. Самое простое это если вы выложите проект чтоб не играть в угадывание, что вы там понаделали.

[SM 0]

2. Я не понял вы для плис, пины питаний вывели на символ или в PDB? Если в PDB, то естественно придется добавить и к символу *_pcb атрибут

Supply_Rename.

 

в pdb. Я понимаю, что можно добавить символу _pcb Supply Rename, но это такая же ручная работа, как и поправить вручную сам pdb, убрав оттуда эти _0 и _1. Т.е. при следующей перегенерации символа, подсхемы и pdb в IOD все эти действия придется повторить заново.

 

Моя же задача - сделать так, что бы ничего не трогать из того, что генерирует IOD. Т.е. ни подсхему функ. символа, ни сами символы, ни pdb. Т.е., получается, надо как-то сделать три цепи с именами 3.3V, 3.3V_0 и 3.3V_1, физически соединяющиеся друг с другом в одной точке и электрически представляющих собой единую цепь. Или как-то задать IOD-у, что все нужные мне пины подключены на единую 3.3V. Пока что ни то, ни это мне не удается.

 

Или прямо в IOD-е можно прописать Supply Rename для генерируемого символа?

 

------------------------------------------------

Вопрос закрываю. Приемлемое для себя решение нашел через аттрибуты символа в IOD. Спасибо за подсказку fill-у.

 

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

[fill 2]

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

 

Нашел способ: стр. 94-95 описания

 

1. Tools > Types Compatibility вводим совместимые типы, т.е. для данного случая VCCO и VCC, VCCO и VCCAUX

2. Перетаскиваем сигнал из списка сигналов в список пинов с нажатыми клавишами Ctrl+Shift (естественно перед выполнением операции сделать Unassign для даннного сигнала 3.3V и сигналы 3.3V_0 и 3.3V_1 удалить)

[SM 0]

О! Ну это другое дело. Спасибо, буду знать. А я, блин, уже отказался от глубокого копания документации, так как до сего момента ответов на вопросы она практически не давала.