[iiv 29]

Всем привет,

 

есть два аппарата, общающиеся по скоростной линии по 3-м ногам аля SPI - первый аппарат шлет клок по первой линии всегда, второй аппарат непрерывно посылает на каждый клок один бит информации по второй линии, а по третьей ноге первый аппарат сообщает второму о том, что дошло ли и что дальше посылать.

 

Оба аппарата общаются через плиски.

 

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

 

Сейчас реализовано все так - второй первому шлет пакеты по 9кбит, после этого пакета идет CRC, если пакет пришел битый, то происходит запрос на перепосылку пакета.

 

Запрос возникает примерно в 20% случаев, на декодирование СРС на приемнике и старт-стоп пакета я теряю примерно 300 тактов пересылки (3%). Если уменьшать размер пакета - то оверхед увеличивается, если удлинять пакет - вероятность битости данных увеличивается. Хочется все-таки улучшить проходимость пакетов.

 

При детальном анализе получилось, что почти всегда битость пакета - это либо

 

1. один ошибочный бит,

2. один пропущенный бит (клок пропустился),

3. один случайно возникший дополнительный бит в начале передачи.

 

Скажите, пожалуйста, есть ли способ кодирования сигнала, который бы позволял бы исправить эти типы ошибок?

 

Спасибо

 

ИИВ

[_Pasha 0]

Список корректирующих кодов

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

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

 

[тау 29]

Скажите, пожалуйста, есть ли способ кодирования сигнала, который бы позволял бы исправить эти типы ошибок?

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

SPI на высоких скоростях и длинах более полуметра - фтопку.

сериалайзер\десериалайзер прикрутите или используйте встроенные в плиску если есть.

Изменено 5 октября, 2012 пользователем тау

[iiv 29]

а Вы попробуйте ЛВДС интерфейсом передавать данные и клоки

простите, пожалуйста, что я не понятно выразился, там именно LVDS, но по типу сигнала очень похож на SPI, о котором я и упомянул. Битрейд 250-400МБит/с, общаются когда два, когда и 4 стратикса 3-и и 4-ые, через несколько терасиковских HSMC удлинителей, с суммарной длиной около полуметра. Ножек лишних нет, реально общаюсь по 4-м клокам и 28 лвдс шинам, то есть реальный трафик около двух гбайт в секунду, но каждый клок живет отдельно от другого.

 

В основном задача возникла от того, что скоро надо будет делать броадкаст - одна борда шлет, остальные 3-7 слушают, но, сперва, хочу потренироваться на кошках - то есть отточить все на паре аппаратов.

 

EDIT рядом с приборами иногда случаются ЕМ помехи, и, похоже, даже LVDS не помогает...

 

На счет полуметра - соврал - там где-то 25см всего-то.

[Tiro 0]

есть два аппарата, общающиеся по скоростной линии по 3-м ногам аля SPI - первый аппарат шлет клок по первой линии всегда, второй аппарат непрерывно посылает на каждый клок один бит информации по второй линии, а по третьей ноге первый аппарат сообщает второму о том, что дошло ли и что дальше посылать.

 

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

Поддержу уважаемого Тау.

 

Для высокоскоростной дуплексной передачи трехпроводные синхронные интерфейсы не подходят. Скорость распространения электромагнитного взаимодействия в вакууме составляет 0,3 м/нс. Это при эпсилон вакуума 1. Диэлектрическая проницаемость материала плат на FR-4 примерно 4-6, в проводах похоже. Там скорость ЭМ волны ниже в квадратный корень из диэл проницаемости, то есть раза в 2.

 

Теперь учтем время распространения сигнала туда, реакцию второго устройства, распространение обратно и реакцию первого устройства. И все это должно произойти не медленнее, чем за полтакта клока. Пусть все времена примерно равны и устройства близко, примерно в метре. Тогда половина клока не менее 4*3,3 нс и клок не выше 75 МГц всего.

 

Используйте либо двунаправленные синхронные интерфейсы, а лучше двунаправленные асинхронные интерфейсы.

[iiv 29]

Используйте либо двунаправленные синхронные интерфейсы, а лучше двунаправленные асинхронные интерфейсы.

 

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

 

Список корректирующих кодов

 

спасибо! начал читать - довольно много, но и очень познавательно. Если вдуг книжку найдете, буду премного благодарен!

[Tiro 0]

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

Тогда асинхронный интерфейс в две стороны. Две линии, но придется в поток подмешать синхросигналы.

[тау 29]

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

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

600мбит по 4х метровому DVI кабелю пролезают запросто большими пакетами без потерь, правда в асинхронном режиме.

[iiv 29]

на лишний клок жмотиться - неправильно.

это верно, согласен с Вами, только в этом случае у меня будет большая асинхронность, и, при потере пакета - большая нагрузка на алгоритм.

 

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

 

Фактически я снова возвращаюсь к моему исходному вопросу - надежному алгоритму восстановления пропущеных битов клока или данных.

[alexPec 3]

Как я понял основная проблема - пропуск (или лишние) клоков. Одиночные ошибки данных легко правятся кодами хемминга или БЧХ (не одиночные). А вот если последовательность на 1 бит смещается - тут засада, корректирующие коды не помогут.

Вы serdes для приема LVDS используете? Там ведь вроде ПЛЛ... Неужели при одном потерянном клоке ПЛЛ настолько слетает, я думал что она должна воосстановить его (один то импульс), а дальше подстроится. Не пробовали сигналтапом вставать на ножку захвата ПЛЛ и посмотреть, слетает захват при неправильных (пропуск или лишний) клоках или нет?

[тау 29]

надежному алгоритму восстановления пропущеных битов клока или данных.

если дело в 1 бите клока\данных, то может быть поможет следующее

пакет делится на блоки с контролем четности каждого блока , скажем по 64 бита

в конце пакета передается дополнителный контрольный блок ,являющийся результатом ксор от всех предыдущих блоков пакета.

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

Если ошибка в несколких блоках начиная с n , то принимается решение об ошибке в блоке n . Все последующие восстанавливаются сдвигом туда\сюда на 1 бит , а n-ный ксором как описано выше.

[iiv 29]

если дело в 1 бите клока\данных, то может быть поможет следующее

 

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

 

Кстати посылка клока впараллель с данными улучшила сильно ситуацию с битостью данных - теперь при посылке 9к блока у меня серьезно меньше 1% ошибок, правда, сильно возрос оверхед на старт-стоп... за что, всем отвечавшим, преогромное спасибо! А тип ошибок остался тем же - пропускается либо клок, либо бит.

[Виктория 0]

Фактически я снова возвращаюсь к моему исходному вопросу - надежному алгоритму восстановления пропущеных битов клока или данных.

 

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

Возможна потеря как клока, так и бита данных - это основная проблема, т.к. почти соотношение неопределенностей.

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

Если бы только в клоках - дополнительные измерения по таймеру на стороне приемника/передатчика.

А так как Вы ставите вопрос, это больше похоже на NP сложную задачу.

 

Может выкинуть клоки? Пойти к примеру по такому пути http://www.findpatent.ru

 

[_Pasha 0]

Может выкинуть клоки?

Я так понимаю, что для того, чтобы выкинуть клоки, надо кодировать выходные данные NRZI, а это - битрейт вдвое подымается. Такшта.

Книжка обещанная

Видать, не так давно выложили, раньше не было.

Изменено 6 октября, 2012 пользователем _Pasha

[Виктория 0]

Книжка обещанная

Видать, не так давно выложили, раньше не было.

 

Ага, все пошли в библиотеку :rolleyes:

 

А я, все-таки, ещё на ламерском осмыслении задачи:

- разве существует многомерная передаточная характеристика?

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

 

Хорошо только топикстартеру, отдыхает поди...