[Magnum 0]

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

[dsmv 0]

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

В десяти битах передаются 256 значений данных и 12 служебных символов.

Применяется в Gigabit Ethernet, PCI Express.

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

[xyzzy 0]

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

 

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

[Krys 2]

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

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

[iosifk 3]

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

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

Если посмотрите кодировку 4/5, то:

информация в канале кроме данных несет еще код преамбулы,

код определения полярности линии связи и он же код начала пакета данных,

далее в канале есть кодовые комбинации ошибки данных

комбинации окончания данных

исходное состояние канала.

Вот для этого и нужно расширение полосы.

У всех других кодировок, я думаю, дело обстоит аналогично.

Удачи!

[Gate 0]

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

Имхо есть 2 пути

1. что-то типа манчестера

2. добавить линию и передавать клок

[Magnum 0]

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

Имхо есть 2 пути

1. что-то типа манчестера

2. добавить линию и передавать клок

 

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

Господа, а как реализуется кодер/декодер 8b/10b? Табличным методом или есть более простой алгоритм? Есть ли у кого-нибудь готовый кодер 8b/10b?

[Gate 0]

Готовый кодер/декодер 8/10 исходниками см. в ксайлинковских апнотах xapp336.

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

Если клок восстановить нельзя, то обсуждать передачу по 1 проводу бессмысленно - остаются манчестерские коды.

[Magnum 0]

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

Если клок восстановить нельзя, то обсуждать передачу по 1 проводу бессмысленно - остаются манчестерские коды.

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

[dsmv 0]

Готовый кодер/декодер 8/10 исходниками см. в ксайлинковских апнотах xapp336.

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

Если клок восстановить нельзя, то обсуждать передачу по 1 проводу бессмысленно - остаются манчестерские коды.

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

[Magnum 0]

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

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

 

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

[dsmv 0]

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

 

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

 

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

[des00 25]

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

 

Тут скорее всего имелось в виду уровни иерархии системы, а на чем это было сделано на фпга или на проце это другой вопрос.

Если не секрет вы лабали все на софт проце или на КА ? какое кол-во состояний у вас получилось ?

какой канал передачи инфы между процем и фпга вы использовали ?

[dsmv 0]

Тут скорее всего имелось в виду уровни иерархии системы, а на чем это было сделано на фпга или на проце это другой вопрос.

Если не секрет вы лабали все на софт проце или на КА ? какое кол-во состояний у вас получилось ?

какой канал передачи инфы между процем и фпга вы использовали ?

В ПЛИС реализовано четыре уровня

1. Физический - подключение с микросхеме сериализатора

2. Линк уровень - повторы пакетов, обеспечение надёжной передачи

3. Траспортный уровень - организация транспортной передачи

4. Уровень транзакций - организация доступа к регистрам

 

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

Для процессора достпуно FIFO передачи данных, FIFO приёма данных. Обмен с ними происходит с использованием канала DMA. И ещё есть возможности приёма и передачи пакетов через процессор.

 

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

[iosifk 3]

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

 

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

 

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

Заранее спасибо!