делитель частоты и джиттер, влияние ПЛИС на джиттер Опции

[sysel]

Здравствуйте!
Задача такова: имеется генератор с частотой 33 МГц и джиттером N пикосекунд (генератор подключен ко входу CLK0 ПЛИС семейства Cyclone III).
требуется на ПЛИС реализовать управляемый делитель частоты (1/2, 1/4, 1/6, 1/8, 1/10, 1/12, 1/14, 1/16). Требуется на выходе делителя получить сигнал с как можно меньшим джиттером (разумеется, джиттер меньше чем N пс получить не выйдет).

Моё решение:

Код

LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;

ENTITY clkdiv IS
    GENERIC
        (
            divsz : natural := 3 -- разрядность счетчика
        );    
    PORT
        (
            clk: in std_logic; -- входной клок
            div: in std_logic_vector((divsz-1) downto 0); -- коэффициент деления
            sco: out std_logic -- выходной клок
        );
END clkdiv;

ARCHITECTURE rtl OF clkdiv IS
    signal CN : std_logic_vector((divsz-1) downto 0); -- счетчик
    signal T,Q : std_logic;
BEGIN
    T<='1' when (CN=div) else '0';
    process (clk,T)
    begin
        if (falling_edge(clk)) then    -- по спаду клока
            if (T='1') then
                CN<=(others=>'0');
            else
                CN<=CN+1;
            end if;
        end if;
    end process;
    
    process (clk,T)
    begin
        if (rising_edge(clk) and (T='1')) then -- по фронту клока
            Q<=not Q;
        end if;
    end process;
    sco<=Q;
END rtl;

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

Вопросы:
1) насколько корректна такая реализация?
2) как такое решение может повлиять на джиттер выходного сигнала?
3) ПЛИС и джиттер - как они вообще связаны.

Эскизы прикрепленных изображений

 

[Boris_TS]

Мдааа. Конечно, я с Cyclon 3 не работал, но визуально схема - отвратительная (на уровне начинающего):
1. Выходной триггер имеет обратную связь, в нормальных ПЛИС в IOB это не ложиться (или у Cyclon 3 нет выходных триггеров ?) - соответственно будет прирост jitter'а за счет передачи логического сигнала к выходному буферу (обычно clock распространяеста по ПЛИС с меньшим jitter'ом, чем все остальные сигналы).
2. Э-хе-хе... Кто ж так делитель делает ??! Нормальные люди используют выходной перенос (назовём его CY) загружаемого счетчика: сам CY подается на счетный триггер, сигнал с которого подается на дополнительный выходной триггер (обязательно выходной триггер, иначе дополнительный прирост jitter’а). Дополнительно CY подаётся на вход Load это загружаемого счётчика, а вот значением, которое загружается - выбирается количество тактов, которое счетчик будет досчитывать до переноса (т.е. коэффициент деления). Такая схема значительно компактнее и быстродейственней... если конечно суметь правильно сделать тот самый загружаемый счетчик.

[sazh]

Нормальные люди используют выходной перенос (назовём его CY) загружаемого счетчика: сам CY подается на счетный триггер, сигнал с которого подается на дополнительный выходной триггер (обязательно выходной триггер, иначе дополнительный прирост jitter’а). Дополнительно CY подаётся на вход Load это загружаемого счётчика, а вот значением, которое загружается - выбирается количество тактов, которое счетчик будет досчитывать до переноса (т.е. коэффициент деления). Такая схема значительно компактнее и быстродейственней... если конечно суметь правильно сделать тот самый загружаемый счетчик.

Примерчик можно?

[Boris_TS]

Примерчик можно?

Вот пример подобного делителя (на 2,4,6,8,10,12,14,16).

Код

library IEEE;
use IEEE.std_logic_1164.all;
library unisim;
use unisim.vcomponents.all;
library work;
use work.HardSynP.all;

entity DIV is port (
    DIV_RG_D:    in    std_logic_vector(2 downto 0);
    DIV_RG_CE:    in    std_logic;
    CLK:        in    std_logic;
    OUT_CLK:    out    std_logic );
end entity;

architecture Tushka of DIV is
    signal    DIV_RG:            std_logic_vector(2 downto 0);

    signal    DIV_CB_CY:        std_logic;
    signal    DIV_CB_CY_L:    std_logic;

    signal    OUT_CLK_INT_FF:    std_logic := '0';
    signal    OUT_CLK_IOB_FF:    std_logic := '0';

    attribute IOB of OUT_CLK_IOB_FF: signal is "true";
begin
    DIV_RG_I: entity HS_FD(FDRE)
    generic map ( nInit => 0,  nX => 1,  nY => 0,  sUSet => "DIV_CB" )
    port map ( D => DIV_RG_D,  CE => DIV_RG_CE,  C => CLK,  INIT => '0',  Q => DIV_RG );
    
    DIV_CB_CY_FF: entity HS_CB_CI_FD(CB_CI_FD)
    generic map ( nInit => 0,  nX => 0,  nY => 3,  sUSet => "DIV_CB" )
    port map ( CE => '1',  C => CLK,  INIT => '0',  Q => DIV_CB_CY_L,  CI => DIV_CB_CY);
    
    DIV_CB: entity HS_CBRELIO(CBRELIO)
    generic map ( nInit => 0,  nX => 0,  nY => 0,  sUSet => "DIV_CB" )
    port map ( D => DIV_RG,  L => DIV_CB_CY_L,  CE => '1',  C => CLK,  INIT => '0',  CI => '1',  CO => DIV_CB_CY );
    
    OUT_CLK_INT_FF <= not(OUT_CLK_INT_FF) when rising_edge(CLK) and DIV_CB_CY = '1';
    OUT_CLK_IOB_FF <= not(OUT_CLK_INT_FF) when rising_edge(CLK) and DIV_CB_CY = '1';
    
    OUT_CLK_OBUF: component OBUF port map ( I => OUT_CLK_IOB_FF,  O => OUT_CLK);
end architecture;

Если необходимо еще выше поднять рабочую частоту, то тогда вместо DIV_CB_CY необходимо использовать DIV_CB_CY_L:

Код

    OUT_CLK_INT_FF <= not(OUT_CLK_INT_FF) when rising_edge(CLK) and DIV_CB_CY_L = '1';
    OUT_CLK_IOB_FF <= not(OUT_CLK_INT_FF) when rising_edge(CLK) and DIV_CB_CY_L = '1';

Думаю необходимо дать следующие пояснения:
1. Это переработанное ядро управляемого делителя частоты (в оригинале был 24 разрядный делитель, да и использовался сам сигнал DIV_CB_CY_L)
2. Описанная выше схема использует мою собственную библиотеку HardSyn. Эта библиотека имеет набор различных элементов оптимизированных под конкретные кристаллы (в приведенном примере для Xilinx Spartan-3x).
3. Почти все примитивы в элементах библиотеки имеют constraint RLOC, что позволяет задать взаимное расположение элементов (sUSet - задает название группы, а nX и nY - относительное положение "вершины" элемента).
4. HS_FD(FDRE) - просто D триггера.
5. HS_CBRELIO(CBRELIO) - загружаемый счетчик (необычностью данного счетчика является то, что инкремент производиться всегда, а вход L задает что сейчас необходимо инкрементировать: текущее значение счетчика (L := '0'), или входные данные - D (L := '1'). Т.к. цепи переноса никогда не блокируются, а вся логика в каждом разряде использует только 1 LUT - то достигается предельно возможное быстродействие).
6. HS_CB_CI_FD(CB_CI_FD) - триггер, предназначенный для поимки выходного переноса счетчика (использует dedicated линии переноса - имеющие "нулевую" задержку).

Да, понимаю, при таком подходе лучше, конечно, использовать схемное отображение соединения блоков - нагляднее и красивее... но, видать не судьба. Со схемными редакторами есть проблемы при обновлении ПО, а эта библиотека пережила Xilinx ISE от 5.1 до 11.1, да и у AHDL со схемным редактором при смене версий тоже не всё гладко. А код на языке - он для всех версий одинаков (и можно после работы в более новой среде безболезненно возвращаться к предшествующим).

[SM]

необычностью данного счетчика является то, что инкремент производиться всегда, а вход L задает что сейчас необходимо инкрементировать: текущее значение счетчика (L := '0'), или входные данные - D (L := '1'). Т.к. цепи переноса никогда не блокируются, а вся логика в каждом разряде использует только 1 LUT - то достигается предельно возможное быстродействие).

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

Эскизы прикрепленных изображений