[proton17 0]

Ну извините.

 

Ok :beer:

 

Попробовал добавить устройства вручную, при помощи bsdl файлов. Вот что получил при запуске Chain Integrity Test:

 

INFO:iMPACT - Current time: 13.12.2013 8:59:20

// *** BATCH CMD : CheckIntegrity

Maximum TCK operating frequency for this device chain: 10000000.

Validating chain...

INFO:iMPACT:1209 - Testing for '0' at position 94.The Instruction capture of the device 3 does not match expected capture.

INFO:iMPACT:1206 - Instruction Capture = '1111111111111111111111111111111111111111111111111111111111111111111111111111

111111111111111111111101'

INFO:iMPACT:1207 - Expected Capture = '10101010101010101010101010101010101010101010101010XXXXXXXXXXXXXX01XXXXXXXXXX

XXXX01XXXXXXXXXXXX011101'

INFO:iMPACT:2130 - Boundary-scan chain test failed . Please check tdi->tdo connection between device:'3' ( 'XC4VFX140') and device:'4' ( 'IDT72T18125').

A problem may exist in the hardware configuration.

Check that the cable, scan chain, and power connections are intact,

that the specified scan chain configuration matches the actual hardware, and

that the power supply is adequate and delivering the correct voltage.

 

Если запускать тест с одним только неизвестным устройством - импакт вылетает))

 

При попытке чтения DeviceID любого из добавленных вручную устройств получаю следующее:

 

INFO:iMPACT - Current time: 13.12.2013 9:02:34

// *** BATCH CMD : ReadIdcode -p 3

INFO:iMPACT:583 - '3': The idcode read from the device does not match the idcode in the bsdl File.

INFO:iMPACT:1578 - '3': Device IDCODE : 00001111111111111111111111111111

INFO:iMPACT:1579 - '3': Expected IDCODE: 00000001111100010100000010010011

 

Похоже, что физически цепочка жива, но какое-то из устройств явно валяет дурака.

Изменено 13 декабря, 2013 пользователем proton17

[Raven 8]

Давайте разбираться.

 

?? Цепочка у вас такая (проверьте!): JTAG_CONNECTOR.TDI => DEV1 (XCF32) => DEV2 (Virtex-4 FX140) => DEV3 (IDT72T18125 (FIFO)) => JTAG_CONNECTOR.TDO ??

 

Смотрим лог. Немного смущает вот это:

Maximum TCK operating frequency for this device chain: 10000000.

Если он здесь показывает реальную частоту, то надо бы понизить до предела вниз (50-100 кГц).

 

Идем дальше.

INFO:iMPACT:1206 - Instruction Capture = '1111111111111111111111111111111111111111111111111111111111111111111111111111

111111111111111111111101'

INFO:iMPACT:1207 - Expected Capture = '10101010101010101010101010101010101010101010101010XXXXXXXXXXXXXX01XXXXXXXXXX

XXXX01XXXXXXXXXXXX011101'

1) iMPACT считает, что у вас 4 устройства в цепочке, а не 3. Вернее, в цепочке 4 TAP'а. Нет ли устройств с 2 TAPами? Или вы что-то упустили? Цветовой код такой: CONN.TDI -> TAP1 -> TAP2 -> TAP3 -> TAP4 -> CONN.TDO, коричневым я выделил последовательность (хвост), которую софт вдвигает.

2) Ближайшее к выходу устройство честно выдает содержимое своего 4-битового IR, зафиксированного при прохождении Capture-IR. От остальных, дальше по цепочке, отклика нет. В связи с чем iMPACT и предлагает проверить соединение TAP3 -> TAP4

INFO:iMPACT:2130 - Boundary-scan chain test failed . Please check tdi->tdo connection between device:'3' ( 'XC4VFX140') and device:'4' ( 'IDT72T18125').

3) После этого вполне закономерно, что IDCODE от TAP3 не будет получен:

INFO:iMPACT - Current time: 13.12.2013 9:02:34

// *** BATCH CMD : ReadIdcode -p 3

INFO:iMPACT:583 - '3': The idcode read from the device does not match the idcode in the bsdl File.

INFO:iMPACT:1578 - '3': Device IDCODE : 00001111111111111111111111111111

INFO:iMPACT:1579 - '3': Expected IDCODE: 00000001111100010100000010010011

 

Так что с выводом

Похоже, что физически цепочка жива, но какое-то из устройств явно валяет дурака.

согласится не могу - явно есть проблема неконтакта (как минимум, одного).

 

[proton17 0]

Устройства в цепочке 4 (два xcf32p). Цепочку я задавал вручную так как автоматом она не определялась. Частота пробника 750 кГц. Проблему локализовал путем сдирания маски с переходных отверстий под BGA ПЛИС и ФИФО: с ПЛИС не идет TDO, а висит на 3 вольтах, TCK, TMS, TDI до переходных отверстий ПЛИС доходят. Пока предполагаю отсутствие контакта одного из этих 3 сигналов и самой ИС. Думаю как найти еще какое-ть косвенное подтверждение этой теории перед тем как связываться с рентгеном. Закоротки между шариками нет - смотрели в микроскоп.

 

?? Цепочка у вас такая (проверьте!): JTAG_CONNECTOR.TDI => DEV1 (XCF32) => DEV2 (Virtex-4 FX140) => DEV3 (IDT72T18125 (FIFO)) => JTAG_CONNECTOR.TDO ??

 

Только XCF32P - 2 шт.

[Raven 8]

С 4 TAPами разъяснилось.

 

Правильно ли я понял, что к переходным отверстиям с JTAG сигналами на FPGA вы доступ имеете?

[proton17 0]

С 4 TAPами разъяснилось.

 

Правильно ли я понял, что к переходным отверстиям с JTAG сигналами на FPGA вы доступ имеете?

 

У каждой контактной площадке под BGA корпусом есть переходное отверстие, оно закрыто паяльной маской, но счистить ее не проблема...

[Raven 8]

Тогда можно попробовать пролить больше света на то, что из TCK, TMS, TDI, TDO имеет контакт с чипом, а что - нет. До определенного предела, возможно.

[proton17 0]

Тогда можно попробовать пролить больше света на то, что из TCK, TMS, TDI, TDO имеет контакт с чипом, а что - нет. До определенного предела, возможно.

 

TDO точно имеет, на нем 3 вольта висит, а с остальными не понятно. На TMS/TCK вообще странные 0.8-1 вольта висят...

[Raven 8]

TDO точно имеет, на нем 3 вольта висит

Пока непонятно. Без схемы не скажешь точно, но скорее всего, это говорит лишь о том, что у данной точки хорошая связь с дальнейшей цепью, к которой подключен pull-up. А есть ли контакт с пином - ?

 

 

На TMS/TCK вообще странные 0.8-1 вольта висят...

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

 

Если подтвердится отсутствие контакта - можно проводочками пробросить TCK, TMS (т.к. они все равно в параллель разводятся по всем участникам цепочки). И проверить. Останутся TDI и TDO, но при рабочих TCK/TMS работоспособность TDO легко проверяется (должен выдать IDCODE после выхода из ресета и прохождения через DR-петлю). Останется только TDI. Такой вот маршрут локализации возможен.

[proton17 0]

Пока непонятно. Без схемы не скажешь точно, но скорее всего, это говорит лишь о том, что у данной точки хорошая связь с дальнейшей цепью, к которой подключен pull-up. А есть ли контакт с пином - ?

 

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

 

Если подтвердится отсутствие контакта - можно проводочками пробросить TCK, TMS (т.к. они все равно в параллель разводятся по всем участникам цепочки). И проверить. Останутся TDI и TDO, но при рабочих TCK/TMS работоспособность TDO легко проверяется (должен выдать IDCODE после выхода из ресета и прохождения через DR-петлю). Останется только TDI. Такой вот маршрут локализации возможен.

 

Спасибо за советы ;)

 

Я еще раз попробую более подробно описать схему и обобщить то, что сейчас удалось обнаружить: Xilinx JTAG connector (TDI) -> (TDI) XCF32P (TDO) -> (TDI) XCF32P (TDO) -> (TDI) VIRETX-4 FX140 (TDO) -> (TDI) IDT FIFO (TDO) -> (TDO) Xilinx JTAG connector

 

TMS и TCK от разъема расходятся звездой.

 

Утяжек ни на одном из сигналов нет.

 

Суть проблемы состоит в том, что при инициализации цепочки при помощи Xilinx iMPACT обнаруживается только одно unknow device. Создание цепочки вручную не помогает. Логи при инициализации и тестах цепочки есть выше.

 

Методом осцилотыка удалось обнаружить, что TCK и TMS приходят на все ИС (для ПЛИС и ФИФО это не совсем точно, так как в силу БГА-корпуса доступа к выводам нет, а только к переходным отверстиям рядом с площадками) и при отсутствии опроса имеют уровни ~0.8-1В (питание 3.3В)

А вот TDI от разъема доходит только до ПЛИС, а на ее TDO в независимости от информации на входе стабильно висит 3.3В

 

На выходе TDO ФИФО при опросе появляется некоторая ответная активность, как я понимаю это следствие появления TCK и TMS

 

Из выше сказанного мне наиболее вероятным кажется вариант отсутствия контакта между какими-то сигналами JTAG-а и выводами ПЛИС в следствии непропайки.

 

Имеется еще одна идентичная плата, но она вообще не запускалась в виду наличия КЗ между питанием ПЛИС (1.2В) и землей (( В понедельник буду искать причину кз и возможно удастся ее запустить и проверить JTAG там.

Изменено 13 декабря, 2013 пользователем proton17

[rloc 43]

TMS и TCK от разъема расходятся звездой.

Одна из стандартных ошибок при разводке JTAG. Многие думают, раз частоты низкие, можно разводить как угодно. А на практике, фронты сигналов остаются одинаково быстрыми при любой частоте, что приводит к отражениям, точнее к влиянию отражений. К этому следует добавить высокую чувствительность современных микросхем к пикосекундным импульсам. В итоге - на осциллографе все красиво, а цепочка не работает. На практике встречал ситуации, когда родным программатором Xilinx шьется без проблем, а через Digilent уже не видно, и дело, поверьте мне, совсем не в разном качестве программаторов. На будущее - сигналы TMS и TCK желательно разветвлять через буфера "один вход - несколько выходов", а сейчас остается только экспериментировать с навешиванием емкостей.

[proton17 0]

Ну там не совсем звезда, скорее рогатка), разъем -> пзу -> пзу -> плис, а вот отвод на фифо сделан отдельно с разъема. Дистанции не более 5 см

[proton17 0]

Ура! Проблема решена! Спасибо всем за советы) Трабл оказался вовсе не в JTAGе. На новую плату решили добавить разъем для подключения модуля расширения с дополнительной конфигурационной ПЗУ, и выход CF_ (идет на вход PROG_ ПЛИСы) с нее завели через КМОП буфер объединив его с выходами типа ОК на штатных микросхемах ПЗУ и мониторе питания. На выходе буфера установился лог.0 и держал ПЛИС под постоянным сбросом. Буфер убрали - все сходу заработало.

[rloc 43]

Буфер убрали - все сходу заработало.

Поздравляю.

 

Добавлю краткую ремарку.

Дистанции не более 5 см

Есть у меня модуль, состоящий из двух плат, стыкующихся между собой через один большой разъем. Общая структура такая:

JTAG1->Плата1->Разъем->JTAG2->Плата2->ПЛИС->ПЗУ

Вся цепочка идет строго последовательно, в рабочем режиме - через JTAG1, в режиме отладки - Плата2 отдельно через JTAG2. Плата1 только транслирует соответствующие линии. Общая длина линий по Плата1 составляет ~3 см, по Плата2 - ~5 см, Разъем и JTAG2 расположены вплотную друг к другу. Как уже догадываетесь, ПЛИС и ПЗУ не программируются только в одном случае - через JTAG2, когда две платы состыкованы между собой. Т.е. длины линий в 3 см вполне достаточно, чтобы сделать цепочку не работающей.

[Raven 8]

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

С этим полностью согласен. Однако с отражениями, по идее, должны успешно справляться резисторы последовательного согласования, устанавливаемые у выходов-источников сигнала. И снижать уровень переотражений в нагрузку до приемлемого уровня (чтобы не было значимых 'сёдел' на фронтах, во всяком случае). Другое дело, что они не всегда имеют подходящее сопротивление.

 

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

Такой подход (с буферизацией 1:N) - это, конечно, правильно, и точно должно убивать проблему на корню, но и дороговато. С другой стороны, почти вся схемотехника evaluation boards, с которыми имел дело, не имеет подобного. Причем, во всех этих случаях соображения экономии совершенно разработчиков не обременяли (учитывая цену плат и их основную задачу).

[Suho 0]

Здравствуйте.

В продолжении темы не работы JTAGa.

Принесли родной Platform Cable USB. Решил подключить его к плате. До этого работа с платой происходила через Parallel Cable III. Все нормально работало.

 

С Platform Cable USB выдает вот такой лог:

 

GUI --- Auto connect to cable...
// *** BATCH CMD : setCable -port auto
INFO:iMPACT - Digilent Plugin: Plugin Version: 2.4.4
INFO:iMPACT - Digilent Plugin: no JTAG device was found.
AutoDetecting cable. Please wait.
*** WARNING ***: When port is set to auto detect mode, cable speed is set to default 6 MHz regardless of explicit arguments supplied for setting the baud rates
PROGRESS_START - Starting Operation.
Connecting to cable (Usb Port - USB21).
Checking cable driver.
Driver file xusb_xlp.sys found.
Driver version: src=1029, dest=1029.
Driver windrvr6.sys version = 10.2.1.0. WinDriver v10.21 Jungo (c) 1997 - 2010 Build Date: Aug 31 2010 x86_64 64bit SYS 14:14:44, version = 1021.
Cable PID = 0008.
Max current requested during enumeration is 74 mA.
Type = 0x0004.
Cable Type = 3, Revision = 0.
Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 1303.
File version of C:/Xilinx/14.7/ISE_DS/ISE/data/xusb_xlp.hex = 1303.
Firmware hex file version = 1303.
PLD file version = 0012h.
PLD version = 0012h.
PROGRESS_END - End Operation.
Elapsed time =      0 sec.
Type = 0x0004.
ESN option: 000011775B2701.
Attempting to identify devices in the boundary-scan chain configuration...
INFO:iMPACT - Current time: 17.12.2013 12:15:49
// *** BATCH CMD : Identify -inferir 
PROGRESS_START - Starting Operation.
Identifying chain contents...done.
ERROR:iMPACT - A problem may exist in the hardware configuration. Check that the cable, scan chain, and power connections are intact, that the specified scan chain configuration matches the actual hardware, and that the power supply is adequate and delivering the correct voltage.
PROGRESS_END - End Operation.
Elapsed time =      0 sec.
// *** BATCH CMD : identifyMPM

Я тут для себя наметил несколько причин:

 

1. JTAG попросту подгорел но выходам-входам.

2. Не совместимость старого Platform Cable USB с Windows 7 64.

3. Не совместимость старого Platform Cable USB с последними версиями Xilinx ISE Design Suite.

Изменено 17 декабря, 2013 пользователем Suho