Входной поток со скоростью 270Мбит/с. Кодировка 8В/10В.
Если я подам на вход DCM тактовый сигнал с частотой 270 МГц, а на вход CLKFB данные, и на выходе триггер, тактируемый CLK180, то по идее данные должны восстанавливаться и одновременно тактовый сигнал будет подстраиваться под частоту потока данных. Смоделировал в ModelSim вроде работает, но будет ли это работать в железе? И еще вопрос - как определить начало прихода данных?

Я что-то не понял. Допустим, на вход идет поток данных 001100110011..., т.е. частота на CLKFB получится вдвое ниже, чем на CLKIN. Хотите сказать, что DCM не потеряет LOCK?

В ModelSim заложена очень упрощенная модель DCM'а. В реальности DCM - это полноценная петля ФАПЧ (точнее две ФАПЧ), имеющая как минимум фазовый детектор, интегрирующую цепочку и ГУН. Принцип работы ФАПЧ - это подстройка частоты ГУНа к частоте входного сигнала (в DCM). Так к чему будет подстраиваться частота DCM, если нет обратной связи? Возможны два варианта: либо частота DCM настроится на крайние частоты, либо DCM определит сбой и вообще отключит ГУН. Подавать на вход CLKIN поток 8B/10B также не имеет смысла т.к. в общем случае он псевдослучайный без выраженной спектральной составляющей на частоте 270M.

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

А на что Вам код 8B/10B? Как раз для того, чтобы корректировать ошибки.
Цитата из xapp224:

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

У Alterы года 2 назад был открытый проект - ASI интерфейс. Это теже 270MB/s последовательные данные с 8В/10В кодеком. Там прием осуществлялся на эквивалентной 3х270 или 5х270 MHz. Делается,
соответствено, 3 или 5 выборок и по мажоритарному принципу выбирается достоверная. Проверял - работает.

А где этот открытый проект можно глянуть? Подскажите буду признателен.

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

Пойщу у себя, найду дам знать.
Но на сайте Altera можно найти документацию, там принцип неплохо описан.

http://www.altera.com/products/ip/iup/addi.../m-alt-asi.html

Почитайте.

Из xapp 224
As discussed, the local clock will probably be a bit faster or slower than the incoming clock/data stream, and therefore, there will be clock cycle where the received data is either invalid (local clock faster) or two data bits will be required (local clock slower).
и
In an actual system, these events occur continuously

Похоже Вы еще не до конца разобрались. Поток, который идет с декодирующей схемы (см. Figure 6 из xapp224) нужно подавать на 10-битный сдвиговый регистр. Причем в подавляющем большинстве случаев в этот регистр нужно будет задвигать по 1 биту за такт, и иногда либо пропускать, либо задвигать сразу 2 бита за такт (надеюсь, как это делать, объяснять не надо). Как только накапливается 10 бит, подаете на вход схемы декодера 8B/10B, и получаете на выходе 8 бит. Для того, чтобы все это корректно работало, на странице 7 в разделе "Lock Requirements" подробно расписано, как частота появления ошибочного бита связана с разностью частот приемника и передатчика. Плюс прилагается еще исходный код, чтобы можно было это проверить на практике. Люблю Xilinx, всегда очень грамотно и понятно расписывают свои приложения.

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

Посмотрите, как Xilinx делает 1Gb Ethernet, можете кодер и декодер 8b/10b взять оттуда, или все остальное. Выудил из последнего IP1 для ISE v9.2i (расширение .rar потом удалить).
Нажмите для просмотра прикрепленного файла

Благодарю. Декодер 8B/10B я сгенерировал в CoreGenerator. А остальное гляну.


Еще один глупый вопрос. Что со скачаным файлом делать. Просто удалить .rar? А что это получится за файл?

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

Останется файл с расширением .7z (архиватор 7zip, к сожалению такое расширение не прикрепляется)

Я так понял на первый взгляд что приемопередатчик сделан на базе RocketIO? Просто мне для ASI интерфейса нужен только приемник. Там непрерывный транспортный поток MPEG2. Поэтому хотелось бы без использования RocketIO. Мне кажется я намучаюсь с его настройкой. Или я не прав?
Есть просто xapp514, там показано как они делают ASI. Так вот там два варианта: один из них на RocketIO. Так вот мне кажется что этот вариант посложнее, хотя может быть лучше.

Делали свой ASI приёмник для spartan. XAPP514 писал индус какой-то, лучше за основу брать альтеровский и делать свой блок восстановления данных, с выборкой через сдвинутые по фазе выходы DCM (линия задержки - плохое решение из-за сложностей с разводкой и разбросом задержек в разных кристаллах). Классика блока восстановления данных - XAPP224

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


На RocketIO конечно проще, да и скорости могут быть мультигигабитными. Но если делать на Spartan'е, то вариант только один - на внутренней логике. Разницы в качестве работы между двумя вариантами - никакой. Из даташита на 1Gb Ethernet PCS (физический уровень) написано:

Famaly With TBI Using RocketIO
Virtex-5 Supported Supported
Virtex-4 Supported Supported
Virtex-II Pro Supported Supported
Virtex-II Supported Not supported
Spartan-3 Supported Not supported
Spartan-3E Supported Not supported
Spartan-3A Supported Not supported

Т.е. для семейств Virtex-II Pro, Virtex-4, Virtex-5 можно использовать оба варианта, для остальных - только один (TBI - Ten-Bit-Interface) со внешним сериалайзером-десериалайзером.

У нас Virtex-5 будет. Так что наверное воспользуемся вашим советом и попробуем на RocketIO.
Спасибо за помощь.
P.S. Я думаю у меня будет еще много вопросов


Если не секрет - много времени ушло на разработку ASI? И сколько человек этим занималось?

Здесь возмите архиватор http://www.7-zip.org/

Спасибо я уже скачал

Делал я один - пару месяцев, правда ещё кроме этого работа была. Кстати, насчёт рокет, не смущает маленький битрейт ASI?

А что он не расчитан на такие маленькие скорости?

Ранее не был рассчитан, V-5 не смотрел. А что XAPP514 не весь прочли?

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

Я вот внимательно читаю и никак не могу понять, что же с этим блоком будет, когда фаза входного сигнала совпадет с фазой внутреннего тактового. Допустим, на А будет единица, а на B - фронт, который поймается как 0. Блок скажет - отлично, давайте работать по B и D, а на D тоже придется фронт, который поймается неправильно.

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

Ой. Видно я где-то сильно туплю. Там написано, что частота тактовой равна частоте в канале. Т.е если в точке А фронт, то B попадет на середину бита, в точке С будет фронт, и D попадет на середину следующего бита. Т.е. 4 точки на два бита. А чтобы 4 точки выборки на бит - так данные вроде вдвое медленее должны идти, т.е. при тактовой скажем 300 МГц данные 150 Мгц=300Мбод?

Частота тактовой может быть и равна, но выборка осуществляется сдвинутыми по фазе версиями тактовой - 0, 45, 90, 135 вот уже 4 точки, может и 8 точек сделать, если DCM позволяют (spartan 3e, например)

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

А почему 0, 45, 90 и 135? Я думал 0, 90, 180 и 270. Где я ошибаюсь?

Кстати ее один вопросик.
Прилагаемые к xapp224 файлы можно использовать как готовое решение или они только для демонстрации? А то я запустил на моделирование на 50МГц тактовой и 50.5МГц данных, так не правильно он как-то работает.

Перепроверил - все правильно работает.

Не ошибаетест правильно. Я привёл сетку для тактовой частоты вдвое меньшей битрейта сигнала (сам использовал такой подход для spartan)

Понятненько. Возник еще один вопрос. В xapp224 первые несколько байт не выделяются. В описании написано что вроде бы не определяются только первые 8 бит. Или это зависит от последовательности данных?

а может кто-нить ответить на следующий вопрос:
к примеру ситуация: приемник 8b10b включился несколько позже передатчика и начал считывать пакет из 10 бит где-то посередине. может ли приемник обнаружить служебную команду, если она не передана на самом деле? если теоретически возможно, то как тогда засинхронизироваться не переделывая текст передатчика? забыл отметить, от передатчика идет клок и 8b10b-кодированный сигнал/
кому интересно вот тут