В большом проекте получается порядка 20 тактовых домена. Предполагается работать с трафиком похожем на ethernet. По предыдущем проектам возникали проблемы при разводке кристалла из-за нехватки глобальных клоков. Есть 2 возможных выхода:
1) Оставить 20 клоков.
2) Сделать в каждом модуле вход разрешения и использовать один клок(чуть большей чем необходимо).
Как лучше поступить?
Полная версия этой страницы: Много тактовых в большом проекте
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Цитата(Denisnovel @ Aug 6 2015, 16:30) 
В большом проекте получается порядка 20 тактовых домена. Предполагается работать с трафиком похожем на ethernet. По предыдущем проектам возникали проблемы при разводке кристалла из-за нехватки глобальных клоков. Есть 2 возможных выхода:
1) Оставить 20 клоков.
2) Сделать в каждом модуле вход разрешения и использовать один клок(чуть большей чем необходимо).
Как лучше поступить?
1) Оставить 20 клоков.
2) Сделать в каждом модуле вход разрешения и использовать один клок(чуть большей чем необходимо).
Как лучше поступить?
№2 однозначно...
На самом деле вопрос тот еще. С системной точки зрения один клок - безусловно проще и меньше рисков на "функциональном" уровне. Дальше же начинаются всякие "но".
Если проект большой и сложный, то единый клок (да еще большей частоты, чем минимально необходим) гуляющий по всему кристаллу может стать проблемой в плане производительности. Недаром в современных кристаллах стали появляться клоковые цепи не только глобальные, но и разделенные по регионам. Так что если какие-то части проекта можно уложить в отдельный регион кристалла и использовать региональный клок - это плюс. Понятное дело, что если кристалл простенький только с общими глобальными клоками, то выбор намного упрощается
В общем стоит смотреть по используемому кристаллу и нагрузке как по ресурсам, так и по требуемой частоте.
Если проект большой и сложный, то единый клок (да еще большей частоты, чем минимально необходим) гуляющий по всему кристаллу может стать проблемой в плане производительности. Недаром в современных кристаллах стали появляться клоковые цепи не только глобальные, но и разделенные по регионам. Так что если какие-то части проекта можно уложить в отдельный регион кристалла и использовать региональный клок - это плюс. Понятное дело, что если кристалл простенький только с общими глобальными клоками, то выбор намного упрощается
В общем стоит смотреть по используемому кристаллу и нагрузке как по ресурсам, так и по требуемой частоте.
Denisnovel
Сложный вопрос.
IMHO, от структуры проекта многое зависит.
У нас 5 разных таковых частот в проекте, но модули решают каждый свою задачу, имеют хорошую локализацию (в кристалле и на плате) и частоты формируется от одной исходной.
На выходе модулей переход на глобальную частоту: и отлаживать проще и кристалл используется эффективнее.
Без информации о "потрохах" трудно что-то дельное посоветовать.
Сложный вопрос.
IMHO, от структуры проекта многое зависит.
У нас 5 разных таковых частот в проекте, но модули решают каждый свою задачу, имеют хорошую локализацию (в кристалле и на плате) и частоты формируется от одной исходной.
На выходе модулей переход на глобальную частоту: и отлаживать проще и кристалл используется эффективнее.
Без информации о "потрохах" трудно что-то дельное посоветовать.
у меня в проектах гуляет до 20 тактовых. разумное разбиение и корректные переходы между клоками рулят.
Одна системная по разработке и поддержке, конечно, приятнее чем куча клоков.
Какие значения частот у этих 20 клоков? Меняются ли они динамически во время работы? Или все клоки это RX_CLK, от каких-то трансиверов?
Какие значения частот у этих 20 клоков? Меняются ли они динамически во время работы? Или все клоки это RX_CLK, от каких-то трансиверов?
Не могу представить 20 тактовых частот, могу, максимум, 5. Цифры назовите, пожалуйста, не дайте пропасть тупым. 
понимаю, если бы частоты соответствовали 20 различным видам интерфейсов, критичных к ppm и/или джиттеру.
в противном случае не понимаю.
в противном случае не понимаю.
Цитата(johan @ Aug 6 2015, 18:16)
Одна системная по разработке и поддержке, конечно, приятнее чем куча клоков.
Какие значения частот у этих 20 клоков? Меняются ли они динамически во время работы? Или все клоки это RX_CLK, от каких-то трансиверов?
Какие значения частот у этих 20 клоков? Меняются ли они динамически во время работы? Или все клоки это RX_CLK, от каких-то трансиверов?
150-166 MHz. Да все TX RX от трансиверов. Частоты могут динамически меняться. Интерфейсы критичны к джиттеру и ppm.
найти то место, где можно перейти от этих 20 разных к одному общему, например, 200МГц. дальше всю обработку делать на нём.
если какой-нибудь STM или OTN, то однозначно - так и делается.
в STM переход производится сразу после обработки указателей H1H2. VC4 перекладывается в фифо, а вынимается на той частоте, на которой работает основной домен, занимающийся обработкой.
если какой-нибудь STM или OTN, то однозначно - так и делается.
в STM переход производится сразу после обработки указателей H1H2. VC4 перекладывается в фифо, а вынимается на той частоте, на которой работает основной домен, занимающийся обработкой.
Цитата(Denisnovel @ Aug 6 2015, 16:30)
В большом проекте получается порядка 20 тактовых домена. Предполагается работать с трафиком похожем на ethernet. По предыдущем проектам возникали проблемы при разводке кристалла из-за нехватки глобальных клоков. Есть 2 возможных выхода:
1) Оставить 20 клоков.
2) Сделать в каждом модуле вход разрешения и использовать один клок(чуть большей чем необходимо).
Как лучше поступить?
1) Оставить 20 клоков.
2) Сделать в каждом модуле вход разрешения и использовать один клок(чуть большей чем необходимо).
Как лучше поступить?
Я бы выбрал пункт 2.
PS Если хорошо подумать думаю можно уменьшить кол-во тактовых...
Цитата(Denisnovel @ Aug 7 2015, 08:59)
150-166 MHz. Да все TX RX от трансиверов. Частоты могут динамически меняться. Интерфейсы критичны к джиттеру и ppm.
Посмотрите, как это сделано в ПЛИС Акроникс. Там для каждого набора из 8 (кажется так) входных выводов под RX есть своя тактовая... Потом коммутатор тактовых... И еще аппаратные приемники со сдвигами битов...
Посмотрите, это, возможно поможет
чтобы не плодить тактовые частоты - программировал "на лету" DCM_CLKGEN (xilinx - Spartan 6 Clocking Resources User Guide for more info)
Код
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;
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)
№2 предпочтителен. К сожалению, в сложных проектах не всегда возможен. Пришел к необходимости замены ПЛИС с б0льшим числом глобальных тактов.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.