Прояснить ситуацию, синхронная загрузка регистров по 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 по фронту клока начать загруску по спаду того-же клока...?

Спасибо

[Михаил_K]

Работа по фронту конечно желательно, согласен, но проблема в том что первый байт потока на входе согласован прямо по первому фронту клока по которому-же и синхронизирован DV, посему ежели брать дату по фронту - первая valid дата будет упускаться, но ежели по спаду - она должна по идее фиксироваться...

Выражайтесь более точно. DV и данные выходят с триггера, который работает по клоку? Или как?
Если так, как я говорю, то замечание Very_hard - правильное. Ничего упускаться не будет.

Честно гворя не понял у вас в коде как продвигается p

p - двигается циклично, и синхронизируется с первым значимым данным. Раз в три такта, когда на входе 3е данное, в старшем разряде p появляется 1, что и является признаком выдачи данных в параллельный регистр.

[Саша Z]

Выражайтесь более точно. DV и данные выходят с триггера, который работает по клоку? Или как?
Если так, как я говорю, то замечание Very_hard - правильное. Ничего упускаться не будет.
p - двигается циклично, и синхронизируется с первым значимым данным. Раз в три такта, когда на входе 3е данное, в старшем разряде p появляется 1, что и является признаком выдачи данных в параллельный регистр.

Насчет p - понял, спасибо. В моем случае - счетчик до 3х...делает в результате тоже-самое.
DV, данные, клок приходят извне, т.е. в системе но от внешнего устройства, в test benchе я их сгенерировал согласно их ожидаемому таймингу (по specу того устройства). DV и дата по идее синхронизированы по входному клоку (в внешнем устройстве), значит в реальности видимо будет задержка между фронтом соотв. клока и фронтом DV и первого данного. Я пока симулирую функционально (хотя и после route), посему этих задержек не видно (хотя можно наверно их проимитировать)...

Мне кажется, я начинаю догадываться...
Будьте добры, приведите код генерации dv и oled_video_in.

код DV (в test benchе):

Код

OLED_DV: PROCESS
    BEGIN
        DV <= '0';
        wait for start_time;
        for fdv in frames_to_simulate downto 1 loop
            for ldv in TV_tot_lines downto 1 loop
                if ldv > (TV_tot_lines - TVs)  or ldv <= (TV_tot_lines - TVd - TVs) then
                    DV <= '0';
                    wait for line_time;
                else
                    wait for HSYNC_time;
                    DV <= '1';
                    wait for DV_time;            --activate DV for 960 PCLKs
                    DV <= '0';
                    wait for (line_time - DV_time - HSYNC_time);        
                end if;
            end loop;
        end loop;
        wait;
    END PROCESS;

все параметры - нужные задержки для имитации циклов синхронизации DV в строках.

код данных:

Код

OLED_DATA: PROCESS
    BEGIN
        OLED_VIDEO_IN <= x"00";
        wait for start_time;
        OLED_VIDEO_IN <= x"00";
        wait for start_frame_blank_time;    --wait for first 7 blank lines
        for ldat in TVd downto 1 loop
            wait for HSYNC_time;            --wait for HSYNC pulse duration
            for clkdat in 960 downto 1 loop    
                OLED_VIDEO_IN <= x"FF";
                wait for Tclock;
                OLED_VIDEO_IN <= x"00";
                wait for Tclock;
            end loop;
        end loop;
    END PROCESS;

опять-же все константы задержек нужны для синхронизации видео sync сигналов и т.д.

[Михаил_K]

Насчет p - понял, спасибо. В моем случае - счетчик до 3х...делает в результате тоже-самое.
DV, данные, клок приходят извне, т.е. в системе но от внешнего устройства, в test benchе я их сгенерировал согласно их ожидаемому таймингу (по specу того устройства). DV и дата по идее синхронизированы по входному клоку (в внешнем устройстве), значит в реальности видимо будет задержка между фронтом соотв. клока и фронтом DV и первого данного. Я пока симулирую функционально (хотя и после route), посему этих задержек не видно (хотя можно наверно их проимитировать)...

опять-же все константы задержек нужны для синхронизации видео sync сигналов и т.д.

ИМХО если данные приходят из вне вместе с клоком, то в первую очередь их нужно принять на входной триггер, тактируемый этим клоком. И сигнал DV также. После этого все становится нормально.

Сообщение отредактировал Михаил_K - Mar 17 2008, 13:03

[Саша Z]

ИМХО если данные приходят из вне вместе с клоком, то в первую очередь их нужно принять на входной триггер, тактируемый этим клоком. И сигнал DV также. После этого все становится нормально.

Т.е. засинхронизировать входные сигналы по входному клоку внутри ?