У ксайлинкса это xapp224. Там тоже делают 4 опорных клока, сдвинутых на 90 градусов. Вопрос в другом - кто-нибудь реально пользовался таким способом передачи даных? И на сколько это надежно?

Ага, т.е. ксайлинкс тоже не умеет восстанавливать клок в явном виде, а использует чисто цифровой способ. А вы не видели среди xapp именно восстановления клока из потока данных?
Что касается надежности, то у меня сложилось впечатление, что альтера обычно честно прорабатывает свои реф.дизайны, и они работают, как описано. У них, кстати, можно запросить исходники этого проекта.
В принципе я не вижу в таком подходе ничего опасного - частота остается в пределах разумной (~200-300 Мгц), надо только внимательно смотреть на времянки и сообщения синтезатора и роутера - при 300 Мгц зазор между двумя фронтами (при 90 градусах сдвига) 0.8 нс. Схема, которая выделяет переход уровня во входном потоке, должна быть простой, чтобы успеть за такое время.

Да, большинство примеров говорит именно об этом. Но есть xapp250, в котором они предлагают способ восставновления клока, но используют внешний элемент - VCO MAX2605. Мне этот вариант не нравится...



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

Будет время - обязательно попробую. Правда нужно еще найти на чем это сделать.

Этот вход, насколько я понимаю, - для высшего пилотажа. Чтобы ОС делать снаружи плис - это для особых извратов.
Насколько я читал хэндбук на стратикс2, эта штучка называется DPA (dynamic phase alignment). Но это никак не значит, что входная частота не восстанавливается. Это нужно чтобы угадать правильный момент "защёлкивания" данных в сдвиговый регистр. А про восстановление клока из данных ничего не говорится: может и заработать, поскольку это отдельная задача, с DPA никак не связанная.

Поправка, не NRZ, а NRZI. Вообще же битстаффинг заметно более эффективен, чем старт-стоппные кодировки (типа 8/10): он "сжирает" меньше полосы канала, при этом создает лучшие условия для PLL. Восстановление клока после битстаффинка в принципе не отличается от 8/10.


Не-а. Реализовать в FPGA восстановление клока можно. Термин для гугления CDR - Clock and Data Recovery. Есть FPGA со встроенными serdes, способные на это, например, у Алтеры - Меркурий. Однако они стоят хрен знает сколько.

Есть и другой путь. У Алтеры на эту тему есть пара аппликух и референс дизайн на Верилоге, где при помощи Стратикса или Циклона делается CDR из видеопотока SDI (270 Mbps) или HD-SDI (почти полтора гига), с полным декодированием. Фокус состоит в том, что используется оверсамплинг 3/2 или 5/4. Однако как это реализовать на практике - не так уж очевидно, для этого надо выходить на уровень фиттера и логических элементов, чего я лично, например, пока не умею.

Почему вы считаете 8В/10В стартстопной кодировкой? Насколько я знаю - это непрерывный поток бит, просто закодирован так, чтобы больше 3х нулей или единиц подряд не встречались. А вот стартстопные кодировки - применяются в аппаратных сериализерах-десериализерах ЛВДС, о которых упоминалось в этой теме ранее. Там именно стартовый и стоповый биты, отличающиеся по форме от бит данных. Так что, на мой взгляд, мы с вами либо по-разному понимаем термин "стартстопный" либо вы не полностью представляете кодировку 8В/10В

Очень может быть. Я имел ввиду аппаратные сердесы, где к 10 бит данных привешивается старт-бит в начале и стоп-бит в конце. С какого бодуна я их обозвал 8/10? Сработала ассоциация с UART-ом, где обычно к 8 бит данных привешивается старт-бит в начале и стоп-бит в конце.

PS: Посмотрел 8b/10b. Замысловатый код, однако эффективность использования полосы канала такая же, как у стартстопных, т.е. хуже чем у битстаффинга. В отличие от старт-стопных, 8b/10b позволяет обнаруживать одиночные ошибки, а также дает сбалансированное кол-во 0 и 1, что важно для транформаторной развязки. В общем, эзернетовский прикол, там ему и место, имхо.

Не позволяет.

Если не затруднит, дайте ссылку на алгоритм организации битстаффинга в USB.

Восстановить клок и данные при передаче в ЮСБ-подобной системе очень легко. Главное выдержать соотношения частоты передачи, частоты приема и максимального количества оодинаковых бит, после которых вставляется противоположный.

Описано в стандарте на http://www.usb.org/developers/docs/

http://iram.cs.berkeley.edu/serialio/cs254/enc_dec/
The IBM 8B/10B encoding scheme exhibits all the desired behaviors. It guarantees a maximum run length of 5 bits; the lowest transition density that can be indefinitely maintained under the encoding scheme is 30 transitions per 100 bits; it can detect all single-bit and many other errors; it contains three different comma characters. The encoding scheme also exhibits some interesting characteristics that are not especially useful in this application. These include the dc-balanced property: the coding scheme generates a bit stream with a balanced number of '1' and '0' bits.

Это ошибка в описании. Нигде больше про это не говориться. Действительно, по коду 8/10 можно обнаружить некоторые ошибки. Но говорить, что он обнаружит все ошибки, нельзя.
Например привожу 10 битный код для двух символов:
K28.3 001111 0011
K28.4 001111 0010 - ошибка в младшем бите не будет обнаружена.


P.S. Может я все-таки не прав?

Сообщение отредактировал dsmv - Mar 7 2006, 13:47

Думаю, что не ошибка :)
Прошу прощения за тавтологию, но ошибка в младшем бите будет обнаружена, т.к. есть еще "running disparity", который вы измените поменяв бит, единственное, что ошибка обнаружится только при приеме следующего слова. К тому же любая нарушающая баланс ошибка, а не только одиночная, будет обнаружена :)