назвал сигнал DONE, имена стали одинаковыми и ........ проблема осталась
в DxD на символе рсв на сигнале DONE не появляется порт и упаковка не проходит

на взирая на предупреждение THIS SHEET IS AUTOMATICALLY UPDATED BY I/O DESIGNER. PLEASE DO NOT MODIFY. руками поставил порт DONE на цепь пина, обозвал DONE и упаковка прошла на ура. FA тож на ура
горячая связь по цепи X_DONE (это уже цепь в DxD) работает, подсвечивается и пины и проводник для DxD & Exp

не понимаю в чем дело
какая галка при экспорте не поставлена чтобы порт ставился для символа рсв ???

Ну тут надо разбираться на проекте. Как я понимаю для других цепей она порты поставила? Иначе связи по иерархии не получилось бы. Т.е. проблема с конкретной цепью\портом\пином.



1. Ну вообще-то в данном режиме подсхема не перерисовывается. Вы уверены что не использовали самый первый пункт меню экспорта?
2. Вполне логично - в Preferences->Symbol Editor выставляется размер листа для внутреннего редактора символов, который в свою очередь влияет на размер листа подсхемы. А в Preferences->Symbol Editor>Export вы конфигурируете что и как будет экспортироваться. Если переместить настройку форматки туда где выставляется размер листа, сетка и т.п. то станет еще менее логично, т.к. получится что выставляем вид\размер форматки для символьного редактора - что напрямую противоречит действительности, ибо в символьном редакторе IOD мы форматку увидеть никак не сможем. Вот если бы можно было отдельно выставлять размеры листа для символьного редактора и отдельно для генерируемой схемы, тогда все стало бы более определенным.

да, порты для других цепей поставила
осталось проблема со всеми пинами JTAG и Config которые я руками ввел в символ рсв и функциональный (т.е. ошибка упаковки на каждый пин JTAG и Config). сейчас я уже хотел на одном пине DONE пройти упаковку.
Александр, проект на XC35S700 ты уже имеешь, с тем над которым мы (точнее я бился долго).
в новой версии проекта я решил выкинуть питание в глобальные (это удачно прошло), а JTAG и Config ввести в функциональный символ.

одно условие - проект был в 2007.6 а сейчас он в 2007.7

Ну и в чем проблема?
- Удалил все лишние символы из IOD - осталось всего два (функ. и _pcb)
- Перетащил на эти символы пины конфиг. (3 штуки)
- Сделал экспорт схемы и символов
- Запустил Package - 3 ошибки - все правильно, щелкнул на ошибке и увидел старые конфиг. символ и символ питания в общей схеме
- Удалил их из общей схемы , ибо теперь их быть не должно иначе дублируются пины (одинаковый номер есть как на символе в схеме, так и в PDB в разделе Supply...)
- Все - упаковка заработала

Посмотрел подсхему - все на месте - IOD сам добавил порты на эти три цепи Нажмите для просмотра прикрепленного файла

1. Уверен. Схему не экспортировал специально.
2. Согласен, отдельное выставление размеров было бы логично.

Ну тогда не знаю почему у вас так работает ибо у меня при All_Symbols схема не перерисовывается- специально несколько раз проверил.

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

IOD не видит и категорически не желает импортировать из Schematic Design'a (Design Capture) результаты свопинга диф.пар в Expedition.
Маршрут DC/EE2007.7 - IOD 8.1.
Интересно это только у меня или реально существует такая проблема ?

Попробуйте после выполнения обратной аннотации закрыть-открыть проект в DC\DV и сделать compile.

сделал новый проект - три цепи и сигнал DONE.
только два символа: функцю. и рсв
после экспорта нет порта

и только сейчас разобрался в чем дело, оказалось из-за моей лени
у меня расположение окнон signals-pins-symbols
я перетаскивал пины из pins, просто он ближе к symbols


проверил все комбинации и выяснил
ЕСЛИ пин из Pins попадает на функциональный символ - после экспорта нет порта в подсхеме

господа, плиз проверте мою догадку

Port Binding - получится разный. Откройте Properties и увидите.
Signal - будет порт на схеме
Pin - не будет

да , увидел
Pin - не будет и соответственно не проходит упаковка
не вижу смысла в этой фиче

Зайди в Help и увидишь что у Port Binding есть и другие задачи.

К сожалению не помогает.
Корень проблемы похоже в следующем:
При сохранении базы данных, для дифсигналов с именами вида NAME<k> {NAME_p<k> NAME_n<k>} (такие имена получаются после команды Split для диф. шины) происходит замена свойств "Diff Namе P" ("Diff Namе N") с NAME_p<k> (NAME_n<k>) на NAME_p_k (NAME_n_k), при том, что имена сигналов входящих в пару не изменяются.
После этого IOD начинает работать странно и нестабильно (например перестает работать srename) .
По моему проблема вполне заслуживает формирования SR на менторе (ежели еще не завели).

Теперь у меня очередная пачка вопросов. Два скриншота - иод и подсхема в дхд.

Вопросы:

- JTAG и VPLL/GPLL. На ф. символе они есть, перетащил сигнал вручную, но каким образом они подключены в подсхеме к ПЛИСине?
- Питания. Что-то я смотрю аттрибуты FPGA Signal у pcb-символа в подсхеме, и нифига не понимаю, почему они отличаются от того, что в таблице у IOD?

Если IOD сделал pdb и прописал в нем правильные питания, то как и где этот pdb найти и посмотреть?

1. На предыдущей странице пример с TMS, TDI, TDO, TCK
В подсхеме как у всех сигналов выведенных на функ. символ - от пинов символа _pcb короткие отрезки цепей с именами сигналов и в правом верхнем углу такие же отрезки оканчивающиеся портами с именами сигналов выведенных на функ. символ.
2. После FA в Exp - Setup>Part_Editor

Так на pcb-символе нет отрезков, нет пинов... Но тут я похоже недоделал, на пцб-символ тоже надо было руками сигнал добавлять.


А до FA и до первой упаковки вообще?

И что насчет несоответствия атрибутов FPGA Signal тому, что на схеме в IOD?

1. Сделайте из IOD экспорт в hkp. Полученный файл можно импортировать в ЦБ и посмотреть.
2. Вообще-то данный атрибут находится в списке Obsolete Properties (стр. 191 "DxDesigner® Properties Glossary") - т.е. в 2007.7 уже не используется.

А как? Единственное, что нашел - галка в пропертях проекта, что Export Part Data и что этот экспорт в hkp. А где искать результат, и в какой момент он должен появиться?

Я же даже в своем видео это отразил.
Там две галки:
- Первая - сохранить в виде HKP
- Вторая - в Local_PDB_File

Соответственно (и это видно в окне Console) *.hkp сохраняется в папке проекта, а PartsDB.pdb в папке Integration\Layout\

Кстати можно и PartsDB.pdb посмотреть:
- Копируем PartsDB.pdb в папку PartsDBLibs какой либо ЦБ
- Удаляем SysIndex.cbf из головной папки этой ЦБ
- Открываем ЦБ в LM
- LM пересобирает ЦБ и в ней образуется новый раздел компонентов с именем PartsDB, в котором и лежат наши PDB генерированный из 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 удалить)

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

1.сделал
Нажмите для просмотра прикрепленного файла
2.перетащить не получается появляется Cannot swap pins with NOSWAP group
для сигнала +3.3V какое должно стоять значение Type

Попробуй VCCO, у меня получилось с ним.

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

наверно пора записаться на курсы "Успокоения нервной системы"
не хрена не могу прописать VCCO и VCCAUX под +3.3V
а кажисссь проще простого "2. Перетаскиваем сигнал из списка сигналов в список пинов с нажатыми клавишами Ctrl+Shift (естественно перед выполнением операции сделать Unassign для даннного сигнала 3.3V"

Я так понял ты пытаешься претащить уже назначеные, что естественно запрещено.
Сделай Unassign всех пинов +3.3V, а также пинов VCCO, VCCAUX которые надо назначить на +3.3V. И только потом делай общее присвоение.

Надо обязательно сделать UNASSIGN всем тем цепям, которые будут потом одним питанием, и VCCAUX, и VCCO, всем, потом их всех разом (с ctrl/shift) выделить в pins list, и всех скопом перетащить на сигнал 3.3v, и бросить туда с ctrl+shift.

К превеликому сожалению нельзя добавлять сигналы по одному несмотря на Type compatibility. Только из pin list и только оптом. Как всегда "особенности национальной ...". Т.е. для перебрасывания одного питания в другое место придется опять оперировать всей кучей.

прошлый проект, он модернизируется и VCCO, VCCAUX висели на сигналах VCCO, VCCAUX соответственно
теперь, одним словом - полная виктория

для SM

т.е. ты хотел бы каждый банк посадить на свое питание ?

Не только хотел, но и посадил У меня часть банков на 1.8 вольтах, часть на 3.3. Но это совершенно не суть, самое главное, что если я задумываю менять банки по ходу дела из соображения удобства разводки, то 3.3 вольта приходится опять полностью unassign, и опять скопом заново assign. Вместо того, чтобы один-два пина унассигн/ассигн.

Коллеги, прокомментируйте, где у меня ошибка:
мне необходимо также часть банков повесить на напряжение 2,5 а часть на 3,3. Я создаю два сигнала: 2V5 и 3V3. Сажаю на эти сигналы соответствующие VCCO. Далее делаю символы, причем добавляю VCCO к символам (к PCB-символам). Беда в том, что когда я пробовал НЕ добавлять эти пины к PCB символам, у меня генерировался PDB без этих сигналов. Ставлю функциональный символ на схему DxD. На подсхеме вижу, что к VCCO добавлены отрезки цепей с маркировкой: 2V5 и 3V3. Оно все бы хорошо, да беда в том, что когда я делаю аннотацию в Expedition, соответствующим пинам присвоена цепь с суффиксом, т.е. 2V_60. Понятно почему: эти сигналы не объявлены глобальными на подсхеме, генерируемой IOD, хотя на схеме верхнего уровня они объявлены глобальными. Итак, вопрос: что делать? Можно, наверное, добавить эти сигналы на функциональный символ, но хочется, чтобы все неявно было задано.
IOD, зараза, как только меняешь функциональный символ, ломает все твои символы и приходится заново их формировать. Кстати, когда я посадил неиспользуемые клоковые входы на землю, у меня IOD нагенерил кучу символов с этими входами... все пришлось вручную удалять. Короче, каждая итерация, внесение изменений обходятся большим количеством ручной работы. Спрашивается: на кой хрен такая автоматизация, когда она чревата побочным ручным трудом? В сумме убил на IOD недели две чистого рабочего времени, и до сих пор все гладко не получается

Быть того не может. Если в Signals есть и 3V3 и 2V5, и эти сигналы приассигнены к какому-то множеству пинов, и режим генерации символов "только использумые пины" и "без питаний", то они совершенно точно попадают в PDB. Как вариант - Вы забывали закрывать плату в Exp, и pdb в результате просто не перегенерировался. Это да, неприятность, что ментор не может подружить свои программы друг с другом, чтобы они все работали впараллель на одном проекте.

Не, я ничего не забывал, я уже так намучился, что порядок закрытия-открытия выучил как "отче наш". Но тем не менее ситуация изменилась: я поставил Update2. После этого напряжения назначились и передались в плату. Однако есть одна маленькая и одна большая неприятность. Маленькая: когда стал делать Update символам, то мастер зачем-то запихнул VCCO пины в PCB символы, хотя когда я их создавал, была выбрана опция не добавлять пины питания. Ну ладно, я их вручную выкинул - все прокатило. А вот большая.
Мне надо было назначить GND на неиспользуемые пины Clock. Еще до установки апдейта2, я сделал Tools-Type compatibility-GND=CLOCK. После чего перетащил сигнал GND на нужные пины клока, удерживая Ctrl+Shift. Все получилось. Однако, после установки апдейта, IOD мне сообщил:
# Assignment for signal GND is not valid.
# Invalid pins will be unassigned.
И, как обещал, нахрен удалил мои назначения. И повторить фокус не удается. Вываливается сообщение: Cannot swap pins with NOSWAP group. Попытка поиграться с назначением группы свопирования удачи также не принесла. Сижу, подсчитываю потерянное время, и тихо матерю менторовцев...
{чуть позже: видимо, это был рудимент первого апдейта. Удалил сигнал GND и создал заново. Группа свопирования осталась неназначенная, а раньше было NOSWAP. После чего удалось успешно назначить GND на нужные пины}
{{Еще чуть позже: однако, пока не добавил этот GND сигнал на функциональный символ, в плату передавался на пины клока сигнал GND_66. После добавления - ОК}}
Кстати, вот еще один глюк: если на VCCO пины не назначать явно сигнал, но в настройках на вкладке Symbol Generation задать VCCO=2V5, то ни хрена не назначается, на плате эти пины идут с именем VCC, хотя оно у меня НИГДЕ не фигурирует. Но да ладно, этот глюк хотя бы обойти можно. Правда, не проверял актуальность глюка на втором апдейте.
И еще один глюк, на закуску: когда довел число IO до 200 (почти все доступные IO задействованы, включая VREF), причем все они сидят на одном SWAP GROUP, перестала работать функция Unravel. Долго думает и ничего не меняет, ни на что не ругается.
Когда же наконец софтомейкеры начнут тестировать свои творения на реальных проектах, а не рафинированных?!

Ну это только что обсуждали на примере VCCO/VCCAUX - надо сделать unassign ВСЕМ gnd, потом выделить в pins ВСЕ то, что надо на GND, и перещить на сигнал GND, бросив с ctrl+shift. Не забыв убедиться в наличии TYpe Compatibility


Это не совсем глюк, а может и совсем не глюк, а готовить не умеем... Оно вполне назначатеся, в процессе когда делается Assign All после задания IO-стандартов всем сигналам. Причем все сигналы автоматом появляются в Signaks. Но вот как автоматически переназначить после тусования IO-банков и IO-стандартов в них я так и не понял.

Разумеется, всем GND был сделан unassign. К слову, нет необходимости делать assign на стандартные пины GND - они и так, даже без задания сигнала, передаются как GND.



По-моему, задавать IO-стандарт - дело бесполезное. Я попробовал было задать 2,5V и 3,3V LVCMOS, потом сделал передачу constraints в DxD, потом, через некоторое время, сделал import constraints из DxD - у меня слетели все назначения IO-стандарт, при этом в логах сетовалось на то, что вроде как ref не задано или что-то в этом духе. Ну да, у меня Vref пины используются как io, но это же не повод скидывать назначения? А вот еще один глюк. Читаем описание:

так вот, попробуйте задать сигналу (или пину) какой-нибудь I/O standard - ни хрена entire bank не affected и неиспользуемые пины вовсе не changed to the same I/O standard



Вот сейчас еще один сюрприз при синхронизации: cannot export the constraints to the iCDB:Error: can not create differential pair in the CES configuration.
Сдается мне, что надежней и БЫСТРЕЕ было бы сделать символы в IOD, экспортировать их в ЦБ, и работать без IOD. Таким образом, пока ментор сделал лишь более-менее приличную рисовалку символов ПЛИС. Все остальное по сути в стадии альфа-тестирования.

Не, не бесполезное. Когда я первый раз ввел на "чистый лист" все сигналы и все IO-стандарты, IOD автоматически раскидал сигналы по банкам и создал все необходимые X.XV (у меня 1.2, 3.3 и 1.8), и приассигнил их к пинам. А вот как потом в процессе оптимизации, после того, как я перетусовал банки, заставить его переассигнить все автоматом, я так и не допетрил.


Ну да, я с этим в принципе согласен. Есть многое, но все какое-то сырое и многие действия не поддаются логике, т.е. надо просто знать наизуть, что делается оно так, и только так. Будем ждать и надеяться.


Чудеса какие-то... В pdb попадают только назначенные сигналы.

Вот, кстати, продолжение моего романа с IOD:
После очередной синхронизации, получил такой лог (привожу слегка в сокращенном виде)

# signal 'GND' has been unassigned - type of signal GND is not compatible with type of pin A11
# signal 'MSEL<1>' has been unassigned
# signal 'GND' has been set as 'DIFF'
# signal 'MSEL<1>' has been set as 'DIFF'
# Signal GND has been set to diff.
# The differential pair can't be imported from the CES. The electrical net '' connected to the pin '' has no equivalent signal in the I/O Designer.

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

А потом я сделал своп сигналов, в результате чего в бакне 2 сигналов стало больше. Дале синхронизация с апдейтом символов. При апдейте опять назойливо закинул VCCO в символы. Пришлось опять вручную выкинуть. Прошу взглянуть на результат:Нажмите для просмотра прикрепленного файла
В придачу, опять скинул назначения GND на клоки и MSEL1, сделал их DIFF. Пришлось опять ручками - заново. Только теперь я залочил эти сигналы. При очередной синхронизации получил:

cannot set signal 'GND' as 'DIFF'
cannot set signal 'MSEL<1>' as 'DIFF'
The differential pair can't be imported from the CES. The electrical net '' connected to the pin '' has no equivalent signal in the I/O Designer.

Понял толко одно: он ругается именно на MSEL<1> потому, что он сидит на земле (через функциональный символ)