Прояснить ситуацию, синхронная загрузка регистров по enable Опции

[Саша Z]

Вопрос в следующем:
есть код который конвертирует последовательность из 8-битного серийного потока (т.е. байтный поток, один байт за другим) в параллельные слова каждые 3 последовательных байта.
Т.е. первые 2 байта загружаются в промеж. регистры, затем по третьему байту - все 3 считываются параллельно на выходе в соотв. раскладе.
В принципе, все работает в симуляции как надо, но начало работы конвертора динхронизировано с определенным сигналом. Фронт данного enable синхронизирован с фронтом первого релевантного клока.
Первый байт данных в потоке синхронизирован тоже по фронту того-же клока, т.е. должен загружаться в первый промеж. регистр по спаду первого клока.
Т.е. по фронту первого клока получаем enable, по его спаду должны загрузить первое данное в регистр.
Далее все продолжается синхронно, по каждому спаду идет загрузка в цепочку из 2х регистров, по каждому 3ему спаду - считывает параллельное данное.
Проблема в следующем: при симуляции вижу получив enable на первом клоке (по его фронту), загрузка не начинается по спаду того-же клока, а только по спаду следующего (второго) клока, т.е. пропускается первый байт потока. Пока не пойму почему. Клок достаточно медленный (примерно 20-25 MHz), 50% duty cycle, симуляция: post-route functional.
Вот релевантный кусок кода:

Код

process(nRST, IN_CLK, DV)        --Input FIFO - buffering input RGB sequence
     begin
      if nRST = RST_pol or DV = not DV_active then
         r0 <= x"00";
         r1 <= x"00";
         RGB_OUT <= x"0000";
      elsif IN_CLK'event and IN_CLK = '0' then    --FIFO is chain-loaded upon falling edge
         r0 <= RGB_IN;                                  --G sample (8 bits), 6 MSB bits will be picked
         r1 <= r0;                                  --R sample (8 bits), 5 MSB bits will be picked
         if out_load_en = '1' then             --loading the output RGB buffer (parallel RGB)
                 RGB_OUT <= r1(7 downto 3) & r0(7 downto 2) & RGB_IN(7 downto 3);
             end if;
      end if;
end process;

Пока не пойму что мешает по получении enable по фронту клока начать загруску по спаду того-же клока...?

Спасибо

[dvladim]

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

На мой взгляд ключевое непонимание HDL.
В список чувствительности процесса заносятся только асинхронные сигналы - сигналы, при изменении которых изменяется выход элемента.
Для комбинационных схем - все входные сигналы.
Для регистра - асинхронные (клок, асинхронный сброс). Остальные (такие как: синхронный сброс, энэйбл, сигналы влияющие на вход триггера и т.п.) в список чувствительности не вносятся.

Шаманство не причем, не обязательно сразу принимать в штыки даже вопросы начального уровня , конкретно насчет попытки задержки клока - я не читал об этом в книгах, так-что их обвинять не могу, это моя додумка, видимо не самая удачная ввиду малого опыта. На свою настольную книгу (VHDL for logic synthesis by Andrew Rushton) жаловаться не могу, из нее почерпнул очень многое...

Задерживается не клок, а данные и другие сигналы.
Триггер ведь не работает мгновенно.

[Саша Z]

На мой взгляд ключевое непонимание HDL.
В список чувствительности процесса заносятся только асинхронные сигналы - сигналы, при изменении которых изменяется выход элемента.
Для комбинационных схем - все входные сигналы.
Для регистра - асинхронные (клок, асинхронный сброс). Остальные (такие как: синхронный сброс, энэйбл, сигналы влияющие на вход триггера и т.п.) в список чувствительности не вносятся.
Задерживается не клок, а данные и другие сигналы.
Триггер ведь не работает мгновенно.

Да понятно все это, в синхронных процессах в основном так и получалось что кроме клока все остальные сигналы по которым происходили events - были асинхронные.

То что задержка идет на сигналах по выходу относительно клока - тоже спору нет, тут все очевидно. Говорилось о другом аспекте - о том как искуственно приимитировать задержку сигналов в test benchе, т.е. имитация входного тайминга. Было предложение задержать входной клок, но все-таки ессно правельней дать задержки на сигналы относительно клока.