Т.к. судя по всему многие до сих пор не понимают, что такое 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 файлы, он это увидит и предложит соответствующие действия.

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

Александр, спасибо за описание, действительно - кратко, толково, без лишней воды.
Но, несмотря на безмерное уважение к Вам с моей стороны, по поводу продукта возникают некоторые вопросы:

Пока, я вижу в этом только один плюс: "Как правило любой из этих файлов могут прочитать системы разработки ПЛИС и таким образом ему не нужно будет в ручную определять выводы." Т.е. я убью 2 дня времени, пройду через кучу гемора с IOD, наловлю косяков и все это только для того, чтобы душечка программист не мучался с назначением портов вручную ?
Я, конечно, не махровый гуру, еще только учусь, но у нас все просто:
1. Сформировать перечень сигналов, которые пойдут в/на плис. Из них лишь небольшое кол-во является предопределенным, остальные свободные, поэтому это Я буду в декларативном порядке сообщать программисту какие сигналы на каких ножках будут, а не ОН мне. Т.к. ему это фиолетово, а мне на плате - нет. Случай с DDR модулем немного другой, но там тоже от программиста немного зависит.
2. Выслушать от программиста пожелания - какие бы он особые сигналы хотел видеть на спец. ножках, типа глобальных клоков.
3. Спокойно разводить плату.
4. Сообщить программисту где будут какие сигналы. И он за полчаса вручную их назначит.

В результате мне не нужно мучаться с IOD, писать там всякие описания и прочее. Как-то так, уж извините.

Может быть, конечно, если делать плату с 100 плисами, причем разными, через IOD это будет и удобнее. Я таких не делал. Но, если почитать, большинство народа, пройдя через кучу создания разных описаний, символов и наловив кучу глюков, остаются с недовольным осадком.

Случай, когда разводчик и программист в разных странах - не рассматриваю. Там - возможно.

Тогда дополню:
1. Передача информации автоматом через файл исключает человеческий фактор - если у вас 1000 выводов, то при ручном вводе легко сделать ошибку, причем это касается как разработчика ПЛИС так и схемотехника-тополога (в PDB также легко можно сделать ошибку).
2. IOD контролирует правильность назначения сигналов. Я уже видел проекты, где разработчики плат сделали ошибки в назначении сигналов "не в те выводы" - когда делали схему и плату они не всегда дотошно изучали datasheets. А затем схемотехники, заказавшие эти платы у них, разбирались почему они не работают и пытались ускорить процесс поиска таких неправильных назначений в том числе с помощью IOD.
3. При достаточно плотном заполнении ПЛИС возникает потребность компромиса между получением нужной скорости внутри ПЛИС и внешней длины\распутывания связей на плате. Ориентируясь только на один критерий вы неизбежно проиграете в другом - выбрав только внешнюю длину\чистоту связей вы можете не получить нужную частоту внутри ПЛИС и наоборот. В таких случаях и нужны итерации назначения выводов, а значит IOD может помочь.

Предположим

Ну, допустим

Я извиняюсь, но чтобы начинать определение ПЛИС, не нужно ничего, кроме Вашего любимого текстового редактора
И если уж так хочется сгенерить hdl-файл, а не набрать его ручками, никакие иоды не нужны. Достаточно скриптов

Для этого иод не нужен

Зачем? Предварительное присвоение выводов делается в схемном редакторе путем рисования схемы Для этого нам понадобятся библиотечные символы, схемный редактор и руки. Возможно даже голова, но никак не иод

Это ключевой момент. Если ПЛИС многоногая, и ее символ получается слишком большой, чтобы разместить ее на схеме, этот самый символ необходимо разбить на части. Причем я не верю, что существует ПЛИС, символ которой физически невозможно разместить на схеме. Это всегда можно сделать, но такой символ не будет удовлетворять гостам. Существует и другая причина побить символ на более мелкие - удобочитаемость. Во всех остальных случаях необходим один символ на одну ПЛИС, который рисуется штатными средствами используемого вами пакета разработки печатных плат. Таким образом, IOD предназначен лишь для разбиения символа ПЛИС на более мелкие, все остальное притянуто за уши. Имхо на всякий случай

Существует жизнь и вне DxD

Ну сделали

Это еще зачем?

Причем штатными средствами, без иодов

Очень мило Ну если лень разработчику вручную определить выводы согласно имеющейся схеме, так и быть, я ему определю вручную. Затрачу я на это, ну, допустим, час. И что? А если очень хочется погенерить текстовые файлы, в моем распоряжении всегда есть всевозможные скриптовые языки

Перераспределение выводов делается путем правки схемы и прямой аннотации в плату без участия каких-либо посредников, которые непонятно что синхронизируют. И какие такие действия может предложить таинственный синхронизатор? Как у Жванецкого: "Продолжать движение!!!"?

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

На создание компонета с ~700 ногами в ИОДе уходит час-два, это если не спешить. Это при том, что несколько групп свапирования, разные стандарты ввода-вывода, разные клоки, МГТ и т.д. И даже мысли не приходит что возможна ошибка с нумерацией, перепутыванием ног и прочими косяками. Изменения в сигналах делаются еще быстрее. ОДно из основных достоинств - это база по всем ПЛИС.
Даже думать не хочу сколько человеко-месяцев нужно чтобы без ошибки создать такой компонент без ИОД, а потом его править при изменении количества сигналов\банков и т.д.
Поэтому можно забить на все глюки ИОД, коих ни чуть не меньше чем в ДхД.

Допустим.

Имхо, несерьезно. На этапе создания символа задача библиотекаря - тупо повторить даташит.

Извините, не понял, в каких таких сигналах?

Сомнительное достоинство. Заходим на сайт производителя и скачиваем даташит.

Т.е на создание компонента с 700 ногами без ошибок у Вас уйдет несколько человеко-месяцев? Не сочтите за наезд, но теперь я понимаю, что ИОД иногда полезен И не понимаю, зачем править созданный без ошибок компонент. Как в компоненте, серийно выпускаемой славной капиталистической промышленностью, может измениться количество сигналов (каких сигналов?) и банков? Это же не трансформер какой нибудь, а FPGA!!!

интересно как ты в базе пропишишь ногу с функционалом Diff/Clock/IO/DiffClock ???
и через день придется поменять Clock на IO чтобы сделать своп


надо скачивать не даташит, а ээээ как правильно выразится файл распиновки для IOD
хотя даташин нужен, чтобы нарисовать Cell


в яблочко и этим подведен итог дискусии.


в четверг я вправлю тебе мозги

Не поверишь, с помощью клавиатуры

Стесняюсь сказать, но мне не нужно менять "Clock на IO", чтобы сделать своп

Ну если даташит не нужен, не скачивай. Медитируй над "файлом распиновки для IOD". Там информации больше

Исключение человеческого фактора. Вероятность ошибки при вводе м\сх с 1000 ногами далека от нулевой, а ее цена очень высока.
Создать универсальный символ для ПЛИС невозможно, поскольку в каждом проекте свои сигналы, разные питания. И соответственно разные группы свапа.


Например есть группа ног для ЦАПа, они 3,3В, им заданы банки 1-2 где они могут свапиться, есть ноги АЦП, они ЛВДС, т.е.2,5В им заданы банки 3-4. И нужно поменять местами. Или для ЦАП отдать 1,3. А еще есть клоки которые должны попадать на клоковые ноги, МГТ с его питанием, и т.д.
В ИОД все это делается элементарно, в нем уже вся информация о плис. Без него все вручную, долго, непроизводительно, и при этом есть вероятность ошибки.


см. выше.


Каждый волен расставлять вокруг себя любые грабли. Удачи.

А в случае использования IOD даже не обязательно его качать, большинство ПЛИС уже в базе, надо только выбрать производителя, модель и корпус.

Сколько времени надо для того чтобы "тупо повторить даташит"? В IOD тупо генерация символов проделывается минут за 5-10, плюс полчаса-час на подгонку под ГОСТ, и это речь о корпусе FF1760 например.
А сколько времени нужно для создания компонента? Создание групп свопирования, сверка с даташитом каждого пина банка, питания и т.д... В IOD же просто надо по фильтру выделить все пины банка и пачкой определить в одну группу свопирования. И, как говорилось выше, исключение пресловутого человеческого фактора, ошибиться при ручном создании компонента элементарно.

Группы свопирования для ФПГА вещь совершенно бездарная, так как можно или нельзя свопнуть два пина определяется не только даташитом на ПЛИС, но и доп.функциями пинов и назначением соответствующих цепей, и особенностями разводки схемы внутри ПЛИС. Так что нет смысла вообще определять свопируемые пины в pdb на плисину.

А кто мешает создавать отдельный pdb для каждого нового проекта учитывая все эти особенности? Или вы хотите сказать что проще редактировать схематик? В IOD можно быстренько набросать несколько вариантов pdb для разных плис проекта. А если использовать его по уму - с синхронизацией и прочим, то в теории всё вообще должно быть замечательно
но внедрить что-то новое довольно сложно... вот и делается многое по-старинке

в ЦБ вообще можно не делать компанент.
работать локально и как сказал Inpharhus для каждого проекта своя индивидульная плисина

Да вот я пока ничего не хочу сказать Еще не вник в суть. Но точно могу сказать - что в pdb нет механизма учета "всех этих особенностей", поэтому однозначно делать это не в pdb. А значит именно IOD и генерация каждый раз всего заново для каждого проекта.

PS.
Хотя, как по мне, лучше бы один универсальный символ по даташиту и разветвленная и продвинутая система констрейнов по части того, что с чем можно свопить и по каким правилам. И никакого IOD не надо бы, все необходимое было бы в Exp.

Подскажите пожалуйста такую вещь по IOD:

- ПЛИСка Lattice LFXP2-5E-5MN132

Есть входная цепь "INCK", стандарт IO LVDS25, которая должна быть подключена на входной сигнал одной из двух PLL.
Я ставлю ей стандарт LVDS25, ставлю тип PLLDIFF, после чего assign говорит, что нету таких пинов. Хотя я то точно знаю, что есть, а именно
PT8A__ULC_GPLLT_IN_A__True_of_PT8B / PT8B__ULC_GPLLC_IN_A__Comp_of_PT8A
и второй вариант - PB26A__LRC_GPLLT_IN_A__True_of_PB26B / PB26B__LRC_GPLLC_IN_A__Comp_of_PB26A

В чем дело и как правильно тут поступить?

Дальше хуже. Кроме этого есть еще пины IN, тоже LVDS25, и это та же физическая цепь, что и INCK (ну т.е. входной сигнал должен прийти одновременно и на dedicated вход PLL-ки, и на generic IO. Ну надо так. Там ШИ-модулированный 150-Мбитный поток данных), и правило по ее размещению - должна быть в том же банке, что и INCK. Тоже не понял, как это задать.

Да-да. Людям следует доверять только в самом крайнем случае (Це)
Число пинов растет как на дрожжах

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

Это Ваш ответ на вопрос о сигналах на этапе создания компонента? Первый раз слышу о сигналах в символе и pdb(кроме сигналов питания). Старею, наверное.

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

Действия я привык совершать осознанно и нести полную ответственность за их последствия, так что по крайней мере в вопросах свапа она мне вряд ли понадобится, тем не менее спасибо, и Вам тоже удачи

Рискну предположить что нужные пины имеют переключаемый тип и он в данный момент отличный от PLLDIFF, хотя я не совсем понял что именно вы делаете, да и IOD под рукой нет.


Кому бесполезно, а кому нет. IOD генерит не только символ, но и pdb, главное не забыть о создании cell с указанным IOD именем.
Вот кстати удивляюсь этому, что сложно было интегрировать в IOD сразу все необходимые cell'ы? Нарисовать не сложно, но время...

IOD на выходе может создавать схематик с символами и уже присоединенными цепями к пинам.

А вы в окне Pins на этих пинах установили нужный тип - я так понимаю они многозадачные?

Я хочу соптимизировать подключение цепей к пинам исходя из заданных мной правил, как это показывал fill в ролике, где в IOD перенесено размещение компонентов на плате, и видны все цепи. Потом оттрассировать плату. После чего хочу сгенерировать verilog-шапку с получившимся назначением пинов, и начать писать описание устройства, реализованного в этой ПЛИС.


А там предлагают только DIFF или IO, а PLLDIFF нету. DIFF не катит, так как свопится с чем попало.... А можно как-то "custom" тип добавить или сделать просто DIFF, но добавить констрейн, что только либо эта пара, либо та? Да и как я уже понял, в окне Pins не надо тип выставлять, IOD сам смотрит, есть ли нужный тип в списке, и если есть, то коннектит.

Конечно, не обязательно качать. Настоящие ковбои даташитов не читают (Це)

Символ, что ли, нарисовать? С 1760 ногами? Ой, как страшно Ну допустим, за рабочий день справлюсь... Ну ладно, так и быть, специально для Вас - за два А если меня посадят библиотекарем на постоянку, заточу соответствующий инструмент, и буду выдавать такие страшные символы ну максимум за пару часов. А что?

Не, ну про свопирование и человеческий фактор я третий раз повторять не буду. Устал.

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

Присвоить DIFF, выбрать 2 нужные пары пинов и присвоить им собственную группу свопирования.

Вообще-то IOD тип пина сам меняет только в случае изменения типа сигнала к нему подключенного. Т.е. если сигнал назначен нами в пин и мы поменяли тип сигнала.

Ага, понял, спасибо. А как теперь поступить со второй частью вопроса - другой сигнал, который тоже DIFF, и правило для него "в том же банке, что и этот сигнал, но на любой дифпаре".


Ну как же так? Я вот описал пачку сигналов типа DIFF, сделал Assign pins with overwrite им, и он сам все подключил, куда надо причем, и поменял тип с IO на DIFF.

ЗЫ.
А можно как-то руками залезть в БД IOD-а и вручную нужным пинам добавить тип PLLDIFF? IMHO это упростило бы жизнь...

Ключевое слово Assign pins with overwrite - вы принудили назначить сигнал в пин не его типа - в текущей версии не проверял, но так можно было назначить и в пин который не может быть такого типа вообще .



В принципе да, но надо изучать документацию.

А то что вы сами ответили на вопрос целесообразности IOD - экономия времени. А если "заточить" IOD, то и подгонять под ГОСТы почти нечего будет...
Повторю еще раз - IOD одновременно генерит еще и pdb, а это тоже время.
В любом случае сомневаюсь что какой-либо заточенный инструмент будет быстрее IOD по отношению к фпга, кроме случаев выхода новых плис еще не включенных в IOD и то лишь до момента выхода соответствующих библиотек

Ну наверно все оставшиеся дифпары банка объединить в другую группу свопирования и прицепить к какой-нибудь дифпаре этот сигнал.

Если разберетесь в синтаксисе .\IOD\library\devices\... далее производитель, модель фпга и редактирование файла *.dev

Не понял, зачем Вы мне это рассказываете? То, что иод Вам не бесполезен, я уже понял. Все остальные возможности иода узнал во время плотного знакомства с ним, сразу после перехода на Expedition. Спешите поделиться радостью иодного просветления?

Неа, не даеть... Только в пины, которые могут быть такими. Он по ходу физически не может переписать тип пина на тот, которого нет в списке.


Ну что же... Порою...

Повторите третий раз, пожалуйста. Очень хочется еще раз почитать А я пожалуй, третий раз повторять не буду. Не просто устал, а очень устал Просто сделаю выводы и пойду работать.
Всем иодным дизайнерам - привет!!!

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


Спасибо еще раз, и Impharus-у тоже за наводку на .dev файлы, там по ходу можно и свои новые типы добавлять тоже.

Насколько я знаю - нет. IOD генерит стандартный pdb, там же это невозможно?
А там их и не будет, группы свопирования имеют условные названия которые при генерации pdb становятся некими группами Просто для удобства IOD сразу часть пинов определяет в стандартные группы, но это наверняка прописано в движке IOD, а не в файле .dev

P.S. А цепи по-моему вообще не имеют групп свопирования.

Так мне в pdb вообще группы свопирования не нужны. Мне нужно чтобы IOD все это знал. Что например на пару типа DIFFPLL, которая находится в группе свопирования DIFF_PLL_INPUTS, можно еще и два разных IO прицепить, если эти пины не заняты, и когда они IO, свопировать их по правилам свопа обычных IO...


Имеют, имеют...

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

fill, а почему это в описании EE2007.7? IOD стал его частью? А не отдельным продуктом?

Так взаимодействие с проектом все равно через pdb происходит, если я всё правильно понимаю. Речь о маршруте DC-Exp, а с DxD не работал, не знаю как там.
Если работать в режиме синхронизации IOD с проектом думаю у вас всё получится. Когда надо - поменять группы свопирования и тип пинов...

А как я понял - работа делается через аннотацию в Exp. А как в сам DxD - пока не знаю, я только начал делать символ и парт в IODе, ни в DxD, ни в Exp еще ничего не размещал. Но IOD спросил меня путь к проекту DxD-шному при создании IOD-ного проекта.

И... Я вообще не понимаю, на кой нужны группы свопирования в pdb, если все свопирование делается в IOD?

Он остался отдельным - ведь его можно использовать не только с Expedition. Просто его релизы синхронизуют теперь с текущим релизом EE, ведь внутри IOD можно создать сразу project в формате DxD и если его формат не совпадет с текущими возможностями DxD то ...

уже второй раз вижу скриншот переведенного документа на 2007.7. А можно весь документ целиком увидеть?

Тут не подскажу. Я в IOD генерил символ и компонент, на выходе имел .hkp и пачку .inp которые потом импортировал в центральную библиотеку и уже использовал в проекте.

Чтобы свопировать в Exp. А то ведь запаришься аннотировать туда-сюда...

Так я IOD только ради того, чтобы свопировать в нем, и применить решил, так как правила свопирования EXP-а куцые и меня не устраивают.

Если внимательно посмотрите видео, то есть два варианта передачи PDB:
1. Через файл *.hkp - такой же путь используется для DC\DV - т.е. надо потом импортировать его в ЦБ или плату (намек тем кто это не заметил и всегда тащит все в ЦБ )
2. Через Local_PDB - сделан для DxD - т.е. данный файл при экспорте записывается в папку Integration и автоматически попадает в плату при прямой аннотации. Т.е. в случае DxD можно вообще не иметь ни символов ни PDB внутри ЦБ - процесс значительно ускоряется и упрощается.

Т.к свопировать можно и не выходя из Exp. - например есть у вас шина и надо переставить ее члены между собой, то и создаются группы свопирования в PDB - иначе это было бы невозможно и пришлось каждый раз переходить в IOD.

Во - именно этот путь и есть наш


Ну скажем так - мне это не нужно, так как я, как понял, все цепи ("нитки") увижу и из IOD. Да и сходить в IOD - это ведь просто переключиться в другое окно - мне не в напряг.

Ну не просто переключиться, а еще провести синхронизацию. Пробуйте

Ясно дело, попробую... А то выхода-то два всего - или IOD с его умным свопированием, или в PCAD, который умеет "свопировать несвопуемое" с дополнительным подтверждением в уверенности... А свопирование в Exp отпадает на корню из-за того, что после аннотации в DxD оно портит соответствие номеров пинов их названиям на схеме.

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




но тогда надо несколько cell (с простыми площадками, площадки аддаптированные под ренгенконтрль, с переходными via, cell с микроvia ......)
а так для начала сгенери в PCB Matrix, но внимательно с cell Editor, если работать без ЦБ, то возможно удаление cell, не взирая что он используется в проекте

Тааак.... Начинается... У меня IOD на одном компе, там нет DxD. А DxD на другом - там нет IOD. Такой раскордаж временный, из-за отсутствия линуксового IOD. Интересно, оно вообще получится так синхронизироваться? Я еще не успел попробовать синхронизацию.


А подправление .dev-файла руками на тему добавления типа PLLDIFF к нужным мне пинам сработало. Осталось таки въехать, можно ли задать такое правило свопа, навроде "цепь INCK должна быть подключена к пинам типа PLLDIFF, а цепь IN к пинам типа DIFF, и они обе обязаны быть в одном банке, но все равно в каком."

Скорее всего неполучится, т.к. при экспорте из IOD запускается DxD для выполнения действий по генерированию подсхемы в проекте. Аннотация идет через схему. IOD<-->DxD<-->Exp

Ну я все же надеюсь, что он генерирует какой-то скрипт, который потом выполняется в DxD. Если так - то можно попытаться его, скрипт, подсунуть вручную. А если нет - то можно попытаться обмануть всех сразу, сделав запуск DxD через rsh или ssh, чтобы IOD думал, что запускает локально, а не самом деле удаленно.

А вообще конечно жаль, что ментор не думает о том, что с одним проектом может работать несколько человек в разных программах (LM, IOD, DxD, Exp) из разных мест.

Подскажите есть ли что-то похожее на IOD для микропроцессоров или может бывают библиотеки микропроцессоров для IOD?

Готовые библиотеки врядли, а работать с ASIC уже можно - изучайте iod_asic_user.pdf



При экспорте в окне консоли написано:
idxdesigner C:/MentorGraphics/IOD8.0/IODesigner/dxdesigner/rundxd.vbs C:/Demonstrations/Vidar_WG/Vidar_WG.prj FPGA_Controller_top 1

В Preferences>Paths указание где лежит DxD.

В iod_fpga_user.pdf описание TCL команд.