Сэр!
Вот Вам ответ от Др. Ами Городецкого:
У Вас в самом деле осталось невыясненными значительно более одного вопроса. Во-первых, при выполнении команды EXTEST выходы ИС ни в коем случае не переключаются на TAP-контроллер, они вообще никак не связаны с ТАР-контроллером, поэтому вопрос о том, когда они обратно переключаются, не имеет смысла. А имеет смысл внимательно почитать, как происходит управление всем этим в нашей статье “Регистры и команды граничного сканирования” – см.
www.start-test.com/University/Docs/6_07_Registers_commands.pdf
Что касается цепочки из двух ИС: все правильно, одна из них в EXTEST, а вторая – в BYPASS, именно так все и происходит, никаких других прошивок не нужно. Временные диаграммы этих команд для более глубокого понимания можно найти в той же статье.
И вообще, читайте продолжающийся цикл наших статей в журнале “Производство Электроники” и у нас на сайте:
www.start-test.com/University/StartestInRussia.aspx
Вопросы можно (и нужно!) задавать напрямую с нашего сайта:
www.start-test.com/Language/Rus.aspx

Спасибо за ответ. Постараюсь переформулировать вопрос в терминах именно этой статьи: при каких условиях сигнал Mode, который (как следует из статьи) устанавливается в 1 при выполнении команды EXTEST, возвращается обратно в 0?



Правильно ли я понимаю, что переведя один раз ноги одной из м/сх в 3 состояние (или в любое другое - например вывод какого-либо значения, загруженного SAMPLE/PRELOAD или очередным EXTEST'ом) командой EXTEST, я могу рассчитывать, что они в этом состоянии и останутся, подавая далее команды BYPASS? Если так, то как вернуть м/сх обратно в штатный рабочий режим?

Подозреваю, что ответом на 1ый и 2ой вопросы является перевод TAPконтроллера в состояние test-reset-logic, так ли это?




Продублировал туда.


upd: с вашего сайта комменты не посылаются! при попытке что-то послать выкинуло вот сюда: http://www.start-test.com/BadRequest.aspx?...nguage/Rus.aspx . Браузер - opera 8.5)

Сэр, привет от Ами.Го.
Из статьи следует, что Mode=1 не все время выполнения команды EXTEST, а только начиная с заднего пульса t0 при нахождении контроллера ТАР в фазе UPDATE_IR (см. рис.8). Через 2,5 периода ТСК (по переднему фронту t2) уже произойдет чтение реакции схемы, так что это последний осмысленный срок удержания выходного мультиплексора открытым, и его переключение (Mode=0) ТАР может выполнить в любой момент этого промежутка времени.
Второй вопрос: контакт ИС может быть введен в третье состояние командой EXTEST (или PRELOAD, или HIGHZ), если он снабжен ячейкой управления ЯУ (типа d или g - см. рис.6), и в эту ячейку загружена определенная в файле BSDL величина disval (читайте статью “Язык описания структур граничного сканирования” в
www.start-test.com/University/Docs/7_07_BSDL.pdf ). Команда BYPASS регистр РГС не активизирует, поэтому контакт ИС будет оставаться в третьем состоянии до тех пор, пока в его ЯУ не будет загружена величина /disval.
Если же на контакте Вы хотите “завесить” какое-то значение (0 или 1) командой EXTEST (или PRELOAD, или CLAMP), то следует помнить, что контакт ИС подключен к триггеру фиксации не более 2,5 периодов ТСК при выполнении команды EXTEST (или CLAMP), все остальное время он остается подключенным к ядру ИС (возможно, через выходной мультиплексор), т.е. остается в “штатном рабочем режиме”.
Относительно сброса контроллера ТАР (в состояние TLR) подозрения неверны, он здесь совершенно ни при чем. Никакого обнуления или сброса регистров данных ГС ни в этом и ни в каком другом состоянии ТАР не происходит.
Вопросы можно (и нужно!) задавать напрямую с нашего сайта:
www.start-test.com/Language/Rus.aspx Мы проверим, почему был сбой, подозрение на то, что Ваш браузер должен быть при этом установлен на кодировку Unicode (UTF-8). Можно также писать с английской страницы сайта
www.start-test.com/Contact/Default.aspx , там с кодировкой проблем не будет.
Л.К. Мы уже проверили - нет проблем. Возможно был какой-то сбой сервера.

Для начала про сайт - от языка и браузера не зависит. Короткие сообщения (из 1 слова) отправляются, более-менее длинные - нет. Продолжаю всё же здесь. Могу сообщить вам (или вы мне) email в привате для общения, но всё же думаю, что поднятая тема интересна не только мне.


Что же получается тогда - если у нас есть какой-либо не-jtag компонент (например flash, ram, да и хотя бы банальная 74hc74), подключенный к jtag-микросхемам, то его проверить (или зашить) невозможно? Мой опыт показывает, что, например ep1k30 состояния между выполнениями команды EXTEST сохраняет (ибо flash и ram, подключенные к ним, шьются без проблем). При этом многие из соединений имеют pullup'ы, а сама последовательность данных для команды extest составляет почти 700 бит и вдвигается при помощи дёргания за ножки LPT "вручную" (giveio.sys), то есть ОЧЕНЬ медленно.



Из рис.6 и рис.7 статьи 6_07_*.pdf, а также, скажем, из вот этого файла ftp://ftp.altera.com/outgoing/download/bsdl/3032al44.bsd следует, что как выходное значение на ножку, так и управление выходным буфером на эту ножку осуществляются однотипными ячейками типа BC_1, которые либо пропускают значение из ядра м/сх (Mode=0), либо подменяют его значением из РГС. Следовательно, вопрос #1 всё ещё в силе. disval же, насколько следует из статьи 7_07_*.pdf, указывает, какое именно значение надо записать в ЯУ данной ножки, чтобы отключить выходной буфер.

[тут случайно было дублирующее сообщение, просьба удалить]

Ответы от др. Городецкого.
Что же получается тогда - если у нас есть какой-либо не-jtag компонент (например flash, ram, да и хотя бы банальная 74hc74), подключенный к jtag-микросхемам, то его проверить (или зашить) невозможно? Мой опыт показывает, что, например ep1k30 состояния между выполнениями команды EXTEST сохраняет (ибо flash и ram, подключенные к ним, шьются без проблем). При этом многие из соединений имеют pullup'ы, а сама последовательность данных для команды extest составляет почти 700 бит и вдвигается при помощи дёргания за ножки LPT "вручную" (giveio.sys), то есть ОЧЕНЬ медленно.

Я ведь отвечал на вопрос о выполнении команды EXTEST, а не последовательности команд EXTEST вперемешку с другими возможными командами. Еще более корректно вопрос следовало бы задать относительно ячеек ГС того или иного типа. Скажем, для ВС_1, ВС_2 и ВС_5 последовательность команд EXTEST включает и удерживает Mode=1, для ВС_3 такая последовательность включает и удерживает Mode=0, а для ВС_7 вместо сигнала Mode используются сигналы Mode1, Mode2, Mode3, и ответ был бы совсем другим и не в формате форума и не журнальной статьи. Хотя Вы правы, ответ действительно неполон, т.к. существует целый набор событий, которые могут перевести Mode в 0, например загрузка команд BYPASS, SAMPLE и т.д., а также сброс ТАР в исходное состояние TLR, и другие.

Ответ на данный вопрос - очень даже возможно! Ваш опыт впечатляет, но частота "дергания за ножки" и в этом случае тоже не имеет (для большинства приложений) решающего значения.



Второй вопрос: контакт ИС может быть введен в третье состояние командой EXTEST (или PRELOAD, или HIGHZ), если он снабжен ячейкой управления ЯУ (типа d или g - см. рис.6), и в эту ячейку загружена определенная в файле BSDL величина disval (читайте статью "Язык описания структур граничного сканирования" в
www.start-test.com/University/Docs/7_07_BSDL.pdf ). Команда BYPASS регистр РГС не активизирует, поэтому контакт ИС будет оставаться в третьем состоянии до тех пор, пока в его ЯУ не будет загружена величина /disval.
Если же на контакте Вы хотите "завесить" какое-то значение (0 или 1) командой EXTEST (или PRELOAD, или CLAMP), то следует помнить, что контакт ИС подключен к триггеру фиксации не более 2,5 периодов ТСК при выполнении команды EXTEST (или CLAMP), все остальное время он остается подключенным к ядру ИС (возможно, через выходной мультиплексор), т.е. остается в "штатном рабочем режиме".
Относительно сброса контроллера ТАР (в состояние TLR) подозрения неверны, он здесь совершенно ни при чем. Никакого обнуления или сброса регистров данных ГС ни в этом и ни в каком другом состоянии ТАР не происходит.





Из рис.6 и рис.7 статьи 6_07_*.pdf, а также, скажем, из вот этого файла ftp://ftp.altera.com/outgoing/download/bsdl/3032al44.bsd следует, что как выходное значение на ножку, так и управление выходным буфером на эту ножку осуществляются однотипными ячейками типа BC_1, которые либо пропускают значение из ядра м/сх (Mode=0), либо подменяют его значением из РГС. Следовательно, вопрос #1 всё ещё в силе. disval же, насколько следует из статьи 7_07_*.pdf, указывает, какое именно значение надо записать в ЯУ данной ножки, чтобы отключить выходной буфер.

Определение "однотипные ячейки типа ВС_1" бессмысленно, по-видимому, имеется в виду "одинаковые", хотя предложение в целом возражений не вызывает. Но это утверждение, а где вопрос?

Вопрос №1 , а также ответ на него - оба в силе, а как же... Вплоть до переключения Mode в 0 по тем или иным причинам контакт ИС подключен к триггеру фиксации и не находится в "штатном рабочем режиме". Загрузка команды BYPASS непременно приведет к Mode=0, и хотя содержимое триггера фиксации при этом может оставаться прежним, к контакту ИС он уже подключен не будет. При желании сохранить на контакте ИC значение, введенное в EXTEST, переведя саму ИС в BYPASS, следует после EXTEST ввести CLAMP – описание см. в статье 7_07.

Выражение "чтобы отключить выходной буфер" в статье 7_07 не употребляется в силу своей некорректности: выходной буфер либо прозрачен, либо в третьем состоянии (если ЯУ=disval). Но это тоже утверждение, а не вопрос.



Кстати, проверил длинное сообщение. Прекрасно работает.

оформили как нибудь или локально юзаете ?