Выбираем униполярный самосинхронизирующийся код, Передача данных и CLK м/у ПЛИС по одному LVDS каналу Опции

[Magnum]

Какие существуют ухищрения для передачи данных и тактовой в одном канале, не приводящие в существенному расширению полосы, как манчестер 2. Первое что приходит на ум - скрембирование. Есть ли альтернативные методы?

[dsmv]

Широко применяется кодировка 8/10. Т.е. восемь бит данных заменяются десятью битами.
В десяти битах передаются 256 значений данных и 12 служебных символов.
Применяется в Gigabit Ethernet, PCI Express.
Мельком слышал, что есть ещё кодировка 64/66.

[xyzzy]

Мельком слышал, что есть ещё кодировка 64/66.

Применяется в 10-Gig Ethernet.

[Krys]

Широко применяется кодировка 8/10. Т.е. восемь бит данных заменяются десятью битами.

Ну это тоже 20%-ное расширение полосы :)

[iosifk]

Широко применяется кодировка 8/10. Т.е. восемь бит данных заменяются десятью битами.

Ну это тоже 20%-ное расширение полосы

Если посмотрите кодировку 4/5, то:
информация в канале кроме данных несет еще код преамбулы,
код определения полярности линии связи и он же код начала пакета данных,
далее в канале есть кодовые комбинации ошибки данных
комбинации окончания данных
исходное состояние канала.
Вот для этого и нужно расширение полосы.
У всех других кодировок, я думаю, дело обстоит аналогично.
Удачи!

[Gate]

В USB применяется NRZ плюс битстаффинг (когда в канале подряд шесть 1 вставляется лишний 0, или наоборот) - тут полоса практически не расширяется. Однако для восстановления клока потребуется фактически аналоговая схема (pll плюс обвязка). Как это реализовать на fpga я не представляю, там pll функционально ограничен.
Имхо есть 2 пути
1. что-то типа манчестера
2. добавить линию и передавать клок

[Magnum]

В USB применяется NRZ плюс битстаффинг (когда в канале подряд шесть 1 вставляется лишний 0, или наоборот) - тут полоса практически не расширяется. Однако для восстановления клока потребуется фактически аналоговая схема (pll плюс обвязка). Как это реализовать на fpga я не представляю, там pll функционально ограничен.
Имхо есть 2 пути
1. что-то типа манчестера
2. добавить линию и передавать клок

Для передачи менчестера нужна вдвое большая скорость передачи в канале по сравнению со скоростью входдящего битового потока т.е. если LVDS расчитан допустим на 200МБит то реально мы сможем передать только 100, а это не есть правильно. Передавать параллельно тоже большая роскошь.. 8b/10b ещё куда не шло..
Господа, а как реализуется кодер/декодер 8b/10b? Табличным методом или есть более простой алгоритм? Есть ли у кого-нибудь готовый кодер 8b/10b?

[Gate]

Готовый кодер/декодер 8/10 исходниками см. в ксайлинковских апнотах xapp336.
Вопрос: а как вы собираетесь восстанавливать клок на плисине? Мне казалось, что это невозможно, но может я ошибаюсь? Апноты у альтеры и ксайлинкса, посвященные lvds-передаче, всегда используют схему с передачей клока по отдельной линии.
Если клок восстановить нельзя, то обсуждать передачу по 1 проводу бессмысленно - остаются манчестерские коды.

[Magnum]

Вопрос: а как вы собираетесь восстанавливать клок на плисине? Мне казалось, что это невозможно, но может я ошибаюсь? Апноты у альтеры и ксайлинкса, посвященные lvds-передаче, всегда используют схему с передачей клока по отдельной линии.
Если клок восстановить нельзя, то обсуждать передачу по 1 проводу бессмысленно - остаются манчестерские коды.

Были бы не сильно удаленные друг от друга фронты во входном потоке, как раз то что обеспечивает 8b/10b а клок восстановим, пусть даже для этого потребуется пара внешних элементов

[dsmv]

Готовый кодер/декодер 8/10 исходниками см. в ксайлинковских апнотах xapp336.
Вопрос: а как вы собираетесь восстанавливать клок на плисине? Мне казалось, что это невозможно, но может я ошибаюсь? Апноты у альтеры и ксайлинкса, посвященные lvds-передаче, всегда используют схему с передачей клока по отдельной линии.
Если клок восстановить нельзя, то обсуждать передачу по 1 проводу бессмысленно - остаются манчестерские коды.

На мой взгляд самое правильное - это устанавливать внешнюю микросхему сериализатора. Например TKL2201. На входе 10 бит - на выходе последовательный код. На входе последовательный код - на выходе 10 бит. Можно подключить к любой ПЛИС. Впрочем есть микросхемы и со встроенным перекодировщиком. В любом случае передачу по последовательной шине надо рассматривать как ненадёжную. Следовательно нужно уметь разбивать поток на пакеты, формировать контрольную сумму, обеспечивать повтор пакетов. На эти процедуры потери будут гораздо больше чем просто на кодировку 8/10. По своему опыту могу сказать, что с использованием оптической линии 1.25 ГБит/с получилась скорость передачи 106 МБайт/с. И я считаю это хорошим результатом. Хотя небольшие резервы ещё есть.

[Magnum]

Например TKL2201. На входе 10 бит - на выходе последовательный код. На входе последовательный код - на выходе 10 бит. Можно подключить к любой ПЛИС. Впрочем есть микросхемы и со встроенным перекодировщиком. В любом случае передачу по последовательной шине надо рассматривать как ненадёжную. Следовательно нужно уметь разбивать поток на пакеты, формировать контрольную сумму, обеспечивать повтор пакетов. На эти процедуры потери будут гораздо больше чем просто на кодировку 8/10. По своему опыту могу сказать, что с использованием оптической линии 1.25 ГБит/с получилась скорость передачи 106 МБайт/с. И я считаю это хорошим результатом. Хотя небольшие резервы ещё есть.

Зачем ставить дополнительный LVDS сериализатор, если его можно реализовать в ПЛИС, сейчас даже в младших моделях циклонов есть такая возможность.

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

[dsmv]

Зачем ставить дополнительный LVDS сериализатор, если его можно реализовать в ПЛИС, сейчас даже в младших моделях циклонов есть такая возможность.

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

Я работаю с Xilinx, и такой возможности не имею. ПЛИС Spartan 3 XC3S400; А вот насчёт более высокого уровня - не согласен. У меня весь протокол реализован на ПЛИС. Это требуется для максимальной разгрузки сигнальных процессоров. Заполнение ПЛИС, которая обеспечивает два таких канала, 35%. Т.е. ~17% на канал. При этом обеспечивается надёжная передача данных, доступ к регистрам, передача потока. И при этом минимальная загрузка процессора.

[des00]

Я работаю с Xilinx, и такой возможности не имею. ПЛИС Spartan 3 XC3S400; А вот насчёт более высокого уровня - не согласен. У меня весь протокол реализован на ПЛИС. Это требуется для максимальной разгрузки сигнальных процессоров. Заполнение ПЛИС, которая обеспечивает два таких канала, 35%. Т.е. ~17% на канал. При этом обеспечивается надёжная передача данных, доступ к регистрам, передача потока. И при этом минимальная загрузка процессора.

Тут скорее всего имелось в виду уровни иерархии системы, а на чем это было сделано на фпга или на проце это другой вопрос.
Если не секрет вы лабали все на софт проце или на КА ? какое кол-во состояний у вас получилось ?
какой канал передачи инфы между процем и фпга вы использовали ?

[dsmv]

Тут скорее всего имелось в виду уровни иерархии системы, а на чем это было сделано на фпга или на проце это другой вопрос.
Если не секрет вы лабали все на софт проце или на КА ? какое кол-во состояний у вас получилось ?
какой канал передачи инфы между процем и фпга вы использовали ?

В ПЛИС реализовано четыре уровня
1. Физический - подключение с микросхеме сериализатора
2. Линк уровень - повторы пакетов, обеспечение надёжной передачи
3. Траспортный уровень - организация транспортной передачи
4. Уровень транзакций - организация доступа к регистрам

Используются конечные автоматы. Состояний много (автоматов тоже), так что затрудняюсб ответить сколько. Подключение процессора происходит в рамках стандарта фирмы "Инструментальные Системы" на организацию ПЛИС ADM. При этом используются три тетрады.
Для процессора достпуно FIFO передачи данных, FIFO приёма данных. Обмен с ними происходит с использованием канала DMA. И ещё есть возможности приёма и передачи пакетов через процессор.

P.S. По этой теме у меня будет доклад на DSPA-2006. Приходите.

[iosifk]

P.S. По этой теме у меня будет доклад на DSPA-2006. Приходите.

А для тех кто хочет ознакомиться в "удаленном режиме"?

Может пришлете материальчик, или скажете где прочитать?
Заранее спасибо!

[DmitryR]

Для передачи менчестера нужна вдвое большая скорость передачи в канале по сравнению со скоростью входдящего битового потока т.е. если LVDS расчитан допустим на 200МБит то реально мы сможем передать только 100

На Spartan-3 четвертой скорости можно сделать 500 Мегагерц на выходе, используя DDR регистры (проверено). Соответственно реальная скорость будет 250 Мбит/с. Вам надо больше?

[Magnum]

Для передачи менчестера нужна вдвое большая скорость передачи в канале по сравнению со скоростью входдящего битового потока т.е. если LVDS расчитан допустим на 200МБит то реально мы сможем передать только 100

На Spartan-3 четвертой скорости можно сделать 500 Мегагерц на выходе, используя DDR регистры (проверено). Соответственно реальная скорость будет 250 Мбит/с. Вам надо больше?

Мы используем альтеру, там LVDS-ный интерфейс 640Мбит тянет и ДДР можно организовать, нам надо отжать по максимуму

Сообщение отредактировал Magnum - Feb 27 2006, 09:49

[Gate]

Если использовать внешний сериализатор/десериализатор, то задача становится чисто цифровой и понятной - в плисине надо реализовывать протоколы уровня выше физического. По это теме есть куча информации. И у альтеры и у ксайлинкса есть доки, посвященные быстрой связи между fpga на плате, быстрой последовательной передаче между платами внутри крейта (по бэкплэйну) и т.д. Нет базару...
Меня-то здесь интересует неясная для меня аналоговая часть - восстановление клока из данных. Я считал, что _просто_ это сделать нельзя, и выгоднее либо добавлять линию передачи клока, либо ставить внешний чип сер/десер. Magnum, если вы знаете простой способ или литературу или ссылки - расскажите pls, буду рад любой информации.

[Magnum]

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

Так можно сделать хотябы по тому же принципу, как это делается в тех же внешних сериализаторах, где каждый пакет из 10 бит снабжается по краям старт (1) и стоп (0) битами. Таким образом всегда есть фронт между соседними пакетами. К этому фронту привязывается PLL, умножается на 12 и этой частотой тактируется входящий поток. http://cache.national.com/ds/DS/DS92LV1023.pdf

[Krys]

На мой взгляд самое правильное - это устанавливать внешнюю микросхему сериализатора. Например TKL2201. На входе 10 бит - на выходе последовательный код. На входе последовательный код - на выходе 10 бит. Можно подключить к любой ПЛИС. Впрочем есть микросхемы и со встроенным перекодировщиком.

Позвольте заметить, что вы вводите автора темы (а заодно и себя) в заблуждение: указанная вами микросхема - это всего лишь SerDes, и никакими "волшебными" свойствами по восстановлению тактовой частоты не обладает. Эта микросхема никогда не восстановит тактовую частоту, не будь десятибитный код закодирован так, чтобы подряд не встречалось большое количество нулей либо единиц. Обычно с этой микросхемой применяется кодирование 8В/10В, о котором упоминалось ранее. При этом, если не ошибаюсь, подряд не может следовать больше 3 одинаковых цифр, поэтому синхронизация не успевает сбиться.

[dsmv]

На мой взгляд самое правильное - это устанавливать внешнюю микросхему сериализатора. Например TKL2201. На входе 10 бит - на выходе последовательный код. На входе последовательный код - на выходе 10 бит. Можно подключить к любой ПЛИС. Впрочем есть микросхемы и со встроенным перекодировщиком.

Позвольте заметить, что вы вводите автора темы (а заодно и себя) в заблуждение: указанная вами микросхема - это всего лишь SerDes, и никакими "волшебными" свойствами по восстановлению тактовой частоты не обладает. Эта микросхема никогда не восстановит тактовую частоту, не будь десятибитный код закодирован так, чтобы подряд не встречалось большое количество нулей либо единиц. Обычно с этой микросхемой применяется кодирование 8В/10В, о котором упоминалось ранее. При этом, если не ошибаюсь, подряд не может следовать больше 3 одинаковых цифр, поэтому синхронизация не успевает сбиться.

Надеюсь что заблуждения не будет. Я прекрасно понимаю, что возможна передача только с использованием перекодировки 8/10. На приёме происходит восстановление тактовой частоты и выравнивание битов по приёму символа K28.5;

[Krys]

Надеюсь что заблуждения не будет. Я прекрасно понимаю, что возможна передача только с использованием перекодировки 8/10. На приёме происходит восстановление тактовой частоты и выравнивание битов по приёму символа K28.5;

Ну а раз так, то с подобной задачей легко можно справиться и внутренними средствами ПЛИС, без применения внешних микросхем. Если, конечно, внутри ПЛИС есть ГУН с ФАПЧ, выводы стандарта ЛВДС, и триггерная частота переключения позволяет работать с потоком данных в последовательной форме. Не так ли?

Сообщение отредактировал Janna - Mar 1 2006, 06:40

[dsmv]

[quote name='Janna' date='Mar 1 2006, 09:39' post='91043']
[/quote]Ну а раз так, то с подобной задачей легко можно справиться и внутренними средствами ПЛИС, без применения внешних микросхем. Если, конечно, внутри ПЛИС есть ГУН с ФАПЧ, выводы стандарта ЛВДС, и триггерная частота переключения позволяет работать с потоком данных в последовательной форме. Не так ли?
[/quote]
Конечно, вот только требуется частота 1.25 ГГц. Это позволяет сделать Xilinx Virtex 2 Pro, Xilinx Virtex 4 FX, Altera Stratix GX; В этих микросхемах есть такие узлы. Но сами микросхемы дорогие. Поэтому я высказываю мнение, что лучше поставть дешёвый Spartan 3 (или Cyclon) и внешний сериализатор.

[Krys]

Конечно, вот только требуется частота 1.25 ГГц.ваю мнение, что лучше поставть дешёвый Spartan 3 (или Cyclon) и внешний сериализатор.

Ну никто не говорил, что требуются такие заоблачные частоты :)

Конечно, вот только требуется частота 1.25 ГГц. Это позволяет сделать Xilinx Virtex 2 Pro, Xilinx Virtex 4 FX, Altera Stratix GX; В этих микросхемах есть такие узлы. Но сами микросхемы дорогие.

Поверьте, такие узлы есть и в более дешёвых микросхемах, просто они не работают на указанной вами частоте.
Таким образом, мы приходим к выводу, что внешняя микросхема SerDes требуется только в том случае, где не позволяет быстродействие ПЛИС

[kyb]

А не проще ли поставить внешнюю пару приема-передачи DVB-ASI (типа cy7c924). И будут 200 мбит/с и последовательная шина и другие вкусности. Или проект уже готов и на плате ничего не изменить?

[Magnum]

А не проще ли поставить внешнюю пару приема-передачи DVB-ASI (типа cy7c924). И будут 200 мбит/с и последовательная шина и другие вкусности. Или проект уже готов и на плате ничего не изменить?

Конечно проще, но тратить лишние 100у.е. на внешний интерфейс, имея всё необходимое на борту 20уёвого циклона смысла не вижу.

[Krys]

Может, автору стоит разместить эту тему или ссылку на эту тему в группе тем, где обсуждаются интерфейс ЛВДС?

[Gate]

Господа, мы опять вернулись к обсуждению физического уровня протокола и вопросу восстановления клока из потока данных средствами fpga. Мое утверждение (и вопрос) заключается в том, что _только _ с помощью внутреннего pll сделать это нельзя (корректно говоря - я не знаю как ), т.к. pll в циклонах и стратиксах (про ксайлинксы не знаю, но думаю, что примерно также) может только * и / частоту + сдвигать результат. Основание моего убеждения - изучение вопроса примерно полгода назад (была проработка проекта) плюс тот факт, что в application notes у altera и xilinx в lvds-передачах участвует клок, передаваемый по отдельной линии.
Я задал вопрос Magnum, но он описал мне принцип восстановления частоты и дал почему-то ссылку на внешний чип сериализатора. Однако, как все мы знаем, между принципом и его реализацией в железе могут встретится некоторые трудности (читайте статьи про квантовые вычисления).
Вопрос остался открытым: можно ли и как с помощью pll в fpga восстановить клок из данных.

[Krys]

Ни в коей степени не претендую на правильность, но у меня следующие рассуждения: какая разница внутри ПЛИС стоит ПЛЛ или вне? Ведь ПЛЛ состоит из одного и того же: ГУН, ФАПЧ, ФНЧ. Я смотрел в хэндбуке на стратикс2 вид ПЛЛ - всё так, как я описал.
Конечно, не исключаю, что ПЛЛ внутри ПЛИС не сможет подстроиться под тактовую, получаемую из данных, из-за особенностей построения. Но из хэндбука не следует ни подтверждения этой мысли, ни опровержения. Так что остаётся проверять. Или слушать совет того, кто уже проверял.

pll в циклонах и стратиксах (про ксайлинксы не знаю, но думаю, что примерно также) может только * и / частоту + сдвигать результат. Основание моего убеждения - изучение вопроса примерно полгода назад (была проработка проекта) плюс тот факт, что в application notes у altera и xilinx в lvds-передачах участвует клок, передаваемый по отдельной линии

Ничто не мешает подать на вход клока этот же сигнал данных. В теории. Ну а вообще, надо проверять, "вытянет" ли ПЛЛ такие трюки или будут срывы. Всё зависит от конкретной реализации ПЛЛ

[Gate]

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

Забыл еще упомянуть an356 у альтеры (Serial Digital Interface Reference Design for Cyclone & Stratix Devices). Там клок не восстанавливается, а используется чисто цифровой способ - oversampling (делаются 4 клока опорной частоты, сдвинутые на 90 градусов каждый и смотрят когда во входном потоке есть переходы уровней).

[makc]

Забыл еще упомянуть an356 у альтеры (Serial Digital Interface Reference Design for Cyclone & Stratix Devices). Там клок не восстанавливается, а используется чисто цифровой способ - oversampling (делаются 4 клока опорной частоты, сдвинутые на 90 градусов каждый и смотрят когда во входном потоке есть переходы уровней).

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

[Gate]

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

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

[makc]

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

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

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

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

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

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

[Krys]

Например, feedback есть только у стратиксов (которые дороги), а в дешевых циклонах у pll есть только вход частоты, сигналы сброса и разрешения.

Этот вход, насколько я понимаю, - для высшего пилотажа. Чтобы ОС делать снаружи плис - это для особых извратов.

делаются 4 клока опорной частоты, сдвинутые на 90 градусов каждый и смотрят когда во входном потоке есть переходы уровней

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

[=AK=]

В USB применяется NRZ плюс битстаффинг (когда в канале подряд шесть 1 вставляется лишний 0, или наоборот) - тут полоса практически не расширяется. Однако для восстановления клока потребуется фактически аналоговая схема (pll плюс обвязка). Как это реализовать на fpga я не представляю, там pll функционально ограничен.

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

Имхо есть 2 пути
1. что-то типа манчестера
2. добавить линию и передавать клок

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

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

[Krys]

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

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

[=AK=]

либо вы не полностью представляете кодировку 8В/10В

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

[=AK=]

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

[dsmv]

...
В отличие от старт-стопных, 8b/10b позволяет обнаруживать одиночные ошибки
...

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

[Magnum]

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

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

[jericho]

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

[Gate]

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

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

[=AK=]

В отличие от старт-стопных, 8b/10b позволяет обнаруживать одиночные ошибки

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

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.

[dsmv]

В отличие от старт-стопных, 8b/10b позволяет обнаруживать одиночные ошибки

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

it can detect all single-bit and many other errors;

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


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

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

[Victor]

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

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

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

[dsmv]

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

Мне кажется, что в данном случае не обнаружиться, поскольку K28.4 не нарушает баланс. В нём одинаковое число нулей и единиц.

[Krys]

Мне кажется, что в данном случае не обнаружиться, поскольку K28.4 не нарушает баланс. В нём одинаковое число нулей и единиц.

Боюсь, вы всё-таки ошибаетесь: кодовая группа К28.3, которую вы привели, должна следовать после отрицательной перменной составляющей, и в результате в конце ожидается положительная переменная составляющая, поэтому следующая кодовая группа должна иметь отрицательную переменную составляющую для компенсации.
В случае возникновения ошибки и приёма кодовой группы К28.4, которую вы привели и которая также должна следовать после отрицательной переменной составляющей, ожидаться будет положительная переменная составляющая для компенсации постоянного тока.
Таким образом, ожидаться будет противоположная переменная составляющая, поэтому ошибка будет обнаружена.
Кроме того, вы привели пример на зарезервированных кодовых группах, которые автор темы волен не использовать, как их не используют и в гигабитном изернете.
Возможно, это лишь ваш неудачный пример. Если хотите, приведите другой пример, с реально действующими кодовыми группами.

[dsmv]

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

Вот ещё пример:
D3.1 110001 1001
D4.1 110101 1001

Это коды уже из группы данных. Так что они точно используются.
Код D3.1 является нейтральным. Мне пока не совсем понятен механизм перехода между
положительной и отрицательной полярностью. Переход обязательно должен производиться, или возможена передача нескольких слов без перехода ?

[Krys]

В этом примере всё аналогично предыдущему: для кодовой группы D3.1 ожидается, что следующая кодовая группа будет положительной полярностью. А для кодовой группы D4.1 ожидается, что следующая будет отрицательной. Согласен? Поэтому обнаружить ошибку не составляет труда именно по несоответствию ожидаемой и действительно принятой полярности.

Код D3.1 является нейтральным. Мне пока не совсем понятен механизм перехода между положительной и отрицательной полярностью. Переход обязательно должен производиться, или возможена передача нескольких слов без перехода ?

На одну кодовую группу одной полярности должна приходиться кодовая группа другой полярности, притом подряд несколько одной полярности, потом подряд несколько другой полярности быть не может: только одна за другой. Между разными полярностями может вставать хоть сколько нейтральных, это не изменит баланса, поэтому на них плевать.

Сообщение отредактировал Janna - Mar 9 2006, 07:13

[Victor]

... для кодовой группы D3.1 ожидается, что следующая кодовая группа будет положительной полярностью.

Мне кажется, что не _следующая будет_, а _предыдущая была_ полярность RD-...

Вот ещё пример:
D3.1 110001 1001
D4.1 110101 1001

Понимаете, где бы ни был использован D3.1, это будет означать, что БЫЛ "RD-", а раз в D3.1 кол-во 0-й = кол-ву 1-ц, значит и на следующем БУДЕТ "RD-"! А если вместо D3.1 будет D4.1, это будет означать, что на следующем слове БУДЕТ "RD+", т.к. в D4.1 1-ц больше...

Сообщение отредактировал Victor - Mar 9 2006, 07:49

[dsmv]

Провёл следственный эксперимент :-)
Последовательно включил узлы 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 - принятый байт
[attachment=4621:attachment] [attachment=4621:attachment]

Эскизы прикрепленных изображений

 

[Magnum]

Провёл следственный эксперимент :-)
Последовательно включил узлы encode8/10 и decode8/10

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

[dsmv]

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

[dsmv]

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

Прикрепленные файлы

 encode8b10b.zip ( 16.81 килобайт ) Кол-во скачиваний: 62

 

[Krys]

Последовательно включил узлы encode8/10 и decode8/10
Привожу временную диаграмму. Сигнал code_err это признак ошибки. Видно, что он не устанавливается.

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

[dsmv]

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

[Krys]

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

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

...данной реализацией декодера. И ничего более. Уж не собираетесь ли вы опровергать теорию (а это очень неблагодарное занятие...)?

[=AK=]

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

Эксперимент показал, что существуют одиночные ошибки, которые не могут быть обнаружены по сигналу 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 ведь показал ошибки, почему Вы этот сигнал игнорируете?

Сообщение отредактировал =AK= - Mar 9 2006, 12:39

[lutik]

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

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

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


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

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

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

[Krys]

с кодировкой 8b/10b все понятно - она дает сбалансированное кол-во 0-й и 1-ц в потоке, вопрос правда в следующем - на сколько такой поток можно использовать на внутренних DCM-ах, скажем S3

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

Схемотехника № 12 • декабрь 2004. описано скремблирование данных псевдослучайной последовательностью. но там проблема основная - синхронизация передающего и приемного регистра ПСП

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

[lutik]

2 =AK=

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

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

[=AK=]

есть ли у альтеры какая нибудь апликуха на енту тему?

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

Сообщение отредактировал =AK= - Mar 9 2006, 12:51

[Krys]

Вопрос: а как вы собираетесь восстанавливать клок на плисине?

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

[=AK=]

Да, вроде пришли к выводу, что внутренняя PLL плисины не может выполнять роль CDR. Поэтому нужно использовать внешнюю ПЛЛ.

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

Сообщение отредактировал =AK= - Mar 11 2006, 23:11

[Krys]

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

[=AK=]

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

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