xilinx jtag, много устройств в цепочке Опции

[rv3dll(lex)]

есть проблема

в одной цепи житаг соединены до 48 одинаковых плат. на каждой плате 2 житаг устройства virtex4 и xcf08p и того под сотню устройств в одной цепочке. усилители параллельных сигналов житаг сделаны на цплдшках.

до 16 плат ещё както работает раз с 10 можно умудриться прошить все пзу. после 16 вообще ничего не работает.

кто-нить вообще помногу соединял?

[iosifk]

есть проблема

в одной цепи житаг соединены до 48 одинаковых плат. на каждой плате 2 житаг устройства virtex4 и xcf08p и того под сотню устройств в одной цепочке. усилители параллельных сигналов житаг сделаны на цплдшках.

до 16 плат ещё както работает раз с 10 можно умудриться прошить все пзу. после 16 вообще ничего не работает.

кто-нить вообще помногу соединял?

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

[rv3dll(lex)]

пробовали и уменьшать и повышать - ничем не отличается . причём даже есть такое, что при увеличении частоты до максимума иногда проскакивает с первого раза

[iosifk]

пробовали и уменьшать и повышать - ничем не отличается . причём даже есть такое, что при увеличении частоты до максимума иногда проскакивает с первого раза

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

[rv3dll(lex)]

применительно к версии с 16 платами.
эти платы стоят в объединительной стойке и фактически воткнуты в кросс плату. на этой кросс плате стоит 95 цплдшка в которой на каждые 4 платы разветвляется тмс и тск через цплдшку а тди и тдо проходят от платы к плате напрямую и всё это выходит на разъём. осциллографом тыкались вроде разветвитель на цплдшке сдвигает эти сигналы на одну величину - наносекунды.

питание 3.3 на платы в параллель а вторичные для плис и 1.8 для пзух у каждого своё

Сообщение отредактировал rv3dll(lex) - Mar 15 2010, 08:53

[dvladim]

Может параллельные сигналы приходят со сдвигом?

А вот это как раз без разницы, недаром TDO меняется по заднему фронту, а TDI и TMS защелкиваются по переднему.

[rv3dll(lex)]

чем длиннее кабель от чекера до USB тем лучше работает

[o_khavin]

чем длиннее кабель от чекера до USB тем лучше работает

Отражёнка однака. Если её правильно побороть - проблем нет. Несколько лет назад я участвовал во вполне успешной реализации проекта, где несколько десятков Xilinx-ов грузились через JTAG.

[rv3dll(lex)]

поподробнее можно?

[o_khavin]

поподробнее можно?

А что подробнее?
Про то, что такое отражённые фронты и как с ними бороться? Так я в этом детально не разбирась т.к. занимаюсь исключительно цифрой. Но классический метод, это посмотреть осцилографом на jtag-их ногах загружаемых чипов (или близко от них) и осмыслить увиденое на предмет соответствия требованиям из соответсвующего даташита. Просто симптомы очень похожи: зависимость от длинны провода, парадоксальная реакция на увеличение частоты...
Или подробнее про проект, где я это всё наблюдал? Давно это было... к тому же я PCB не занимался, только FPGA и USB-контроллером, через который прошивка шла. Единственное, что помню - у нас разветвелние tms/tck делалось на каких-то буферах, а не на CPLD-хе. Ну и терминация стояла для борьбы с отражёнкой. Может дело и не в отражёнке, а просто CPLD-хе мощи не хватает и фронты слишком завалены по приходу на чипы?
В любом случае осцилограф и длительная медитация помогут.
А через что прошивка идёт? Через стандартный кабель от Xilinx-а или что-то своё? Это я к тому, что пока мы не отладили код своего контроллера, то ловили множество самых разнообразных багов. Причём забавно то, что даже когда всё делали в точном соответствии с даташитом от Xilinx-а - оно не работало, т.к. сам Xilinx (это выяснилось путём подключения стандартного кабеля для прошивки в обход нашей схемы, и просмотром сигналов логическим анализатором) использует не совсем ту последовательность, которую рекомендует пользовать юзерам.

[rv3dll(lex)]

прошивка идёт через родной кабель. если цплдшка заваливает фронта, то на 750 килогерц всё бы работало

[yuri_d]

на этой кросс плате стоит 95 цплдшка в которой на каждые 4 платы разветвляется тмс и тск через цплдшку а тди и тдо проходят от платы к плате напрямую и всё это выходит на разъём.

Топология "звезда"? Если так, то в этом и есть проблема. Попробуйте переделать в точка-точка (сколько линий TCK, столько и драйверов должно быть). На самих платах тоже разветвлений не должно быть. Ну и согласовывать на обоих концах линии нужно.

Нужно вылизывать TCK. Звон на остальных линиях JTAG-а не мешает.

[vitan]

Нужно вылизывать TCK.

И TMS тоже.

[dvladim]

Нужно вылизывать TCK. Звон на остальных линиях JTAG-а не мешает.

И TRST, если подключен. TMS - нет.

[rv3dll(lex)]

насчёт звезды не понятно как это влияет.

кстати кончик из схемы 3.3 вольта, который нужен для питания выходных каскадов жтаг имеет фильтр внутри???

и ещё насчёт длины провода вы не поняли. длина usb кабеля влияет на работу.

[yuri_d]

насчёт звезды не понятно как это влияет.

Посмотрите рекомендации из Virtex-4 FPGA Configuration User Guide UG071 для CCLK. Помоделируйте в каком нибудь симуляторе. Например в том же HyperLinx.

На пальцах это так: Предполагаю, что используется XC95xxXL в режиме VIO=2.5В. Типичное волновое опротивление дорожки от 50 до 100 Ом. Пусть будет 80. Тогда при соединении звездой с 4 лучами имеет нагрузку на выходе драйвера CPLD в 20 Ом. Используя IBIS модель получаем для фронта сигнала перепад 0В -> 0.64В и для спада имеем 2.5В -> 1.35В. Ни в том, ни в другом случае сигнал не перешел из одного логического состояния в другое. Сам переход будет проходить долго и мучительно. Сигнал будет отражаться от конца линии, бежать обратно, снова отражаться, и так далее пока не достигнет конечного уровня. Длина лучей у звезды разная, значит приходить отраженные сигналы будут в разные моменты времени. В результате будем иметь не монотонное изменение сигнала, что может быть воспринято входной частью Virtex4 как несколько тактовых импульсов.

[rv3dll(lex)]

Посмотрите рекомендации из Virtex-4 FPGA Configuration User Guide UG071 для CCLK. Помоделируйте в каком нибудь симуляторе. Например в том же HyperLinx.

На пальцах это так: Предполагаю, что используется XC95xxXL в режиме VIO=2.5В. Типичное волновое опротивление дорожки от 50 до 100 Ом. Пусть будет 80. Тогда при соединении звездой с 4 лучами имеет нагрузку на выходе драйвера CPLD в 20 Ом. Используя IBIS модель получаем для фронта сигнала перепад 0В -> 0.64В и для спада имеем 2.5В -> 1.35В. Ни в том, ни в другом случае сигнал не перешел из одного логического состояния в другое. Сам переход будет проходить долго и мучительно. Сигнал будет отражаться от конца линии, бежать обратно, снова отражаться, и так далее пока не достигнет конечного уровня. Длина лучей у звезды разная, значит приходить отраженные сигналы будут в разные моменты времени. В результате будем иметь не монотонное изменение сигнала, что может быть воспринято входной частью Virtex4 как несколько тактовых импульсов.

это конечно всё может быть, только на 750 килогерцах длина линии, чтобы говорить про волновое сопротивлении и отражениях, которые будут куда-то приходить с разными фазами, должна быть десятки метров, но не сантиметров!

[yuri_d]

это конечно всё может быть, только на 750 килогерцах длина линии, чтобы говорить про волновое сопротивлении и отражениях, которые будут куда-то приходить с разными фазами, должна быть десятки метров, но не сантиметров!

Дело в том, что мы должны оперировать длительностью фронта сигнала на выходе драйвера, а не периодом повторения сигнала. Для XC95xxXL фронт меньше 1 нс (данные из IBIS файла). А это 7 см проводника для печатной платы для прохождения туда и обратно.

[vitan]

это конечно всё может быть, только на 750 килогерцах длина линии, чтобы говорить про волновое сопротивлении и отражениях, которые будут куда-то приходить с разными фазами, должна быть десятки метров, но не сантиметров!

Просто проверьте качество фронтов. Если есть немонотонность, то это, скорее всего, вызывает проблемы. Причина в этом случае в плохой, как правило, несогласованной линии передачи