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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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) и внешний сериализатор.

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

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

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

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

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

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

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

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

У ксайлинкса это 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. Может я все-таки не прав?

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

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

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

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

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

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

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


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