Всем привет! Столкнулся с такой проблемой: есть плата на присутствует следующая цепочка XCF32 -> Virtex-4 FX140 -> IDT72T18125 (FIFO). Соединенны правильно) Подключаю Xilinx USB Platform Cabel II, запускаю iMPACT 13.3, пытаюсь инициализировать цепочку и вместо ожидаемых устройств получаю Unknow Bypass... Кто-нибудь сталкивался с похожими проблемами? Хотел добавить, что на предыдущей реализации платы FIFO в цепочке отсутствовало, так что валю все на него, но возможности его закоротить нет, к сожалению, только выпаять, а это не желательно.

А что iMPACT'овский JTAG debugger показывает при прогоне запроса IDCODE?

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

Два джампера пожалели поставить - и вот результат.

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



Тест не проходит

ERROR:iMPACT - Bsdl reader is not available for device 1.
The bsdl for device 'unknown' is out of date. Please check your installation.


Снятие осциллограммы на пине TDO разъема JTAG (это как раз выход TDI FIFO) показало следующие, переход из 1 в 0, затем несколько коротких посылок, пауза в ~50мс (JTAG 1.5 МГц), затем еще посылка и переход в 1. Посылки сопровождались импульсами на TCK.

видимо Вы не включили jtag в fifo. Это нужно управлять сигналом TRST.

TRST is an asynchronous reset pin for the JTAG controller. The JTAG TAP controller does not automatically
INPUT reset upon power-up, thus it must be reset by either this signal or by setting TMS= HIGH for five TCK cycles.
If the TAP controller is not properly reset then the FIFO outputs will always be in high-impedance. If the JTAG
function is used but the user does not want to use TRST, then TRST can be tied with MRS to ensure proper
FIFO operation. If the JTAG function is not used then this signal needs to be tied to GND.

Уже была такая мысль, посмотрел схему, там TRST соединен с MRS и подключен к выводу ПЛИС без всяких утяжек, т.е. по идеи на нем Z. Пробовал через импакт подать последовательность 5 TCK при TMS=1. Не помогло. А соединение между всеми вывода разработчик заботливо упрятал во внутренние слои(((

просто 1 попробуйте хотя бы на TRST.

У ПЛИС и FIFO BGA корпуса, и все соединения выполнены во внутренних слоях. Сейчас посмотрю на тему подпайки к переходному отверстию.

Подождите паять...
Для начала уменьшите частоту работы по JTAG хотя бы на порядок ...
Посмотрите что получится... Посмотрите осциллом импульсы данных и клоков. Может быть они имеют плохие фронты и на высокой частоте работать не будут...
Проверьте, как сделано согласование по импульсам и какую предельную частоту могут дать микросхему в цепочке...
Дайте "байпасс" и хотябы просто погоняйте импульсы...

Частоту уже понижал до 750 KHz, дальше некуда , ФИФО должно на 10 МГц работать, а связка память+плис на прошлой плате без проблем работала и на более высоких. Импульсы смотрел, форма нормальная, завалов и прочих бяк не обнаружено. Плату отдал на доработку. Может заработает)

Дело в том, что "10 МГц работать" - это когда сигналы щупами подаются на микросхему без платы. А на плате 3-х вольтовые сигналы запустить даже выше 1 Мгц бывает трудно...
Напишите, как дело пойдет...

Подтяжка TRST и MRS к питанию через 4к не помогла(((

А логи на различные тестовые команды iMPACT'а можете привести? Он же в консоль не только сообщение об ошибке пишет, но и подробности вроде - что засылал, что получил...

Ну извините. Пошлите письмо с белым порошком разработчику платы.
Если до TDO что-то добегает и фронты культурные, то для начала стоит проверить другой экземпляр платы. Может где-то неприпай ног или битая микросхема. Вторым этапом будет изучение сигналов на линиях JTAG-а при помощи логического анализатора и разучивание машины состояний перед сном. Я это в своё время проходил. После недели тренировок читал команды прямо с экрана анализатора и находил ошибки.

Ok

Попробовал добавить устройства вручную, при помощи 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

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

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

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

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

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

Идем дальше.

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

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


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

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

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



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

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

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

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

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

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

Пока непонятно. Без схемы не скажешь точно, но скорее всего, это говорит лишь о том, что у данной точки хорошая связь с дальнейшей цепью, к которой подключен 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 там.

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

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

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

Поздравляю.

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

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

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


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

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

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


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

1. JTAG попросту подгорел но выходам-входам.
2. Не совместимость старого Platform Cable USB с Windows 7 64.
3. Не совместимость старого Platform Cable USB с последними версиями Xilinx ISE Design Suite.

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


SN74AUP3G34 или SN74AUC2G34 с объединенными входами - это дорого, много места занимает и потребляет?


В очередной раз убеждаюсь, что большинство не означает правильно.

Для начала - уменьшите fTCK до более адекватных 1-3 MHz (а для проверки принципиальной работоспособности - до предельно низких возможных, ну, скажем, до 50-100 kHz).


Ну, это уже философский вопрос. Какие дополнительные гарантии нужны, если после проверки на серии образцов все прекрасно работает? И в похожих решениях вокруг тоже. Гарантии в дополнение к этому - дополнительная цена (в широком смысле - чипы, место на плате, потребление и т.п.). Зачем платить больше, если область применения такой маниакальности не требует?


В сравнении с резисторами? Шутите!


Большинство в данном случае означает еще и некоторую статистику применения, что имеет значение IMHO.

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


Сигналы напрямую идут на флеш XC1802VQ44, за ней стоит XC2S200.

В соответствие с IEEE 1149.7, рекомендуют
1) Для схем разветвления типа "звезд" X, T и TX выравнивать длины, рассчитывать резистор для последовательного согласования источника в зависимости от количества потребителей, ставить дополнительные резисторы для изоляции входных емкостей, симулировать.
2) Буферизовать тактовый сигнал, особенно в случаях, когда используются микросхемы без встроенного механизма улучшения электромагнитной совместимости (slew rate, impedance matching).

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

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

Лучше приведите полный лог iMPACT'а при прогоне, скажем IDCODE для одного из устройств в цепочке, или определите правильный кабель в HW настройках, и потом приведите полный лог энумерации JTAG цепочки.

В общем, побольше информации из логов, но только с корректным пояснением, в каких условиях они снимались.

Кстати, чтобы сразу разделить проблему: а на данном экземпляре платы LPT-кабель все распознает корректно, или с ним тоже проблемы?

В том-то и проблема. До этого я работал с Parallel Cable III. Ни каких проблем с ним нет. Все отлично работает и программируется. Распознается.
Тут принесли Platform Cable USB. Воткнул его и ничего. Мертво все. Лог соединения кабеля я приводил выше. Пробовал на разных скоростях.
Может просто, где-то принципиально ошибаюсь? И подключения Parallel Cable III и Platform Cable USB различаются.
Вот кусок схемы:

Ну, уже что-то понятно. Значит, принципиально JTAG на плате рабочий. Проблема только с USB кабелем.


Нет, подключение принципиально не должно отличаться. Если, конечно, все необходимые подтягивающие резисторы установлены, как это и положено, на "принимающей" плате. И ее функционирование в этом смысле не зависит от JTAG-кабеля (от того, есть или нет соответствующие резисторы на стороне кабеля). У вас никаких положенных, вообще-то, резисторов нет и в помине - все JTAG сигналы напрямую подключены к разъему, и все. Не исключено, что параллельный кабель резистор(ы) имеет, а USB-шный - нет.

Но это только одна из версий, лежащая на поверхности. Все же, как правило, всю эту JTAG братию не так легко сбить с пути истинного. Но в китайских кабелях бывают непропаи контактов (например, того же TDO) - вот и вариант для наблюдаемого эффекта.

А чтобы точнее определиться - нужны дополнительные логи, с конкретными последовательностями 0./1 на входе и выходе. iMPACT выдает такие. Возможно, при других исходных данных и в ответ на другие команды, но точно выдает (посмотрите, например, более ранние сообщения из этого же топика).

Кстати, из лога следует (если я не отстал от жизни), что шефство над кабелем пытается взять Digilent plugin, а это вовсе не родной драйвер для Xilinx USB Platform Cable (а, видимо, Digilent'овский для их USB-JTAG наплатного модуля). У вас точно родной Platform Cable? Все ли правильно у вас определяется по USB драйверной части?

В общем, попробуйте вначале добиться соответствия между реальным железом (USB Platform Cable) и тем, как он распознался в iMPACT'е. Попробуйте проделать все так, как в соответствующем Application Note об установке USB Platform Cable говорится (только поищите свежую инфу, адекватную вашему ISE - драйвера могли поменяться).

В общем, после влезания с осциллографом куда надо и не надо было выявлено, что в кабеле погорел входной компаратор на TDO.
Всем спасибо за помощь.