Проверка работоспособности FPGA, Есть ли стандартный способ проверить FPGA? Опции

[Gothard]

Доброго времени суток!
Недавно возникла проблема на одной из плат и есть подозрение, что конкретный плис (Xilinx) частично неработоспособный.
В данный момент собираюсь сделать загрузку для диагностики сего явления, но возник вопрос - может есть какой-то стандартный способ? Например подключить JTAG и запустить утилиту, осуществляющую проверку FPGA на функциональность (типа заводской).
Понимаю, что в большинстве случаев сам дурак оказываешься и вероятность, что проблема с самим FPGA очень низка, но чем черт не шутит....

Если у кого-то были такие проблемы, поделитесь опытом пожалуйста

P.S. Питание проверял - на мой взгляд удовлетворительно. Да и плис, стоящий рядом и кормящийся от тех же источников, работает. Синхросигналы нормальные.
Подозрения на плис появились после того как первая загрузка для диагностики не работала (порт данных оставался в 3-м состоянии), а вторая загрука (были выведены некоторые внутренние сигналы на контрольные точки (т.е. наружу FPGA)) заработала в полной мере. Причем первая загрузка не работает стабильно, а вторая стабильно работает. Обе загрузки нормально работают на другой плате.

[DW0]

обратите внимание на отчеты по максимальным частотам, так бывает что одна ПЛИС немного шустрее другой, и на одной работает, другой нет.
если Вы выводите что-то на тестовые пины и проект начинает работать, то это свидетельствует о том, что произошла компиляция по другому, и это два абсолютно разных проекта и работают по разному.
еще важно заполнение, если более 70% то могут быть тоже проблемы на больших частотах

[Gothard]

обратите внимание на отчеты по максимальным частотам, так бывает что одна ПЛИС немного шустрее другой, и на одной работает, другой нет.
еще важно заполнение, если более 70% то могут быть тоже проблемы на больших частотах

Загрузка диагностики практически пустая, частота только 25 МГц, тайминги выполняются, никаких DCM.

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

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

[des00]

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

если корпус бга проверьте пропайку шаров.

[AJIEKCEu]

если корпус бга проверьте пропайку шаров.

Не совсем понятно, чем это поможет. Потому что:
1. Исходный проект - стабильно не работает.
2. Тестовый проект состоящий из исходного + некоторые дополнительные ноги _НА ВЫХОД_ - стабильно работает.

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

[DW0]

а кто является источником тактовой частоты? через PLL она пропущена???

[DS]

Не совсем понятно, чем это поможет. Потому что:

Питание / земля не до всех ног, например, доходит.

[Gothard]

Питание / земля не до всех ног, например, доходит.

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

А насчет стандартного способа проверки плиса на функциональность - выходит глухо?
Хотелось бы иметь возможность удостоверится, что дело не в плисе.

[MrYuran]

Загрузка диагностики практически пустая, частота только 25 МГц, тайминги выполняются, никаких DCM.

А боевая?
Пост-роут тайминг аналайз проводили? Нету узких мест?

[Gothard]

а кто является источником тактовой частоты? через PLL она пропущена???

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

А боевая?
Пост-роут тайминг аналайз проводили? Нету узких мест?

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

[des00]

Не совсем понятно, чем это поможет. Потому что:

я месяц просидел над платой, в вопросах почему от сборки к сборке не работает проект. Оказалось плохая пропайка земли/питания где то в центре плис. Сняли, поставили, все заработало %)

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

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

[DW0]

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

[x736C]

нужно через ПЛЛ пропустить синхрочастоту, она как фильтр работает и пропускает только то что надо.

Должно быть достаточно внутренней PLL (если она есть, конечно).

[Gothard]

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

Возможно у вас были проблемы с времянками передачи между плисами? С точки зрения синхросигнала и схемы на триггерах важно лишь иметь ровные фронты, уровни логического 0 и 1 и уложиться в setup/hold. PLL может сдвинуть (в конечном счете именно это она и сделает) фазу синхросигнала на триггерах и разброс задержек дерева синхронизации, чем поможет выполнить времянки.
В моем случае запасы параметров большие, синхросигнал наблюдаю хороший.

[DW0]

все стало хорошо после того когда каждая плисина стала работать со своим генератором.
В общем пришли к выводу, что когда без ПЛЛ (я имел ввиду и имею внутреннею) то генератор или пин немного дребезжит и некоторые, очень редкие, фронты расположены слишком близко, что вся внутренняя комбинационная логика успела завершить свои переходные процессы.
Если вы с генератора заводите на пин, а с пина, без внутреней ПЛЛ, синхронизируете с пина все или часть триггеров(регистров) то будете иметь проблему, причем это может быть вообще не рабочий, а может быть и раз в час в день один глюк, причем совершенно хаотично, без какой либо закономерности.

[des00]

Если вы с генератора заводите на пин, а с пина, без внутреней ПЛЛ, синхронизируете с пина все или часть триггеров(регистров) то будете иметь проблему, причем это может быть вообще не рабочий, а может быть и раз в час в день один глюк, причем совершенно хаотично, без какой либо закономерности.

у нас есть модемы, работающие от внешнего генератора без PLL, работают годами без каких либо проблем %)

[DW0]

у нас есть модемы, работающие от внешнего генератора без PLL, работают годами без каких либо проблем %)

Вы просто их можете не видеть, так как то что я замечал случалось не часто, и имело место восстановление, если там не было элементов памяти, плюс ко всему система регистрации каждого чиха позволило это выявить. Внешне все было без замечаний, но внутри были проблемы.
И это был циклон 2и циклон 1, с максами таких проблем не замечали.

и еще это повторялось абсолютно в разных проектах на циклонах

Сообщение отредактировал DW0 - Aug 18 2010, 09:45

[disel]

все стало хорошо после того когда каждая плисина стала работать со своим генератором.
В общем пришли к выводу, что когда без ПЛЛ (я имел ввиду и имею внутреннею) то генератор или пин немного дребезжит и некоторые, очень редкие, фронты расположены слишком близко, что вся внутренняя комбинационная логика успела завершить свои переходные процессы.
Если вы с генератора заводите на пин, а с пина, без внутреней ПЛЛ, синхронизируете с пина все или часть триггеров(регистров) то будете иметь проблему, причем это может быть вообще не рабочий, а может быть и раз в час в день один глюк, причем совершенно хаотично, без какой либо закономерности.

Вы просто не умеете их готовить Хороший клок и правильно заданный в констрейнах джиттер спасут вас от этих проблем. Все и без ПЛЛ может замечательно работать. И работает.

[des00]

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

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

[DW0]

disel скажите пожалуйста, джиттер это только настройкак или аппаратная заморочка, если аппаратная то как фильтр поможет, а если просто настройка с учетом которой компилятор оптимизирует задержки, то есть сомнения, я всегда использую встроенную ПЛЛ, это как правила хорошего тона.

[Gothard]

я всегда использую встроенную ПЛЛ, это как правила хорошего тона.

PLL работает только в определенном диапазоне частот и только на периодических сигналах. К тому же PLL может создать джиттер больший, чем был в исходном синхросигнале. Кроме этого при запуске (пока не произошла подстройка ГУНа) на выходе имеет некоторое время другую частоту, что тоже может добавить проблем, если не принять меры. Поэтому использовать PLL надо обосновано и с умом.
P.S. просто совет