LVDS под одной паре (без клока), Cyclone10LP и Spartan7 Опции

[AVR]

Есть связь из Spartan 7 в Cyclone 10 LP по одной дифференциальной паре проводников (есть и обратная пара). Хочется понять, как действовать, если хочется передавать данные без передачи клока?
Допустим, задействую такой код 8/10, где байт будет передаваться так, чтобы хотя бы раз в три бита будет инверсия. Ведь сам поток данных это по сути прерывистые нерегулярные такты.
Или например, буду добавлять преамбулы в начала пакетов, escape-последовательности.

Вообще, реально ли какими-то алгоритмическими мерами и кодами, просто принимая поток с LVDS (от 10 до 400 Мбит/с, но каждый раз это константа), учитывая что тактовые не синхронные (хотя их стабильность 50 ppm) и плавают, что мы не знаем где центр глаза, как-то принимать данные, как-то делать обнаруживать битовые сдвиги и компенсировать их?

Нужно именно не задействовать хитрые режимы PLL, задержки, приемы на разных фазах, потому что возможности Cyclone 10 LP тут ничтожны. Или я ошибаюсь?

Опираюсь на бутылочное горлышко - на ту ПЛИС из этих двух, что имеет наименьшие возможности (C10LP), пусть будет единое со Spartan 7 решение.

[blackfin]

Это не решит проблемы если разбежка за пакет больше пары бит.

Не будет там такой "разбежки"..

У ТС клоки на обоих концах линка равны с точностью до 100 ppm. Из этого следует, что сдвиг на один бит случится после 10 тысяч бит. Меж тем, у ТС длина пакета 2048 бит. То есть, за время передачи пакета накопленная ошибка будет не больше 1/5 битового интервала.

... поток с LVDS (от 10 до 400 Мбит/с, но каждый раз это константа), учитывая что тактовые не синхронные (хотя их стабильность 50 ppm) и плавают, ...

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

PS. Только сейчас заметил, что у ТС длина пакета указана в байтах. То есть, в битах это 16384. Так что ошибка в один бит вполне реальна. Тогда только кодировка 8/10 и подстраивать момент выборки бита на лету..

[AVR]

Не будет там такой "разбежки"..
У ТС клоки на обоих концах линка равны с точностью до 100 ppm. Из этого следует, что сдвиг на один бит случится после 10 тысяч бит. Меж тем, у ТС длина пакета 2048 бит. То есть, за время передачи пакета накопленная ошибка будет не больше 1/5 битового интервала.
PS. Только сейчас заметил, что у ТС длина пакета указана в байтах. То есть, в битах это 16384. Так что ошибка в один бит вполне реальна. Тогда только кодировка 8/10 и подстраивать момент выборки бита на лету..

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

[blackfin]

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

Если вы откалибровались по преамбуле и длина пакета не превышает 2500 бит, то "реклокинг" внутри пакета уже не нужен. Можно также поставить более дорогие TXCO с лучшей начальной точностью и стабильностью. Скажем, 10 ppm будет не сильно дороже, а расхождение клоков на обеих сторонах линка будет в пять раз меньше. Как следствие, допустимый размер пакета будет тоже в пять раз больше.

[AVR]

Если вы откалибровались по преамбуле и длина пакета не превышает 2500 бит, то "реклокинг" не нужен. Можно также поставить более дорогие TXCO с лучшей начальной точностью и стабильностью. Скажем, 10 ppm будет не сильно дороже, а расходжение клоков на обеих сторонах линка будет в пять раз меньше. Соответстенно, допустимый размер пакета будет тоже в пять раз больше.

А что значит откалиброваться по преамбуле? Допустим, принимаю преамбулу, вижу ее смещение (у меня уже есть такое решение в модели) - определив величину битового смещения, начинаю кушать пакет. Что защищает от ситуации, чтобы не попасть на зону перехода, когда после приема 1250 бит пойдет зона на десятки бит, где битовое положение будет колбаситься туда-сюда из-за джиттера???

Протянули бы уже тактовый сигнал. Ради связи на 15 см столько фантазий.

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

[blackfin]

А что значит откалиброваться по преамбуле? Допустим, принимаю преамбулу, вижу ее смещение (у меня уже есть такое решение в модели) - определив величину битового смещения, начинаю кушать пакет. Что защищает от ситуации, чтобы не попасть на зону перехода, когда после приема 1250 бит пойдет зона на десятки бит, где битовое положение будет колбаситься туда-сюда из-за джиттера???

Ну, я ориентируюсь на xapp523. Там каждый бит данных семплируется четыре раза. При таком семплировании наибольшая ошибка в определении положения максимума в линии данных не будет превышать 0.25*UI. Далее вы начинаете принимать пакет, но поскольку клок на приемной стороне имеет систематическую ошибку, со временем возникает сдвиг между центром бита и временем семплирования этого бита. Джиттер здесь влияния не оказывает, так как его величина мала по сравнению с длительностью одного бита на частоте 400 МГц и он не приводит к систематическому смещению фронта данных.

Таково жесткое требование на данное устройство.
...
Но теперь я обязан убрать общий клок на приемной и передающей стороне, и не давать клок в параллель с данными.

А чем вызвано столь "жесткое требование"?

Для самопального много проще и компактнее по ресурсам будет принимать по всем фазам и выбрать правильные.
Пишем 8 потоков, а дальше пускаем только 1 из них с правильным контрольным кодом.

Не соглашусь. Проще и компактнее то, как описано у Xilinx'а в xapp523. Один конечный автомат на четыре состояния, один триггер для граничных условий и немного логики для управления этим автоматом. Этот метод, кроме всего прочего, позволяет подстраивать момент выборки бита на интервале меньшем десяти бит (для кодировки 8/10) и не зависеть от длины пакета в принципе. Ваш же метод при большой длине пакета может привести к ситуации, когда во всех восьми блоках памяти будут лежать данные с неверными CRC.

[AVR]

Не соглашусь. Проще и компактнее то, как описано у Xilinx'а в xapp523. Один конечный автомат на четыре состояния, один триггер для граничных условий и немного логики для управления этим автоматом. Этот метод, кроме всего прочего, позволяет подстраивать момент выборки бита на интервале меньшем десяти бит (для кодировки 8/10) и не зависеть от длины пакета в принципе. Ваш же метод при большой длине пакета может привести к ситуации, когда во всех восьми блоках памяти будут лежать данные с неверными CRC.

Скачал xapp523.zip размером 5138659 байт 75138e67fc7f40fda0e89e998214e645
Но там много пустых каталогов, нет файлов проекта, нет PDF-файлов с описанием. Вроде качал с официального сайта, но это странно очень.

xapp224.zip не могу нигде скачать, но подозреваю там другой метод и другая идея, которая не так хороша, как в xapp523 - верно?

Мне нравится xapp523, я почти уловил мысль, но не до конца. Там пример на 1250 мегабит SGMII, но я ожидаю, что могу взять не 8 а всего 4 фазы для этой идеи и обойтись лишь одним десериализатором (а не двумя, сдвинутыми на сколько-то пс при помощи IDELAY). Но нужно посимулить и понять идею глубже.

[blackfin]

Там пример на 1250 мегабит SGMII, но я ожидаю, что могу взять не 8 а всего 4 фазы для этой идеи и обойтись лишь одним десериализатором (а не двумя, сдвинутыми на сколько-то пс при помощи IDELAY). Но нужно посимулить и понять идею глубже.

С четырьмя семплами и одним десериализатором не получится следить за направлением смещения фронта данных относительно точек семплирования. В этом случае алгоритм "Bit Skip" работать не будет.

Иными словами FSM из рисунка 9 должен шагать строго по кругу - либо по часовой стрелке, либо против. Недопустимы переходы между состояниями "по диагонали"..

[AVR]

С четырьмя семплами и одним десериализатором не получится следить за направлением смещения фронта данных относительно точек семплирования. В этом случае алгоритм "Bit Skip" работать не будет.
Иными словами FSM из рисунка 9 должен шагать строго по кругу - либо по часовой стрелке, либо против. Недопустимы переходы между состояниями "по диагонали"..

Так, похоже идея работать не будет, потому что в C10LP нет такого элемента как задержка входного сигнала на X пикосекунд. Где-то даже читал на форумах альтеры ответ сотрудника что типа "а нафига это теоретически было бы надо". К тому же не знаю, можно ли подать с одного входа на два десериализатора в C10LP задав соответствующие констрейны чтоб не расползалось.

[blackfin]

Так, похоже идея работать не будет, потому что в C10LP нет такого элемента как задержка входного сигнала на X пикосекунд.

А в чем смысл скрещивать ужа Altera и ежа Xilinx в одном проекте? Страсть к мазохизму?