Выложили и возможно более простое/"чистое" решение с счетчиком то 3 (2 DFFа) и еще один DFF.
Оказалось весьма просто и легко реализуемо кодом.

Все эти выложенные схемы конечно работают. Но толку от них мало.
Опмсание на вентильном уровне. Gate клоки. И все равно присутсвует понятие удвоенной частоты.
Поттому что работает на обих фронтах клока.
Вам же не делительнужен. Вам данные надо этим Вашим gate клоком сопровождать. И что?
Передний фронт этого gate клока попадет в "центр" данных?
Ведь чего проще. На таких частотах. Иметь свой кварцованный генератор. Перевести данные в э
тот домен и в разах этого своего клока поведенчески лепить что угодно: и данные и выходной клок.
причем на выходе будет только регистровая структура.

sazh, хммм... а ведь данные можно хватать по обоим фронтам без деления частоты клока, а потом уже отсортировывать нужные. Оверсемплинг своего рода с избыточными и абсолютно не нужными данными, зато никаких проблем с расхождением клока и данных во времени.
Сделать два FIFO - с защёлкой по положительному и отрицательному фронтам, а на выходе "подбирать" только данные, защёлкнутые на втрое меньшей частоте.

Кому нужны в стандартном случае работа по обоим фронтам. Тем более, что клок сформированный pll не даст такой возможности. Да и не надо.
Все те схемы, которые приведены были это порождение работы в графических редакторах, оперируя готовыми примитивами. Не задумываясь при этом о структуре кристалла.
Что касается FiFo Зачем двуклоковое. когда можно обойтись одноклоковым. Это ресурсы и латентность.
Поведенческое языковое описание, параметризуемость легко ложиться на одноклоковое описание.
Зачем огород городить.

library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;

entity RGB_a is
port (
DATA_FIFO_OUT : in std_logic_vector(7 downto 0);
CLK_x2 : in std_logic;
nRST : in std_logic;
clk_out : out std_logic;
DATA_OUT : out std_logic_vector(23 downto 0)
);
end RGB_a;

architecture RGB_arch of RGB_a is

signal cnt : std_logic_vector(2 downto 0);
signal temp : std_logic;
signal rg_a, rg_b : std_logic_vector(7 downto 0);

begin
process(CLK_x2)
begin
if CLK_x2'event and CLK_x2 = '1' then
if nRST = '0' then cnt <= (others => '0');
elsif cnt = "101" then cnt <= (others => '0');
else cnt <= cnt + 1;
end if;
if cnt = "001" then rg_a <= DATA_FIFO_OUT;
end if;
if cnt = "011" then rg_b <= DATA_FIFO_OUT;
end if;
if cnt = "101" then DATA_OUT <= DATA_FIFO_OUT & rg_b & rg_a;
end if;
if nRST = '0' then temp <= '1';
elsif cnt = "010" then temp <= '1';
elsif cnt = "101" then temp <= '0';
end if;
end if;
end process;

clk_out <= temp;

end RGB_arch;

Честно говоря не понял.
Данные приходя со своим клоком, не вижу серьезного резона добавлять в систему еще один кварц. Подгонка фронтов выходного (деленного на 3) клока под выходные данные - очень проста. На выходе и так регистровая структура (и данных и выходной клок). Честно говоря не вижу проблемы и надобности системно осложнять.

Либо я не понял в точности вас.

Я просто привел альтернативный пример делителя на 3. (Я же не вкурсе Вашего TЗ)
И тему вроде бы закрыли.
Насчет простой подгонки - можно поспорить.
Попробуйте полученный клок простробировать входным клоком. неужели тоже самое получите?

Прочитал ваш код - теперь понятен ход ваших мыслей. Вполне тоже может быть вариантом, может быть хотя-бы ради интереса я его тоже прогоню в коде/симуляторе, кстати, не уверен получается ли в вашем варинате 50% duty cycle. Будет неплохой вариант и для самообучения...