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

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

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

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

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

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

вот так делали и все работало при соотношении скорости передачи к частоте клока 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, и скорее всего альтернативы не найдете

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

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

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

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

//Как я и говорил, с данными я не могу ничего сделать. Они мне идут "как есть". Схема предложенная в книге "Синхронизация в телекоммуникационных сетях" на стр. 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 мГц маловато.

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

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

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

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