Работая с ChipScope появилось желание задать более сложное воздейстивие на элементы VIO (Virtual Input/Output component) чем это возможно через ChipScope Analazer. Вообще самое хорошее было бы просто файл прокачать через VIO.
Может возможно как-нибудь подключиться к VIO компанентам через Matlab/Simulink или что-то C++ - подобное. Или через TCL или еще каким-нибудь способом.
Подскажите может кто-нибудь занимался этой проблемой?

Я попробовал сделать это через TCL. Я напрямую пытался дергать ножками TCK, TDI, TMS. Использовал я Xilinx USB JTAG. Ничего из этого не вышло. На осциле я видел как TDI дергается когда мой TCL скрипт проходит чейнинг, берет инфу о кристалах в цепочки. Но вот когда идет мой цикл с дерганием ног командами
csejtag_target set_pin $handle $CSEJTAG_TMS $value
csejtag_target set_pin $handle $CSEJTAG_TCK $value
csejtag_target set_pin $handle $CSEJTAG_TDI $value
ничего не происходит.

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

Берете этот файл, где у вас воздействия, делаете из него MEM, и простейший автомат (счетчик адреса фактически), который эти цифры из ПЗУ будет читать и превращать в сигнал. На одном модуле памяти можно сделать тест на 9 сигналов длиной 2048 тактов. Больше модулей - больше сигналов или длиннее последовательность, в отлаживаемом проекте память обычно свободная есть.

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

И так я продолжаю свои мучения. Моя задача может решиться путем использования JTAG Loader для Picoblaze от Ken Chapman, но он не работает с USB Xilinx JTAG кабелем.
Как кто решает проблему с JTAG для Picoblaze?

Если вам требуются такие огромные тестовые воздействия - скорее всего, дизайн просто плохо отлажен. Используйте для начала моделирование, вначале поведенческое, а потом и временнОе. За одну ночь прогона временнОй модели на современном компьютере можно прогнать достаточно длинный тестовый вектор, при этом иметь потом доступ ко всем внутренним сигналам проекта. ChipScope же в основном бывает нужен чтобы отловить различия железа и временной модели: посмотреть, что реально приходит на кристалл извне, как работают PLL и иные асинхронные цепи, если они есть. Работа же внутренних синхронных цепей определяется моделированием с весьма и весьма высокой вероятностью.

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

Что мешает в поведенческой модели пробовать то одно, то другое?

А что неужели все что вы делали и откатывали в симуляции даже очень дотошно вдруг сразу стало работать в кристале? Ну ушто не разу у PLL low и high не перепутывали или асинхронный ресет не глючил все? Если так то я просто снимаю шляпу! Я просто не настолько аккуратен и хотел бы иметь возможность иметь быструю возможноcть hardware simulation.
А коли она даже вроде как заложена производителем который выпустил Chipscope - то грех ей не воспользоваться - если не понравиться то можно ей и не пользоваться в дальнейшем
Большое спасибо за конструктивные предложения. Вы Дмитрей единственный кто хоть как-то откликнулся!

Вовсе нет, но для того, чтобы это отладить, не нужны гигантские тестовые вектора.
Короче, мы уже по второму кругу пошли. Вы хотите большие тестовые вектора в аппаратуре. Я отвечаю, что то, что требует больших тестовых векторов надо отлаживать на симуляторе, а в аппаратуре отлаживать только то, что не может быть правильно моделировано.

Ну да чего-то мы не там сталкнулись. Очень многие вещи можно сделать разными способами.
Тема данного топика найти решение для работы с JTAG.

Может немного не в тему - иногда в симуляторе _очень_ долго получается. Особенно если тестируется что-то длинное с обратными связями. Проще получается откомпилить целиком проект и завести сигнал, чем симулировать те же полдня, а потом выяснить что воздействие не то. Но отмечу, что такая ситуация возникает обычно на этапе "сборки" проекта целиком, а не тестирования отдельных модулей...

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

Хотя, AFAIK, по BS-цепочке получится не очень быстро, если надо симулировать _всю_ периферию + разные тактовые и пр... все-таки синхронно там все и медленно. А вот одну шину, мне кажется, можно и нужно

Да нет почему-же в тему. Ведь я же говорю, что если с HOST-а грузить воздействие, то оно может быть любым,а не предустановленным как в варинте с заполнением банок памяти. Вот был у меня проект, где надо было делать сигнальную обработку с обратными связями, где переходные процессы были доли секунды, а тактовая около 100МГц. На компе симулировать это было просто мучение!

имхо, в Вашем случае скорости JTAG не хватит.
Спасет логичиский анализатор с патерн-генератором
крайне удобно но жутко дорого....

Ну про скорость JTAG: да пофиг какая скорость ведь этим тестом хочиться проверять синтезабельность+функционал. А патерн-генератор до меня еще не доехал...