Синхронизовать две DE0 борды на 450МГц Опции

[iiv]

Всем привет,

есть две терасиковские борды с EP4CE22F17C6, на каждой из которых работает идентичный дизайн на частоте 450МГц. Сам дизайн прост, поэтому удалось выйти на такую частоту, на ней же хочется оставаться. В дизайне есть основной клок (450МГц) и счетчик по этому клоку. Счетчик двухступенчатый, первая ступень - 2-х битная, а по переполнению счетчик клочит второй счетчик (44Бит) на 450/4МГц частоте. На платах есть свои 50МГц осцилляторы, использовать внешние осцилляторы не хочу. Мне необходимо синхронизировать оба счетчика с обеих плат (пусть с какой-то фиксированной фазой) и удерживать такую синхронизацию бесконечно долго (счетчик переполняется за 40 часов, вот это для меня означает бесконечно долго).

Физически для такой синхронизации я могу задействовать не более 10 ног каждой плисины через JP3 (2x13) коннектор. Длина провода, если постараться, будет не более 10см, но ни о каких лвдсах, к сожалению, мечтать не приходится. Дополнительно хотел бы сказать, что вокруг не сильно благоприятные электромагнитные условия, то есть этот проводок между плисками, хоть я и заэкранирую, может случайно что-то словить из окружающей среды.

Реально никогда с таким не сталкивался, и прошу совета, как правильно поступить. Железо поменять не смогу - не реально.

Вижу одно из решений:

первая плисина

Код

input CLOCK_50;
inout [12:0] GPIO_2;

my_pll1 my_pll1_module(.inclk0(CLOCK_50) /*50МГц от кварца*/, .inclk1(GPIO_2[2]) /* вход 450МГц от соседней плиски*/,
.c0(GPIO_2[0]) /* 450МГц на соседнюю плиску*/, .c1(GPIO_2[1]) /* еще один выход с 450МГц клоком на соседнюю плиску*/);

wire [1:0] FastCounter;
wire         MyClk;

assign FastCounter=GPIO_2[3:4];
assign MyClk=GPIO_2[0];

always @(posedge MyClk) FastCounter<=FastCounter+1;

вторая плисина

Код

inout [12:0] GPIO_2;

my_pll2 my_pll2_module(.inclk0(GPIO_2[0]) /*первый 450МГц вход от соседний плиски*/, .inclk1(GPIO_2[1]) /*второй 450МГц вход от соседний плиски*/,
.c0(GPIO_2[2]) /* 450МГц на соседнюю плиску*/);

wire [1:0] FastCounter;
wire         MyClk;

assign FastCounter=GPIO_2[3:4];
assign MyClk=GPIO_2[2];

Еще в железе не проверял, но вопрошаю, пожалуйста, посоветуйте, можно ли так, и что можно еще улучшить!

Спасибо!

ИИВ

[Raven]

А зачем передавать 450 МГц клоки и огребать все проблемы signal integrity, если можно передавать 50 МГц, и им синхронизировать внутренние PLL? Еще и фазу можно подстроить экспериментально под конкретный кабель, если очень надо.

[iiv]

Уважаемый Raven,

спасибо за ответ, да, я согласен, что 50МГц гораздо проще передать, и от него синхронизировать внутренние PLL.

Но есть несколько вопросов, которые меня в этом случае беспокоят:

1. точности 50МГц синхронизации мне, к сожалению, не достаточно. То есть дополнительно мне всяко надо будет хоть редко, но посылать синхроимпульс, например, на частоте 450/16 МГц.

2. У меня есть, к сожалению, отрицательный опыт работы SPI плиска-процессор именно в этом окружении, хотя SPI была только на 12МГц, очень редко, но клок почему-то пропускался.

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

Скажите, пожалуйста, правильно ли я понимаю, что, чтобы не потерять клок, вернее правильно верифицировать его потерю, можно сделать так:

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

Пожалуйста, посоветуйте мне что в этом случае надо/можно изменить или исправить, чтобы система была максимально отказоустойчивая и надежная?

Спасибо

ИИВ

[Raven]

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

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

спасибо за ответ, да, я согласен, что 50МГц гораздо проще передать, и от него синхронизировать внутренние PLL.

Синхро-клок может быть и на другой, более удобной частоте - 50/2, 50/4.

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

Так пропуск клока предполагается все-таки, просто его надо детектировать и реинициализировать систему? Что является событием "пропуск клока": пропуск 1 такта, 2-х, 3-х, N?

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

Не слишком ли вы усложняете? Как насчет такой схемы.
Board_1 (master) Board_2 (slave)
CLK_SYNC_OUT -> clk_sync -> CLK_SYNC_IN
CLK_INIT_OUT -> clk_init -> CLK_INIT_IN
CLK_FAIL_IN <- clk_fail -> CLK_FAIL_OUT

Board_1 - clock-master, Board_2 - clock-slave, между ними в направлении Board_1 => Board_2 идет CLK_SYNC (скажем, 25 МГц). Board_2 имеет способность способность детектировать пропуск такта/тактов CLK_SYNC (как минимум, а может детектировать и качество конечного клока тоже) на своей стороне, и сигнализирует об этом Board_1 через CLK_FAIL сигнал. Board_1 занимается контролем качества своего локального клока, и мониторит CLK_FAIL_IN вход. Если что не так - переинициализирует клок-схему, принуждая Board_2 сделать то же самое через CLK_INIT сигнал.

PLL вроде контролирует качество генерируемого клока и реагирует на срывы (у него есть выход типа CLK_OK). Точное поведение и характеристики надо, конечно, изучить по документации.

Для контроля пропусков локального 450 МГц клока (если это действительно нужно, и если PLL не делает эту работу), придется замутить какую-то схему.