Ваделение клока из данных., Кто знает как выделить частоту из приходящих данных. Опции

[shamray]

Дано: данные идут со скоростью 2МБит. Необходимо выделить клок из этого потока данных. Есть задающий генератор на 16МГц. Вижу что надо строить цифровой ПЛЛ но вот как - незнаю. Надоумте пожалусто.

[one_man_show]

Вы про данные подробнее дайте описание. Какой формат, протокол и т.п. ? Вы сами что-то хотите сделать или это реинжениринг? Если сами, то для простоты смотрите в сторону кода Манчестера, там клок выделяется достоверно и легко, а генерируется с помощью смеси данных и клока через исключающее ИЛИ.

[shamray]

С данными я ничего сделать не могу. Кодировка - NRZ. Данные идут достаточно редко (8 бит данных на 248 бит нулевых). Нужно сделать устройство на вход которого подается такой поток данных, а на выходе клок и синхронизированные с ним эти-же данные.

[maksya]

Такая штука вроде носит название CDR - Clock Data Recovery. Сейчас под рукой нет инфы, попробуйте поискать самостоятельно.

[line]

Можно для начала посмотреть Сухман и др. "Синхронизация в телекоммуникационных системах". Если кому-то надо, могу выложить на местный ФТП.

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

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

 Contents.pdf ( 348.08 килобайт ) Кол-во скачиваний: 629
 Chapter9.pdf ( 1.33 мегабайт ) Кол-во скачиваний: 490

 

[lutik]

вот так делали и все работало при соотношении скорости передачи к частоте клока 1/4

entity receiver is
generic
(
FRAME_RATE : natural
;BIT_PER_FRAME : natural
;PACKET_COUNT : natural
);
...
...
...

signal RXs : std_logic;
signal LatchBit : std_logic;


IN_RX: dff port map(clk,RX,Res,'0',RXs);

NET_SYNC:
block
--------------
subtype TNetClkDiv is integer range 0 to ceil(real(CLK_FREQ/FRAME_RATE/BIT_PER_FRAME))-1; signal NetClkDiv : TNetClkDiv;
signal RXp : std_logic;
signal NewBit: std_logic;
--------------
begin
IN_P: Front port map(RXs,clk,RXp,open,open);
--**************************************************
NET_CLOCK:
process(clk) begin
if clk='1' and clk'event then
if Res = '1' then
NetClkDiv <= TNetClkDiv'high; --|
NewBit <= '0';
elsif RXp = '1' then
NetClkDiv <= TNetClkDiv'high-1;
NewBit <= '1';
elsif NetClkDiv = 0 then
NetClkDiv <= TNetClkDiv'high-1;
NewBit <= not NewBit;
else
NetClkDiv <= NetClkDiv - '1';
end if;
end if;
end process;
LP1: Front port map(NewBit,clk,LatchBit,open,open);
--**************************************************
end block;

компонент Front вида

entity front is
port (data,clk : in std_logic;
pQ,mQ,dQ : out std_logic);
end;
architecture arc of Front is
signal s : std_logic ;
begin
process(clk) begin
if clk='1' and clk'event then
s <= not data;
end if ;
end process ;
pQ <= data and s ;
mQ <= not(data or s);
dQ <= not data xor s ;
end;

смысл в том, что в отсутствии пакета на NewBit будет идти интересующий вас клок, но не синхронизированый с клоком передатчика.
при поступлении стартового бита (у меня перепад 0 -> 1) генератор подстроится под входные данные, и будет подстраиватся на каждом таком перепаде.

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

а если хотите именно клок выделить - слушайте one_man_show, и скорее всего альтернативы не найдете

[Builder]

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

[DSIoffe]

Если кому-то надо, могу выложить на местный ФТП.

Очень было бы хорошо. Заранее признателен.
Подскажете, как найти?

[Jools]

Если кому-то надо, могу выложить на местный ФТП.

Очень было бы хорошо. Заранее признателен.
Подскажете, как найти?

Да прямо у авторов и возьмите.
У них качественный PDF, вместо криво отсканерных djvu гуляющих по Рунету.

[shamray]

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

Как я и говорил, с данными я немогу ничего сделать. Они мне идут "как есть". Схема предложенная в книге "Синхронизация в телекоммуникационных сетях" на стр. 244 рис 9.7 работает не так как хотелось бы - иногда проскакивает лишний клок. Я думаю что это из=за несовпадения частот данных и задающего кварца. Может стоит увеличить частоту каврца или это не поможет?

[sazh]

//Как я и говорил, с данными я не могу ничего сделать. Они мне идут "как есть". Схема предложенная в книге "Синхронизация в телекоммуникационных сетях" на стр. 244 рис 9.7 работает не так как хотелось бы - иногда проскакивает лишний клок. Я думаю что это из за несовпадения частот данных и задающего кварца. Может стоит увеличить частоту кварца или это не поможет?//
Как схема, объясняющая принцип работы , она верна. Она действительно выделяет синхроимпульсы из потока данных, вот только без данных эти синхроимпульсы никому не нужны, а эти данные не имеют начала и конца. Фактически это только инструмент подстройки внутренних часов по любому перепаду во входном потоке данных. А значит и поток данных может быть только манчестерским, что позволяет подстраивать эти часы в каждом бите входной последовательности. При этом в начале посылки обязательно должен быть синхроимпульс длительностью в три такта битовой посылки. Если данные принимать на сдвигающий регистр минимального размера в 6 разрядов на удвоенной относительно несущей частоте, то значения 000111 или 111000 однозначно говорит о наличии синхроимпульса (в Манчестере таких данных не бывает), а дальше можно отсчитать необходимое количество данных. Это четные или нечетные отсчеты сдвигающего регистра.
Вот фактически таже схема.
module decoder_manchester
(
input in_data, // 1 mHz
input clk, // 12 mHz
output [5:0] out_data
);

reg [2:0] shift_data;
reg [2:0] ct;
reg [5:0] shift_rg;

wire s_clr;


always @(posedge clk)
begin
shift_data <= {shift_data[1:0], in_data};
end

assign s_clr = shift_data[1] ^ shift_data[2];

always @(posedge clk) // делитель на 6
begin
if (s_clr)
ct <= 3'h0;
else if (ct == 3'h5)
ct <= 3'h0;
else
ct <= ct + 1'b1;
end

always @(posedge clk)
begin
if (ct == 3'h2) // 2 mHz
shift_rg <= {shift_rg[4:0], shift_data[2]};
end

assign out_data = shift_rg;

endmodule
Если использовать принцип приема данных как в rs232, то без старт стоповых битов тоже не обойтись. Понятно, что здесь синхронизируются по середине стартового бита на всю длину посылки и нарезают биты на несущей частоте. Уровень молчания это стоп бит (инверсный стартовому).
Если нет возможности каким либо образом идентифицировать начало посылки данных,
Вы будете терять данные.
Исходя из этих соображений если поток манчестерский, то для 2Мбит 16 мГц маловато.

[des00]

Если использовать принцип приема данных как в rs232, то без старт стоповых битов тоже не обойтись. Понятно, что здесь синхронизируются по середине стартового бита на всю длину посылки и нарезают биты на несущей частоте. Уровень молчания это стоп бит (инверсный стартовому).
Если нет возможности каким либо образом идентифицировать начало посылки данных,
Вы будете терять данные.
Исходя из этих соображений если поток манчестерский, то для 2Мбит 16 мГц маловато.

Хммм а может байт стафинг и на вход коррелятор ??

[sazh]

Хммм а может байт стафинг и на вход коррелятор ??
К сожалению я не знаком с такими понятиями. Может приведете законченный пример, чтобы можно было проанализировать в RTL просмотрщике.

[Magnum]

Для начала всёже хлтелось бы узнать поподробнее о потоке данных 2Мбита, к которому надо сгенерировать клок, а точнее на сколько он стабилен, может ли в нем быть джиттер и вандер. От этого в конечном счете и будет зависеть возможность восстановления тактовой.

[des00]

К сожалению я не знаком с такими понятиями. Может приведете законченный пример, чтобы можно было проанализировать в RTL просмотрщике.

Хмм насчет примера помочь не могу, не делал. только теорию изучал, но смысл в том, что если вам все равно подмешивать в поток синхро слова, то слово это хорошо выделяеться корелятором, который может использоваться для синхры под символьную частоту.
А байт стаффинг/бит стафинг нужен для кодирования слов данных == синхрослову, иначе у вас будет сбой посылки

[Builder]

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

Как я и говорил, с данными я немогу ничего сделать. Они мне идут "как есть". Схема предложенная в книге "Синхронизация в телекоммуникационных сетях" на стр. 244 рис 9.7 работает не так как хотелось бы - иногда проскакивает лишний клок. Я думаю что это из=за несовпадения частот данных и задающего кварца. Может стоит увеличить частоту каврца или это не поможет?

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

[handy]

А такое не подойдет: Устройство для вычитания первого импульса из серии импульсов (В.В. Климов, "Импульсные ключи в цифровых устройствах", М., Радио и связь, 1989)

[woodman2]

К сожалению я не знаком с такими понятиями. Может приведете законченный пример, чтобы можно было проанализировать в RTL просмотрщике.

Хмм насчет примера помочь не могу, не делал. только теорию изучал, но смысл в том, что если вам все равно подмешивать в поток синхро слова, то слово это хорошо выделяеться корелятором, который может использоваться для синхры под символьную частоту.
А байт стаффинг/бит стафинг нужен для кодирования слов данных == синхрослову, иначе у вас будет сбой посылки

По поводу стаффинга: Staffing-вставка, бит или байт или др. ("служебная" иформация), специально "вставляемый" в поток данных для синхронизации и в конечном итоге передачи по цифровому каналу асинхронных данных без потерь и с восстановлением тактовой частоты на приемном конце.

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

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

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

К данной теме стаффинг, как видно, отношения не имеет, и как я понял другие "вставки" типа доп. синхропосылок для решения не приемлемы.

[des00]

Я имел в виду немного другое, а именно в любом битовом протоколе передачи данных возникают проблемы синхронизации пакетов данных при передаче по одному каналу.
Для этого можно ввести синхрослово, а на приемном конце разгребать потом по битно сравнивая кореляцию принятого "слова" с синхрословом. Но ИМХО здесь возможна ситуация, когда слово данных == синхрослову, то в таком случае, насколько я в курсе используеться подмена слова данных на другую последовательность. Именно это я понимал под стаффингом.

Хотя вероятно я ошибаюсь

[MosAic]

С данными я ничего сделать не могу. Кодировка - NRZ. Данные идут достаточно редко (8 бит данных на 248 бит нулевых). Нужно сделать устройство на вход которого подается такой поток данных, а на выходе клок и синхронизированные с ним эти-же данные.

А если в 1 будет только 1 бит данных? А как вы определите начало посылки, если первый бит нулевой? А если 8 бит данных будут нулевыми? А если это повторится несколько фреймов подряд или даже еще долго будет повторяться?

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

[woodman2]

des00:
///Я имел в виду немного другое, а именно в любом битовом протоколе передачи данных возникают проблемы синхронизации пакетов данных при передаче по одному каналу.
Для этого можно ввести синхрослово, а на приемном конце разгребать потом по битно сравнивая кореляцию принятого "слова" с синхрословом. Но ИМХО здесь возможна ситуация, когда слово данных == синхрослову, то в таком случае, насколько я в курсе используеться подмена слова данных на другую последовательность. Именно это я понимал под стаффингом.///

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

Вообще если принять изложенные данные как ТЗ,
то задача имеет решение
при нестабильности тактовой Тх не более 0,5Ти/248=2*Е-3.
Это грубо, а с учетом нестабильности приемного генератора, скважности или дискретности работы ЦФАПЧ на приеме, связанной с не очень большой величиной кварц. тактовой (1/8 такта в данном случае), а также упомянутый кем-то выше джиттер (фазовое дрожание битовых переходов) получится, что необходимо и достаточно применить обычные кварцованные генераторы на передаче и приеме, которые дадут в первом приближении 4-ю степень нестабильности.

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

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

Для начала всёже хлтелось бы узнать поподробнее о потоке данных 2Мбита, к которому надо сгенерировать клок, а точнее на сколько он стабилен, может ли в нем быть джиттер и вандер. От этого в конечном счете и будет зависеть возможность восстановления тактовой.

Объясните пожалуйста, что оно такое, вандер?
Спасибо

[sazh]

Подстройка фазы этого окна в цикле. А как это сделать (если принять условия задачи как данность).

[MosAic]

Вандер - это baseline wander - эффект плавания среднего уровня сигнала в зависимости от передаваемых данных. У Максима есть аппнот о его влиянии на джиттер.

Думаю, что условия задачи принимать как данность рановато. Скорее всего в источнике сигнала есть источник синхров. Иначе это не источник сигнала, а чистая провокация

[woodman]

Подстройка фазы этого окна в цикле. А как это сделать (если принять условия задачи как данность).

Ну это ж не есть проблема для схемотехника.
Ну возьмите счетчик по модулю 248, работающий от восстановленной тактовой частоты, а к нему подключите дешифратор, выдающий "1" при состоянии счетчика от "0" до "n" где n длина инф. посылки. А теперь постройте схему сброса его в ноль приходящими инф. посылками, и через х циклов получите цикловую синхронизацию.

Только не спрашивайте - а если в информации будут одни нули.
Вот Вы бы такое допустили?
Допустите на минуточку, что систему делают такие-же умные люди как Вы.
Наверное ввели бы и старт бит и контрольные биты для проверки достоверности..

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

А кстати, где это он? Он в зале?

[woodman]

Вандер - это baseline wander - эффект плавания среднего уровня сигнала в зависимости от передаваемых данных. У Максима есть аппнот о его влиянии на джиттер.

Думаю, что условия задачи принимать как данность рановато. Скорее всего в источнике сигнала есть источник синхров. Иначе это не источник сигнала, а чистая провокация

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

Да уж, провокация.
Как там было -
"С данными я ничего сделать не могу. Кодировка - NRZ. Данные идут достаточно редко (8 бит данных на 248 бит нулевых). Нужно сделать устройство на вход которого подается такой поток данных, а на выходе клок и синхронизированные с ним эти-же данные."
Про канал ни слова. Предполагаем что это медные провода, не длинные или согласованные в противном случае.

[MosAic]

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

В условиях нет ни слова о синхроимпульсах. Поэтому и настаиваю на более подробной информации об источнике. В представленном виде условие задачи ужасно...

А вот и ссылочка на Максимовский аппноут:
HFAN-09.0.4: NRZ Bandwidth - LF Cutoff and Baseline Wander

[woodman2]

[/quote]
В условиях нет ни слова о синхроимпульсах. Поэтому и настаиваю на более подробной информации об источнике. В представленном виде условие задачи ужасно...
[/quote]
И правильно!
[/quote]
А вот и ссылочка на Максимовский аппноут:
HFAN-09.0.4: NRZ Bandwidth - LF Cutoff and Baseline Wander
[/quote]

Спасибо, пошел читать.