[negiin 0]

В большом проекте получается порядка 20 тактовых домена. Предполагается работать с трафиком похожем на ethernet. По предыдущем проектам возникали проблемы при разводке кристалла из-за нехватки глобальных клоков. Есть 2 возможных выхода:

1) Оставить 20 клоков.

2) Сделать в каждом модуле вход разрешения и использовать один клок(чуть большей чем необходимо).

Как лучше поступить?

[iosifk 3]

В большом проекте получается порядка 20 тактовых домена. Предполагается работать с трафиком похожем на ethernet. По предыдущем проектам возникали проблемы при разводке кристалла из-за нехватки глобальных клоков. Есть 2 возможных выхода:

1) Оставить 20 клоков.

2) Сделать в каждом модуле вход разрешения и использовать один клок(чуть большей чем необходимо).

Как лучше поступить?

№2 однозначно...

 

[alexadmin 0]

На самом деле вопрос тот еще. С системной точки зрения один клок - безусловно проще и меньше рисков на "функциональном" уровне. Дальше же начинаются всякие "но".

Если проект большой и сложный, то единый клок (да еще большей частоты, чем минимально необходим) гуляющий по всему кристаллу может стать проблемой в плане производительности. Недаром в современных кристаллах стали появляться клоковые цепи не только глобальные, но и разделенные по регионам. Так что если какие-то части проекта можно уложить в отдельный регион кристалла и использовать региональный клок - это плюс. Понятное дело, что если кристалл простенький только с общими глобальными клоками, то выбор намного упрощается ;)

В общем стоит смотреть по используемому кристаллу и нагрузке как по ресурсам, так и по требуемой частоте.

[ASN 0]

Denisnovel

Сложный вопрос.

IMHO, от структуры проекта многое зависит.

У нас 5 разных таковых частот в проекте, но модули решают каждый свою задачу, имеют хорошую локализацию (в кристалле и на плате) и частоты формируется от одной исходной.

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

Без информации о "потрохах" трудно что-то дельное посоветовать.

[des00 25]

у меня в проектах гуляет до 20 тактовых. разумное разбиение и корректные переходы между клоками рулят.

[johan 0]

Одна системная по разработке и поддержке, конечно, приятнее чем куча клоков.

 

Какие значения частот у этих 20 клоков? Меняются ли они динамически во время работы? Или все клоки это RX_CLK, от каких-то трансиверов?

[ViKo 1]

Не могу представить 20 тактовых частот, могу, максимум, 5. Цифры назовите, пожалуйста, не дайте пропасть тупым. :rolleyes:

[krux 8]

понимаю, если бы частоты соответствовали 20 различным видам интерфейсов, критичных к ppm и/или джиттеру.

в противном случае не понимаю.

[negiin 0]

Одна системная по разработке и поддержке, конечно, приятнее чем куча клоков.

 

Какие значения частот у этих 20 клоков? Меняются ли они динамически во время работы? Или все клоки это RX_CLK, от каких-то трансиверов?

150-166 MHz. Да все TX RX от трансиверов. Частоты могут динамически меняться. Интерфейсы критичны к джиттеру и ppm.

[krux 8]

найти то место, где можно перейти от этих 20 разных к одному общему, например, 200МГц. дальше всю обработку делать на нём.

 

если какой-нибудь STM или OTN, то однозначно - так и делается.

в STM переход производится сразу после обработки указателей H1H2. VC4 перекладывается в фифо, а вынимается на той частоте, на которой работает основной домен, занимающийся обработкой.

[Maverick_ 15]

В большом проекте получается порядка 20 тактовых домена. Предполагается работать с трафиком похожем на ethernet. По предыдущем проектам возникали проблемы при разводке кристалла из-за нехватки глобальных клоков. Есть 2 возможных выхода:

1) Оставить 20 клоков.

2) Сделать в каждом модуле вход разрешения и использовать один клок(чуть большей чем необходимо).

Как лучше поступить?

Я бы выбрал пункт 2.

PS Если хорошо подумать думаю можно уменьшить кол-во тактовых...

[iosifk 3]

150-166 MHz. Да все TX RX от трансиверов. Частоты могут динамически меняться. Интерфейсы критичны к джиттеру и ppm.

Посмотрите, как это сделано в ПЛИС Акроникс. Там для каждого набора из 8 (кажется так) входных выводов под RX есть своя тактовая... Потом коммутатор тактовых... И еще аппаратные приемники со сдвигами битов...

 

 

[Maverick_ 15]

Посмотрите, это, возможно поможет

 

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;

library UNISIM;
use UNISIM.VComponents.all;

entity dcm_clockgen_test is
    Port ( clk_in  : in  STD_LOGIC;
           clk_out : out STD_LOGIC;
           sw      : in  STD_LOGIC_VECTOR (3 downto 0));
end dcm_clockgen_test;

architecture Behavioral of dcm_clockgen_test is
   signal prog_data_sr : std_logic_vector(27 downto 0) := (others => '0');
   signal prog_en_sr   : std_logic_vector(27 downto 0) := (others => '0');
   
   signal prog_data    : std_logic;
   signal prog_en      : std_logic;
   
   signal desired_mode: std_logic_vector(3 downto 0)   := "0001";
   signal current_mode: std_logic_vector(3 downto 0)   := "0000";
begin
   prog_data <= prog_data_sr(0);
   prog_en   <= prog_en_sr(0);
   
process(clk_in)
   begin
      if rising_edge(clk_in) then
         -- Update the clock reprogramming signals
         prog_en_sr   <= '0' & prog_en_sr((prog_en_sr'length)-1 downto 1);
         prog_data_sr <= '0' & prog_data_sr((prog_data_sr'length)-1 downto 1);
         
         -- Do we need to switch modes? 
         if desired_mode /= current_mode and unsigned(prog_en_sr) = 0 then
            case desired_mode is 
            when "0001"  =>
               -- switch to 25MHz
               prog_en_sr   <= "1000" & "11111111" & "11" & "0000" & "11111111" & "11"; -- Two 10-bit xfers + 1-bit 'go'
               prog_data_sr <= "0000" & "00001010" & "11" & "0000" & "00001101" & "01"; -- Code for D 14 M 11
               current_mode <= desired_mode;

            when "0010"  =>
               -- switch to 40MHz
               prog_en_sr   <= "1000" & "11111111" & "11" & "0000" & "11111111" & "11"; -- Two x 10-bit xfers + 1-bit 'go'
               prog_data_sr <= "0000" & "00000100" & "11" & "0000" & "00000011" & "01"; -- Code for D 5 M 4
               current_mode <= desired_mode;

            when "0100"  =>
               -- switch to 64.0MHz 
               prog_en_sr   <= "1000" & "11111111" & "11" & "0000" & "11111111" & "11"; -- Two x 10-bit xfers + 1-bit 'go'
               prog_data_sr <= "0000" & "00000001" & "11" & "0000" & "00000000" & "01"; -- Code for D 1 M 2
               current_mode <= desired_mode;

            when "1000"  =>
               -- switch to 74.6MHz
               prog_en_sr   <= "1000" & "11111111" & "11" & "0000" & "11111111" & "11"; -- Two x 10-bit xfers + 1-bit 'go'
               prog_data_sr <= "0000" & "00000110" & "11" & "0000" & "00000010" & "01"; -- Code for D 3 M 7
               current_mode <= desired_mode;

            when others =>
            
            end case;
         end if;
         if sw /= "0000" then
            desired_mode <= sw;
         end if;
      end if;
   end process;

DCM_CLKGEN_inst : DCM_CLKGEN
   generic map (
      CLKFXDV_DIVIDE => 2,    
      CLKFX_DIVIDE   => 14,   
      CLKFX_MD_MAX   => 2.0,  
      CLKFX_MULTIPLY => 11,   
      CLKIN_PERIOD   => 31.25, 
      SPREAD_SPECTRUM => "NONE", 
      STARTUP_WAIT => FALSE
   )
   
   port map (
      CLKIN     => clk_in,   
      CLKFX     => clk_out,  
      CLKFX180  => open,     
      CLKFXDV   => open,     
      LOCKED    => open,     
      PROGDONE  => open,     
      STATUS    => open,     
      FREEZEDCM => '0',      
      PROGCLK   => clk_in,   
      PROGDATA  => PROG_DATA,
      PROGEN    => PROG_EN,  
      RST       => '0'       
   );

end Behavioral;

чтобы не плодить тактовые частоты - программировал "на лету" DCM_CLKGEN (xilinx - Spartan 6 Clocking Resources User Guide for more info)

[eugen_pcad_ru 0]

№2 предпочтителен. К сожалению, в сложных проектах не всегда возможен. Пришел к необходимости замены ПЛИС с б0льшим числом глобальных тактов.