По аналогии с шуткой 90-60-90 это не размеры, а номер телефона, могу сказать, что 32 бита это не длина регистра данных (она у каждого чипа своя и может быть извлечена из файла BSDL), а фиксированная длина поля ID регистра. Такие программы как XILINX iMPACT, ALTERA QUARTUS, LATTICE ispVM умеют определять длину и количество элементов в цепочке а также вычитывать ID CODES.

С каких это пор инструкция IDCODE стала одинаковая для всех чипов ?

Посмотрите внимательнее на состотяние Test-Logic-Reset

Сэр, читайте внимательней посты. Не инструкция одинаковая, а длина поля.

Оно-то верно, в случае если этот регистр ID есть Кусочек из стандарта :
...
Test-Logic-Reset

The test logic is disabled so that normal operation of the on-chip system logic (i.e., in response to stimuli
received through the system pins only) can continue unhindered. This is achieved by initializing the instruc-
tion register to contain the IDCODE instruction or, if the optional device identification register is not pro-
vided, the BYPASS instruction (see 7.2). No matter what the original state of the controller, it will enter Test-
Logic-Reset when TMS is held high for at least five rising edges of TCK. The controller remains in this state
while TMS is high.
...

Совершенно верно. Но, редкий чип с JTAG не содержит этого регистра.

Я буквально на днях закончил прочтение IEEE 1149.1, и не возьму в толк, отчего возник спор вокруг того, что достаточно ясно описано в стандарте. Чипы, поддерживающие JTAG, обязаны, как минимум, иметь на борту BYPASS register. Они также могут иметь опциональный ID регистр. При переходе в состояние Test-Logic-Reset (тем или иным способом) таковой чип обязан подключить между TDI и TDO либо BYPASS (если нету IDCODE), либо ID (если таковой есть, то именно его). BYPASS всегда инициализируется 0, а ID в 2-х младших битах обязан иметь pattern "01". Длина ID регистра известна (32 бита) и зафиксирована стандартом. Если добавить сюда еще необходимость начинать ВДВИГАЕМУЮ битовую последовательность зарезервированным fake-ID кодом ("xxxxx000011111111" <- lsb), то мы получаем все возможности для того, чтобы:
1) определять начало и конец "отклика" JTAG-цепочки;
2) отделять друг от друга последовательности, соответствующие BYPASS и ID регистрам;
3) соотвтественно, определять место в цепочке соответствующих чипов с BYPASS/ID и вести их учет.

Прошу извинить обчество, если вышеперечисленное было и так всем ясно.

Не совсем так - мне буквально недавно приходилось решать подобную задачу - имелся чип-микросборка с неизвестным числом последовательно "оцепоченных" TAP-ов , один из которых был достоверно ARM7TDMI-S. По ID-регистру выяснить ничего не получится - код команды IDCODE не стандартизован, и длина IR у всех девайсов разная. Но - BYPASS вроде определен в стандарте как все единицы. Вот на это и следует опереться:
1) грузим в цепочку IR-ов единички в избыточном количестве
2) определяем количество регистров BYPASS и соответственно количество TAP-ов
3) далее следует разбить цепочку IR на отдельные элементы - тут в помощь тот факт, что при записи IR он инициализируется в b'01. Ищем единички в отклике после загрузки BYPASS и выясняем границы IR-отдельных TAP-ов. Ну а потом уже выцепляем нужный TAP.

Вот вы говорите: "1) грузим в цепочку IR-ов единички в избыточном количестве". Описанная мной метода (на авторство, ессно, не претендую - уши растут из стандарта :-)), как раз и позволяет не гадать, не загружать единички в избыточном кол-ве (а кстати, сколько это - избыточное количество для конкретно взятой серьезной цепочки?), а точно определить кол-во TAP'ов в цепи. Прочитайте внимательнее.

В результате описанной процедуры мы имеем пока описание JTAG-chain'а в виде последовательности TAP'ов, каждый из которых представлен либо 1) BYPASS rg (в свою очередь, представлен одиночным "0" в выходной последовательности), либо 2) ID rg (представлен 32-битовым кодом, младшие 2 бита которого по стандарту д.б. "01"). Теперь для тех TAP'ов, для которых известен ID, можно определить производителя и модель чипа. Для тех же, которые ID не имеют - придется все же провести небольшой reverse engineering для сопоставления конкретного чипа (с конкретной маркировкой ;-)) конкретному TAP'у в цепочке. Но, сдается мне, что все более-менее современные чипы ID-регистр содержат, так что к последнему варианту вряд ли придется прибегать.

Ну, а коль скоро мы сопоставили каждому TAP'у производителя и модель чипа, можно доставать из Web'а соответствующие bsd-файлы, в которых описана масса другого интересного: и длина регистра команд, и коды команд (по крайней мере, public-команд), и полное описание всего boundary scan регистра, и многое другое. А дальше - все зависит от конечной цели...

Да, согласен, я упустил из вида что при Test-Logic-Reset идет инициализация на такую цепочку регистров. (При попытке самостоятельно настроить такую цепочку моим методом я наткнулся на проблему "неизвестен код команды IDCODE", пришлось решать задачу перебором). Любопытный факт, попробую такой автоопределитель добавить в свои JTAG-утилиты.

Как говорится - случай классический - RTFM Рад, если смог чем-то помочь.