Провёл следственный эксперимент :-)
Последовательно включил узлы encode8/10 и decode8/10
На вход подал тестовую последовательность и получил результат
Вход: код 10, выход
0x00 0x0B9 0x00
0x23 0x263 0x23
0x24 0x26B 0x24
0x23 0x263 0x23
0x24 0x254 0x24 - смена полярности

А вот теперь последовательность с ошибкой
0x00 0x0B9 0x00
0x23 0x263 0x23
0x24 0x263 0x23 - вот здесь ошибка
0x23 0x263 0x23
0x24 0x254 0x24 - смена полярности

Привожу временную диаграмму. Сигнал code_err это признак ошибки. Видно, что он не устанавливается.
d8_in - это входной байт
d10 - байт в кодировке 8/10
d10i - байт с ошибкой
d8_out - принятый байт
Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

Интересно, а откуда взялись эти узлы, на чем написаны? Можно их посмотреть?

Эти узлы собраны кодогенератором из ISE 7.1; Они у меня работают в реальной системе.
Могу их выслать, вместе с тестовым проектом.

Собственно вот тестовый проект.
Работает в Aldec ActivHDL 7.1

Да, эксперимент показал отсутствие ошибки. Но мы выше, ранее доказали, что ошибку обнаружить можно. Таким образом, можно высказать предположение, что сам алгоритм декодера несовершенен, не на 100% соответствует стандарту. (Лично я основываюсь на IEEE802.3, часть 3)

Я бы сказал по другому:
Эксперимент показал, что существуют одиночные ошибки, которые не могут быть обнаружены.
А то, что будут обнаружены ВСЕ одиночные ошибки, никто не обещал.

Не хотелось бы скатываться на банальные перепирательства, но теория всё-таки первична. Поэтому, если что-то в теории возможно, а практическая реализация не позволяет, то это уже недостатки лишь практической реализации. Таким образом, если уж быть совсем точным, то ...данной реализацией декодера. И ничего более. Уж не собираетесь ли вы опровергать теорию (а это очень неблагодарное занятие...)?

Эксперимент показал, что существуют одиночные ошибки, которые не могут быть обнаружены по сигналу CODE_ERR Как я понял, речь шла о
http://www.xilinx.com/ipcenter/catalog/log...ecode_8b10b.pdf
CODE_ERR, an optional output, indicates that the 10-bit symbol on the data-in bus during the rising
edge of the clock was not a valid member of the code set. Active (logic 1) represents a CODE_ERR, and
inactive (logic 0) indicates that the 10-bit code was a valid member of the code set (although other
errors may still exist).

По моему, достаточно ясно сказано, что CODE_ERR не обнаружит все ошибки. Однако на Вашей картинке сигнал DISP_ERR ведь показал ошибки, почему Вы этот сигнал игнорируете?

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

вопрос о выделении клока из кодированного потока данных все еще остается открытым (для меня лично).

итак:
есть
xapp250 от Xilinx который предлагает, используя внешний VCO, выделять клок. Как я понял из хода дискусии этот метод не устраивает не токма меня.
есть
xapp244 от Xilinx который предлагает делать семплирование бита, но он тоже не устраивает, потому как соотношение бауд рейта и системной частоты синхронизации приемника немногим больше 1.
есть
вариант кодировки манчестером, но вдвое расширять полосу канала тоже как то не улыбается, хотя там клок выделяется железно
есть
ну и совсем уж простое решение - передавать клок рядом с данными


хочется
самый "аппетитный" вариант это, что то похожее на xapp250 тока на внутренней PLL/DCM
тогда
с кодировкой 8b/10b все понятно - она дает сбалансированное кол-во 0-й и 1-ц в потоке, вопрос правда в следующем - на сколько такой поток можно использовать на внутренних DCM-ах, скажем S3
тогда
Схемотехника № 12 • декабрь 2004. описано скремблирование данных псевдослучайной последовательностью. но там проблема основная - синхронизация передающего и приемного регистра ПСП

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

премного дякую заранее
)

Поскольку чередование нулей и единиц непериодично, то простой ПЛЛ с таким не справится. Для кода 8В/10В также требуется клок рекавери сёркит. А вот для стартстопной кодировки частота стартстопных бит фиксирована, поэтому на внутренней ПЛЛ можно выделить тактовую.
ЗЫ: не знаю, что такое DCM, не знаком с терминологией, отличной от альтеровской.
Скремблирование, кажется, уже обсуждалось. Всегда найдётся такая последовательность бит, которая в результате скремблирования даст большое число нулей или единиц, что приведёт к срыву синхронизации. (если нет избыточности кодирования)

2 =AK=


а можете ссылку на апликуху дать??

App339 и App356, вместе с референс дизайн. Там клок выделяется из потока данных при помощи оверсамплинга. В реф. дез. дается код на Верилоге для Стратикса для приемо-передатчика на 270 Мбит/сек. Полуторагигабитное декодирование использует внешние примочки.

Да, вроде пришли к выводу, что внутренняя PLL плисины не может выполнять роль CDR. Поэтому нужно использовать внешнюю ПЛЛ.
Только что пришла идея: а если сделать тупо: подать входной сигнал параллельно на колебательный контур, настроенный на тактовую частоту. Он будет выделять эту гармонику. Потом с контура на компаратор и в ПЛИС. Что скажете?

Ничего подобного. PLL сама по себе не может выполнять роль CDR, это верно. Однако PLL вкупе с обычной логикой вполне способны на CDR, если использовать оверсамплинг. Поэтому совершенно не обязательно использовать внешнее железо, если скорость передачи не очень высокая.

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

Предположим, есть у нас PLL, которая на двух своих выходах (со сдвигом 90 град) выдает частоту, соответствующую 4/3 бодовой скорости. Ставим на эти выходы два инвертора, получаем 4 клоковых сигнала, сдвинутых друг от друга на 90 град если считать на частоте PLL, или 60 град если считать на частоте сигнала.

При помощи этих четырех клоков защелкиваем входной поток в 4-х триггерах, и все время смотрим на их выходы. Если в двух соседних триггерах прищелкнуты разные значения (01 или 10) - значит, на этом интервале был переход входного сигнала. Запоминаем в какой паре триггеров был обнаружен переход, и, в зависимости от запомненного значения начинаем выбирать из фазных сигналов такую последовательность фаз, которая будет выдавать клок в момент, наиболее близкий к середине битового интервала. По этому ("скользящему") клоку будем сэмплировать входные данные.