Передача данных между частотными доменами, как правильно ? Опции

[v1vas]

Virtex 6
Есть два частотных домена, 50 MHz и 200 MHz
Клоки идут с Xilinx'го ClockWizard, утверждается, что они на 100% совпадают по фазе. Я так понимаю это не гарантированная фигня и из-за роутинга мы в некоторых местах плисины можем получить небольшое различие по времени прихода фронта волны ?
Соответственно логика моих рассуждений, раз во фронт медленного клока попадают два фронта быстрого, то во втором фронте быстрого мы можем сэмплить данные с медленного.

Код

constant MAINCLK_SAMPLE_STEP : integer := 1;
signal main_clk_cnt : integer range 0 to 3 := 0;

process (data_clock) --50 MHZ
begin
    if (rising_edge(data_clock)) then
        data_mainclk <= i_data;
        data_ready_mainclk <= i_data_ready;
        o_result <= result_mainclk;
    end if;
end process;

process (clock) --200MHZ
begin
    if (rising_edge(clock)) then
     if (reset = '0') then
    
     if (main_clk_cnt = 3) then main_clk_cnt <= 0; else main_clk_cnt <= main_clk_cnt + 1; end if;

        case SM_STATE is
         when SM_DATA_INPUT_FIRST_1 =>
            if (data_ready_mainclk = '1') and (main_clk_cnt = MAINCLK_SAMPLE_STEP) then
                dinp(63 downto 32) <= data_mainclk;                
                SM_STATE <= SM_DATA_INPUT_FIRST_2;
            end if;

............... и т.д.

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

Сообщение отредактировал v1vas - Mar 30 2015, 19:43

[Maverick]

Virtex 6
Есть два частотных домена, 50 MHz и 200 MHz
Клоки идут с Xilinx'го ClockWizard, утверждается, что они на 100% совпадают по фазе. Я так понимаю это не гарантированная фигня и из-за роутинга мы в некоторых местах плисины можем получить небольшое различие по времени прихода фронта волны ?
Соответственно логика моих рассуждений, раз во фронт медленного клока попадают два фронта быстрого, то во втором фронте быстрого мы можем сэмплить данные с медленного.

Код

constant MAINCLK_SAMPLE_STEP : integer := 1;
signal main_clk_cnt : integer range 0 to 3 := 0;

process (data_clock) --50 MHZ
begin
    if (rising_edge(data_clock)) then
        data_mainclk <= i_data;
        data_ready_mainclk <= i_data_ready;
        o_result <= result_mainclk;
    end if;
end process;

process (clock) --200MHZ
begin
    if (rising_edge(clock)) then
     if (reset = '0') then
    
     if (main_clk_cnt = 3) then main_clk_cnt <= 0; else main_clk_cnt <= main_clk_cnt + 1; end if;

        case SM_STATE is
         when SM_DATA_INPUT_FIRST_1 =>
            if (data_ready_mainclk = '1') and (main_clk_cnt = MAINCLK_SAMPLE_STEP) then
                dinp(63 downto 32) <= data_mainclk;                
                SM_STATE <= SM_DATA_INPUT_FIRST_2;
            end if;

............... и т.д.

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

сильно не вчитывался, в Ваше описание (не совсем верное рассуждение) - здесь теория
Но лучше в таких случаях использовать двупортовую память (с 2-мя клоками) или ФИФО (с 2-мя клоками)
Если схема использует сигнал готовности данных, то можно использовать описание ниже для передачи в другой клоковый домен (более высокой тактовой частоты) сигнал готовности данных:

Код

Детектор переднего и заднего фронтов импульса готовности данных

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;

entity det is
    Port ( clk : in  STD_LOGIC;
           input : in  STD_LOGIC;
           stroba  : out  STD_LOGIC;
           strobb : out  STD_LOGIC);
end det;

architecture Behavioral of det is

signal input_0, input_1, input_2 : STD_LOGIC;

begin

process(input, CLK, input_1, input_2)
begin
if (rising_edge(CLK)) then --- falling_edge(clk)
input_0 <= input;
input_1 <= input_0;
input_2 <= input_1;
end if;
end process;

stroba <= input_1 and (not input_2);
strobb <= (not input_1) and input_2;

end Behavioral;

[Timmy]

Virtex 6
Есть два частотных домена, 50 MHz и 200 MHz
Клоки идут с Xilinx'го ClockWizard, утверждается, что они на 100% совпадают по фазе. Я так понимаю это не гарантированная фигня и из-за роутинга мы в некоторых местах плисины можем получить небольшое различие по времени прихода фронта волны ?
Соответственно логика моих рассуждений, раз во фронт медленного клока попадают два фронта быстрого, то во втором фронте быстрого мы можем сэмплить данные с медленного.
Сиё творчество в симуляторе работает нормально.
Насколько вообще правилен такой подход ?
Интуитивно он мне не нравится, чувствую, что тут надо как-то по другому и все законстрейнить, но пока не могу понять как.
Ткните меня пожалуйста, как это нормально сделать ?

В вашем коде неправильно то, что main_clk_cnt не засинхронизирован с медленным клоком, от сброса к сбросу устройство может работать по-разному. Следует перевести медленный клок в логику(например, с помощью двух FF и xor), защёлкнуть его на FF быстрым клоком, выделить фронт, и привязать к этому фронту фазу чтения data_mainclk.
Достаточно, чтобы были правильно оконстрейнены клоки, и не была запрещена проверка путей между data_clock и clock, другие констрейны не нужны.
То, что советует Maverick, тоже в принципе правильно, но для случая синхронных клоков избыточно.
Это я предполагаю, что клоки выходят с одного PLL. Расхождение по фазе между ними тогда невелико, и его допустимость будет проверена при STA.

[Maverick]

В вашем коде неправильно то, что main_clk_cnt не засинхронизирован с медленным клоком, от сброса к сбросу устройство может работать по-разному. Следует перевести медленный клок в логику(например, с помощью двух FF и xor), защёлкнуть его на FF быстрым клоком, выделить фронт, и привязать к этому фронту фазу чтения data_mainclk.
Достаточно, чтобы были правильно оконстрейнены клоки, и не была запрещена проверка путей между data_clock и clock, другие констрейны не нужны.
То, что советует Maverick, тоже в принципе правильно, но для случая синхронных клоков избыточно.
Это я предполагаю, что клоки выходят с одного PLL. Расхождение по фазе между ними тогда невелико, и его допустимость будет проверена при STA.

У меня был случай, проект вырос и мне пришлось использовать несколько PLL, а потом появились причины поменять генерируемые в PLL тактовые частоты с одного перекинуть на другой. Естественно я даже и не вспомнил про применяемую "упрощенную схему" синхронизацию.
Ох, потом я "наигрался" с этой упрощенной схемой, пока выявил этот баг.
Сейчас стараюсь так не делать, упрощенную схему не применяю - делаю полную синхронизацию по всем правилам - благо ПЛИС позволяют...

[Bad0512]

У меня был случай, проект вырос и мне пришлось использовать несколько PLL, а потом появились причины поменять генерируемые в PLL тактовые частоты с одного перекинуть на другой. Естественно я даже и не вспомнил про применяемую "упрощенную схему" синхронизацию.
Ох, потом я "наигрался" с этой упрощенной схемой, пока выявил этот баг.
Сейчас стараюсь так не делать, упрощенную схему не применяю - делаю полную синхронизацию по всем правилам - благо ПЛИС позволяют...

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

[Maverick]

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

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

[v1vas]

Парни, просто хочу вас всех поблагодарить, за помощь тут и тут =) Оно с вашими советами всё заработало, причем куда эффективнее, чем я изначально рассчитывал (логику удалось запустить на 320MHz).
Отдельное спасибо господам Maverick Bad0512 Timmy des00 ASN и iosifk!