Т.к. судя по всему многие до сих пор не понимают, что такое IOD и зачем он нужен, попытаюсь популярно объяснить это в приложении к ПЛИС:

1. Предположим мы начинаем новый проект платы в которой будет стоять ПЛИС(ы).
2. Проработали функционально наш проект и определили какие сигналы (цепи) будут подключены к ПЛИС.
3. Можно начинать определение ПЛИС, используя проект в IOD, сделать это можно несколькими путями:
а) Написали VHDL(Verilog) файл в котором есть "шапка", т.е. определены порты - соответственно его можно:
- прочитать в IOD и таким образом список сигналов окажется в IOD.
- передать разработчику ПЛИС (естественно если не он сам его сделал) для дальнейшего формирования функционально\структурного описания внутренности ПЛИС
б) Ввели сигналы непосредственно внутри IOD:
- можем сгенерить VHDL(Verilog) файл и передать разработчику ПЛИС.
4. Выбрали изготовителя ПЛИС, конкретный device и маршрут ПЛИС.
5. Сделали предварительное присвоение выводов внутри IOD.
6. Генерировали\нарисовали символ(ы) внутри IOD.
7. Экспортировали символы\PDB в DxDesigner.
8. Нарисовали схему платы в DxD.
9. Создали проект платы и сделали размещение.
10. Обратно аннотировали размещение в IOD.
11. Сделали перераспределение выводов для улучшения длин соединений и распутывания их.
12. Теперь надо связаться с разработчиком внутренности ПЛИС на предмет передачи ему информации о текущем распределении выводов. Передать ему можно любой файл из трех типов:
- P&R_Constraints_File (Actel (.pin, .gcf or .pdc), Altera (.csf or .qsf), Xilinx (.ucf), Lattice (.lpf)
- Pin Report File (Actel (.rpt), Altera (.pin), Xilinx (.pad or .csv), Lattice (.pad)
- FPGA Xchange File
Как правило любой из этих файлов могут прочитать (а также генерировать) системы разработки ПЛИС и таким образом ему не нужно будет в ручную определять выводы.
13. После того как разработчик ПЛИС одобрил это размещение или предложил свое (переделанное через такой же файл), вы решаете задачу трассировки платы. Походу этого естественно могут возникать вопросы дальнейших итерации по перераспределению выводов ибо как у разработчика платы может возникнуть потребность в этом, так и у разработчика ПЛИС - все это решается через процесс аннотаций и генерирования указанных выше обменных файлов. Процесс контролирует "Синхронизатор" - если изменились какие-либо подключенные к проекту IOD файлы, он это увидит и предложит соответствующие действия.

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

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

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

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

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

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

Запускаю одновременно 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 открывается автоматом.

У меня новое окно DxD не стартует если есть уже открытый DxD. Более того в DxD открыт этот проект и единственное, что требует IOD, это закрыть в редакторе саму схему.
Чтобы обновилась локальная PDB тоже не обязательно закрывать Exp - достаточно закрыть саму топологию. Если Exp открыт, то тоже самое, при нажатии внутри DxD иконки ExpeditionPCB в уже открытом Exp загружается данная плата.
Т.е. процесс выглядит достаточно просто:
- перед экспортом из IOD закрываем схему и топологию (не закрывая сами редакторы)
- далее при экспорте последовательно загружаются схема и топология в уже открытые редакторы.

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

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

- В 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 - увы. Возникает риторический вопрос "что делать?".

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

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


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

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

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

выведи к название цепи "B" еще и название рипера цепи В
и еще название шины, что в нее включено

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


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

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

1. В случае шины получилась составная цепь с именем 3.3V,3.3V_0,3.3V_1 соответственно все компоненты которые через PDB должны подключится к ней (вместо ранее задуманной 3.3V) должны иметь Supply_Rename c этим именем (а не 3.3V)
2. Я не понял вы для плис, пины питаний вывели на символ или в PDB? Если в PDB, то естественно придется добавить и к символу *_pcb атрибут
Supply_Rename.
3. Самое простое это если вы выложите проект чтоб не играть в угадывание, что вы там понаделали.

в 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 это, конечно, решение, но это явный кастыль.

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


1. Tools > Types Compatibility вводим совместимые типы, т.е. для данного случая VCCO и VCC, VCCO и VCCAUX
2. Перетаскиваем сигнал из списка сигналов в список пинов с нажатыми клавишами Ctrl+Shift (естественно перед выполнением операции сделать Unassign для даннного сигнала 3.3V и сигналы 3.3V_0 и 3.3V_1 удалить)

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