Как грамотно принять цифровой сигнал Опции

[ArAhis]

Есть на входе (в ПЛИС) цифровой сигнал, поступающий с определенной частотой (ну, скажем 10МГц), только этот самый тактовый сигнал НЕ ПОСТУПАЕТ (так сделано в приемопередатчике MLX90121 (режим Direct Reception))! Посоветуйте как грамотно принять этот цифровой сигнал, имея при этом свой (внутренний) тактовый сигнал любой частотой??? Тупо брать тактовый сигнал той же частоты, с которой поступает цифровой сигнал не получится, т.к. фронты обоих сигналов могут совпасть и получим неправильно принятый сигнал!!!
Если я не правильно понял datasheet на MLX90121, поправьте меня. Хотя по другому его понять сложно! Если что, datasheet находится здесь: http://www.melexis.com/Asset.aspx?nID=4755

[rezident]

Что-то я не совсем понял проблемы. Интерфейс-то синхронный вроде, так в чем затруднение?

[maksya]

Датащит качать влом, но насколько Я понял связь между трансивером и ПЛИС только по одному проводу. Т.е. отдельной линии синхронизации для приема информации в буферы программируемой логики нет. Если так, то синхросигнал надо восстанавливать из данных - Clock Data Recovery (CDR). Только мне как-то сомнительно, что такой геморрой устроили для сопряжения трансивера с управляющей логикой.

Любопытсво все же перебороло лень, скачал док. Действительно, все как Я и предполагал. "Видите синхросигнал?.. Нет? А он есть!". Стр. 16: сигнал DSYNC управляет выплевыванием данных из трансивера в логику. Так что никаких CDR. Будьте внимательней!

P.S.: пока дописывал сообщение rezident опубликовал правильный ответ.

[rezident]

Да есть там синхро! Только они раздельные. Для DIN входной CK, для DOUT ВЫходной DSYNC.

[net]

Да есть там синхро! Только они раздельные. Для DIN входной CK, для DOUT ВЫходной DSYNC.

может я конечно невнимательно прочитал - но в том режиме о котором говорит человек синхры там нет
он говорит о прямом приеме - а в остальных режимах синхро там есть

[rezident]

Пардон! Не обратил внимание, что указан конкретный режим.

[ArAhis]

Пардон! Не обратил внимание, что указан конкретный режим.

Вот именно, при приеме используется режим Direct Reception, по даташиту в этом режиме синхросигнал не поступает (вроде бы, хотя может в даташите ошиблись)!!! Так все же как посоветуете поступить, использовать Clock Data Recovery, если да, то что это такое (где про него можно почитать)? А может стоить использовать другие способы приема сигнала (например, в ПЛИС взять синхросигнал частота которого в 4 раза быстрее частоты входных данных, и уже на основании 4-х выборок определять значение входного бита (мои догадки, не факт что это работает))???

[sK0T]

Посоветуйте как грамотно принять этот цифровой сигнал, имея при этом свой (внутренний) тактовый сигнал любой частотой??? Тупо брать тактовый сигнал той же частоты, с которой поступает цифровой сигнал не получится, т.к. фронты обоих сигналов могут совпасть и получим неправильно принятый сигнал!!!

Тут надо поступить довольно просто. Теоретически достаточно сэмплировать входящий сигнал с двойной скоростью. Практически это врядли оправдано. Сэмплируем входной сигнал в k раз большей частотой. Приведу пример для k=3.

Сигнал: 1010
Принимаем: 111000111000

Синхронизируем приём по переходу 0-1 входящего сигнала, записываем n отсчётов в буфер и анализируем его, зная что каждые k бит буфера соответствуют одному биту принимаемого сигнала. Если преобладают единицы в окне бита — значит единица на линии, если нули, значит ноль. Обязательно делать это короткими окнами, синхронизированными по переходу входящего сигнала. Если входящий сигнал имеет малую энтропию (например могут быть сплошные нули в течении длительного времени), то надо думать дальше. :-)

Ещё вариант питать источник Вашего сигнала клоками с ПЛИС частотой f/2, а семплировать на частоте f. Тогда синхронизация будет «автоматической». ;-)

[ArAhis]

Сэмплируем входной сигнал в k раз большей частотой. Приведу пример для k=3.

Сигнал: 1010
Принимаем: 111000111000

Не факт, что принимаемый сигнал будет 111000111000! Если один из фронтов тактового сигнала совподет с фронтом входного сигнала, то может получиться следующее: пусть, например, фронт входного сигнала совпадает с каждым 3-м фронтом синхросигнала, тогда по этому фронте мы можем принять, либо '1' либо '0', причем не факт, что входной сигнал на этом фронте всегда будет искажаться в одну сторону, например, мы можем принять любой из следующих сигналов:
110000111001 или
111000110000 и т.д.
Т.е. на каждом 3-м фронте тактового сигнала, мы можем принять как '1', так и '0', не зависимо от фронта входного сигнала (1->0 или 0->1)!!!

Вообще, меня интересует такой общий вопрос: как грамотно (наиболее просто, с наименьшими затратами) принять (в регистр) цифровой сигнал (1 битовый), поступающий с известной заданной частотой, при условии, что тактовый сигнал не поступает, имея в распоряжении все возможности ПЛИС? Может быть уже существуют оптимальные методы, я не в курсе!!!

Сообщение отредактировал ArAhis - May 24 2006, 22:39

[sK0T]

Не факт, что принимаемый сигнал будет 111000111000! Если один из фронтов тактового сигнала совподет с фронтом входного сигнала, то может получиться следующее: пусть, например, фронт входного сигнала совпадает с каждым 3-м фронтом синхросигнала, тогда по этому фронте мы можем принять, либо '1' либо '0', причем не факт, что входной сигнал на этом фронте всегда будет искажаться в одну сторону, например, мы можем принять любой из следующих сигналов:
110000111001 или
111000110000 и т.д.
Т.е. на каждом 3-м фронте тактового сигнала, мы можем принять как '1', так и '0', не зависимо от фронта входного сигнала (1->0 или 0->1)!!!

Вообще-то там дальше было написано про подсчёт единиц или нулей, ага?
110 000 111 001 — 2 0 3 1 — 1 0 1 0
111 000 110 000 — 3 0 2 0 — 1 0 1 0

Если k взять побольше, всё будет с приличной вероятностью. «Идеальный» приём сигнала в таких условиях представляется задачей в общем случае не разрешимой. Если два устройства питаются независимыми синхросигналами, то синхронизовать их в общем случае без передачи синхросигналов нельзя. Например передаётся ноль. За какое-то время генераторы в устройствах разойдутся так, что сказать сколько нулевых бит прошло между двумя моментами времени достоверно будет нельзя и никакие ресурсы ПЛИС тут не помогут.

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

[net]

Сэмплируем входной сигнал в k раз большей частотой. Приведу пример для k=3.

Сигнал: 1010
Принимаем: 111000111000

Не факт, что принимаемый сигнал будет 111000111000! Если один из фронтов тактового сигнала совподет с фронтом входного сигнала, то может получиться следующее: пусть, например, фронт входного сигнала совпадает с каждым 3-м фронтом синхросигнала, тогда по этому фронте мы можем принять, либо '1' либо '0', причем не факт, что входной сигнал на этом фронте всегда будет искажаться в одну сторону, например, мы можем принять любой из следующих сигналов:
110000111001 или
111000110000 и т.д.
Т.е. на каждом 3-м фронте тактового сигнала, мы можем принять как '1', так и '0', не зависимо от фронта входного сигнала (1->0 или 0->1)!!!

Вообще, меня интересует такой общий вопрос: как грамотно (наиболее просто, с наименьшими затратами) принять (в регистр) цифровой сигнал (1 битовый), поступающий с известной заданной частотой, при условии, что тактовый сигнал не поступает, имея в распоряжении все возможности ПЛИС? Может быть уже существуют оптимальные методы, я не в курсе!!!

ответил вам на телесиськах

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

самые простые примеры это старт стоп - манчестер - битстаффинг - запрещенные коды - и тд и тп

[Jools]

Так все же как посоветуете поступить, использовать Clock Data Recovery, если да, то что это такое (где про него можно почитать)? А может стоить использовать другие способы приема сигнала (например, в ПЛИС взять синхросигнал частота которого в 4 раза быстрее частоты входных данных, и уже на основании 4-х выборок определять значение входного бита (мои догадки, не факт что это работает))???

Вот почитайте очень полезную книгу.

Сухман С.М. Бернов А.В. Шевкопляс Б.В.
Синхронизация в телекоммуникационных системах.
объем 5 Мб

[sazh]

///Если я не правильно понял datasheet на MLX90121, поправьте меня. Хотя по другому его понять сложно!
Из этой фразы можно сделать вывод, что живьем Вы еще не смотрели.
Действительно не однозначно написано. Наверно DSYNC все таки должен присутствовать.
значок x нигде не расписанан. А вдруг это " безразлично" как например на странице 10
Во всяком случае уверенный прием без DSYNC маловероятен. Ведь это простой протокол. (В потоке данных не зашифрован синхроимпульс).

[ArAhis]

Не факт, что принимаемый сигнал будет 111000111000! Если один из фронтов тактового сигнала совподет с фронтом входного сигнала, то может получиться следующее: пусть, например, фронт входного сигнала совпадает с каждым 3-м фронтом синхросигнала, тогда по этому фронте мы можем принять, либо '1' либо '0', причем не факт, что входной сигнал на этом фронте всегда будет искажаться в одну сторону, например, мы можем принять любой из следующих сигналов:
110000111001 или
111000110000 и т.д.
Т.е. на каждом 3-м фронте тактового сигнала, мы можем принять как '1', так и '0', не зависимо от фронта входного сигнала (1->0 или 0->1)!!!

Вообще-то там дальше было написано про подсчёт единиц или нулей, ага?
110 000 111 001 — 2 0 3 1 — 1 0 1 0
111 000 110 000 — 3 0 2 0 — 1 0 1 0

Если k взять побольше, всё будет с приличной вероятностью. «Идеальный» приём сигнала в таких условиях представляется задачей в общем случае не разрешимой. Если два устройства питаются независимыми синхросигналами, то синхронизовать их в общем случае без передачи синхросигналов нельзя. Например передаётся ноль. За какое-то время генераторы в устройствах разойдутся так, что сказать сколько нулевых бит прошло между двумя моментами времени достоверно будет нельзя и никакие ресурсы ПЛИС тут не помогут.

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

Размышлял тут по поводу сверх-семплирования и пришел к следующим выводам:
- сверх-семплирование с частотами большими в 2, 4, 6, 8,... раз частоты входного сигнала не поможет, поскольку в анализируемых 2, 4, 6, 8,...-битных выборках может быть равное число '1' и '0', и тогда не понятно какой сигнал выбирать - '1' или '0';
- сверх-семплирование с частотами в 3, 5, 7,... раз больше частоты входного сигнала также непонятно: может возникнуть ситуация, когда фронт сигнала совпадет с центральным отсчетом сверх-семплированного сигнала; например, сигнал 01, сверх-семплированный с частотой в 5 раз больше может приняться как сигнал 00011 или как сигнал 00111 (центральный бит попал на фронт перехода 0->1) и тогда не понятно, что брать - '1' или '0'.

[sK0T]

Размышлял тут по поводу сверх-семплирования и пришел к следующим выводам:
- сверх-семплирование с частотами большими в 2, 4, 6, 8,... раз частоты входного сигнала не поможет, поскольку в анализируемых 2, 4, 6, 8,...-битных выборках может быть равное число '1' и '0', и тогда не понятно какой сигнал выбирать - '1' или '0';
- сверх-семплирование с частотами в 3, 5, 7,... раз больше частоты входного сигнала также непонятно: может возникнуть ситуация, когда фронт сигнала совпадет с центральным отсчетом сверх-семплированного сигнала; например, сигнал 01, сверх-семплированный с частотой в 5 раз больше может приняться как сигнал 00011 или как сигнал 00111 (центральный бит попал на фронт перехода 0->1) и тогда не понятно, что брать - '1' или '0'.

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

00010 01010

(не синхронизированный буфер) 000 000 001 (поймали переход)111 000 (кончился буфер, начали сначала, но уже синхронизированно) 000 111 000 111 000