День добрый.

В нашем девайсе используется Spartan-3, 400 киловентилей, Speed Grade -4. Большая часть схемы внутри тактируется от сигнала 120 Мгц, который вырабатывается из 12 Мгц на DCM-е.
Недавно обнаружилась проблема - этот модуль DCM иногда вдруг засыпает - перестаёт генерировать какой либо сигнал. Случается очень редко - только 2 раза замечал, но это полный П.
Вот так он подключается:

И входная и выходная частоты подключены к глобальным тактовым линиям.

Атрибуты в настроечном файле:
CLK_FEEDBACK = NONE
CLKDV_DIVIDE = 2
CLKFX_DIVIDE = 1
CLKFX_MULTIPLY = 10
CLKIN_DIVIDE_BY_2 = FALSE
CLKIN_PERIOD = 83.3333
CLKOUT_PHASE_SHIFT = NONE
DESKEW_ADJUST = SYSTEM_SYNCHRONOUS
DFS_FREQUENCY_MODE = LOW
DLL_FREQUENCY_MODE = LOW
DUTY_CYCLE_CORRECTION = TRUE
FACTORY_JF = 16'hC080
PHASE_SHIFT = 0
STARTUP_WAIT = FALSE

В связи с этим вопрос: это где-то проблема в настройках, или такое действительно бывает? И что с эти делать?

Такое случалось, когда форма входного сигнала была отвратительной.
И да, действительно, через некоторое время (как прогреется) DCM "уставал".

Возможно, необходимо согласовать источник клокового сигнала и вход Спартана. Если у входного сигнала есть ещё потребители, кроме одного Спартана, то соединять их и источник нужно равнолучевой "звездой" во избежание наложения отражённого сигнала (в нашем случае была ошибка при разводке и Спартаны "сидели" последовательно на клоке).

Также высока вероятность того, что период у источника входного сигнала сам по себе недостаточно стабильный. ( http://www.xilinx.com/bvdocs/publications/ds099.pdf , страница 86, таблица 59).

3) проблемы со стабильностью источника питания ( http://www.xilinx.com/bvdocs/appnotes/xapp...h=%22xapp462%22 , страница 64; XAPP462 весьма необходимый для вдумчивого изучения документ).

Использование одного только LOCKED сигнала для мониторинга CLKFX в Вашем случае недостаточно. Используйте STATUS[2] ( http://www.xilinx.com/bvdocs/appnotes/xapp...h=%22xapp462%22 , страница 9). Обратите внимание на условия установки '1'!!!

Сообщение отредактировал AlexB - Sep 19 2006, 22:44

Уточните как подключен вход FEEDBACK

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

AlexB
Спасибо, посмотрим, поизучаем.
> Если у входного сигнала есть ещё потребители, кроме одного Спартана, то соединять их и источник нужно равнолучевой "звездой" во избежание наложения отражённого сигнала...
> Также высока вероятность того, что период у источника входного сигнала сам по себе недостаточно стабильный.
Есть - на этом же сигнале 12 Мгц сидит ещё DSP TMS320VC55, работает на частоте 192 Мгц. Процессор и спартан на этом сигнале сидят параллельно, а сам генератор: HCJ-30 12.00 Mhz. Процессор при этом (когда DCM устаёт) работает нормально.

Вроде все (да и сам Xilinx рекомендует) делают автоматический
ресет на DCM в случае его отказа (своеобразный вотчдог).
Может и вам надо?

Было такое. В моем случае период синхронизации плавал.

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

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


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

Сообщение отредактировал AlexB - Sep 20 2006, 17:08

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

Инженер однозначно не прав.
Думать про отражения клока с быстрыми фронтами, поданного на высокочастотный вход, необходимо в любом случае - хоть 1 герц подавай. Звон линии не зависит от частоты клока - только от параметров самой линии и от скоростей фронтов.
Спросите у инженера, моделировал ли он "signal integrity" для этого клока. Если нет - ищите инщенера, который промоделирует и добьется нормального сигнала.

DCM работает минимум от 18 МГц входной частоты - см 83 страницу даташита на спартан 3.
А в спартане 2 - минимум от 25 МГц по-моему.

DCM работает минимум от 18 МГц входной частоты - см 83 страницу даташита на спартан 3.
А в спартане 2 - минимум от 25 МГц по-моему.

litv
Нет, это выходная частота не менее 18, а входная - не менее 1 Мгц.

Эпикур - читаем заново даташит. Четко же написано - входная частота CLKIN DCM от 18 МГц.

Попробуйте добавить в ISE COre_Generatorom - блок DCM из группы CLocking ну например с именем MY_DCM.

Поставьте входную частоту 12 МГц - прочитайте сообщение
(Сообщение - входная частота должна быть выше 18МГц).
Расчет окончен.

litv, Вам тоже надо внимательно в даташит посмотреть. Именно на той странице что Вы указали. Там таблица "Recommended Operating Conditions for the DLL" в которой параметр Fclkin не менее 18МГц, а рядом сноска (2) в которой написано "The DFS, when operating independently of the DLL, supports lower FCLKIN frequencies. See Table 34". Т.е если нужен только DFS, без DLL то входная частота может быть ниже. Ну а в таблице 34 тот же параметр Fclkin, смотрим: минимум 1 МГц.

Хех, опередили!
Добавлю, что для того, чтобы отключить DLL(использовать только DFS) и не получить ругань от корегена, нужно отключить feedback(none) и из выходов оставить только CLKFX и/или CLKFX180. Так что расчет не окончен.

Признаю - не знал. Думал что dll имеет общий принцип с dfs - оказывается разный.