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

[andrew_b]

DV, данные, клок приходят извне, т.е. в системе но от внешнего устройства, в test benchе я их сгенерировал согласно их ожидаемому таймингу (по specу того устройства). DV и дата по идее синхронизированы по входному клоку (в внешнем устройстве),

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

В первом случае это, к примеру,

Код

Clk <= not Clk after 10 ns;
Data <= not Data after 20 ns;

вроде бы всё нормально, но Clk и D асинхронны друг по отношению к другу. Что у вас и получается.

Второй случай -- это синхронная схема

Код

Clk <= not Clk after 10 ns;

process(Clk)
begin
   if (rising_edge(Clk)) then
      Data <= not Data;
   end if;
end process;

значит в реальности видимо будет задержка между фронтом соотв. клока и фронтом DV и первого данного. Я пока симулирую функционально (хотя и после route), посему этих задержек не видно (хотя можно наверно их проимитировать)...

Не можно, а нужно. Проще всего сдвинуть клок, чтобы изменение данных не совпадало по времени с изменением клока. Это будет асинхронщина, но результат у вас будет другой.

[Саша Z]

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

В первом случае это, к примеру,

Код

Clk <= not Clk after 10 ns;
Data <= not Data after 20 ns;

вроде бы всё нормально, но Clk и D асинхронны друг по отношению к другу. Что у вас и получается.

Второй случай -- это синхронная схема

Код

Clk <= not Clk after 10 ns;

process(Clk)
begin
   if (rising_edge(Clk)) then
      Data <= not Data;
   end if;
end process;

Не можно, а нужно. Проще всего сдвинуть клок, чтобы изменение данных не совпадало по времени с изменением клока. Это будет асинхронщина, но результат у вас будет другой.

ОК, спасибо.
Хмм, нужно ли синхронизировать входные контроли и данные (syncs + data) в коде по входному клоку перед процессингом как советует Михаил_К или в приципе достаточно довольстоваться тем фактом что они синхронизированны друг с другом во внешнем устройстве ? Мне кажется предложение Михаила логичным...
Будем думать как сдвинуть клок в test benchе (создать скажем 5-10 ns tpd входных сигналов относительно входного клока)...

[des00]

Будем думать как сдвинуть клок в test benchе (создать скажем 5-10 ns tpd входных сигналов относительно входного клока)...

Прекратите заниматься шаманством, описанным в большинстве книг начального уровня по ХДЛ языкам.

Привязывайте сигналы синхронных интерфейсов к клоку и можете, хотя для событийной модели ВХДЛ это не обязательно, задать задержку на интерфейсе.

делается это просто, положим что valid сигнал синхронного интерфейса.

Код

signal valid : std_logic;

..........

valid <= '0';
wait until rising_edge(clk);  -- initial sync

for i in 0 to 10 loop
  valid <= '1';
  wait until rising_edge(clk);
  valid <= '0';
end loop

в случае добавления задержек

Код

for i in 0 to 10 loop
  valid <= '1' after 1ns;
  wait until rising_edge(clk);
  valid <= '0' after 1ns;
end loop

Удачи!!

ЗЫ. Хотя на SV при использовании interface с clocking секцией все описывается намного красивее %)))

[Саша Z]

Прекратите заниматься шаманством, описанным в большинстве книг начального уровня по ХДЛ языкам.

Привязывайте сигналы синхронных интерфейсов к клоку и можете, хотя для событийной модели ВХДЛ это не обязательно, задать задержку на интерфейсе.

делается это просто, положим что valid сигнал синхронного интерфейса.

Код

signal valid : std_logic;

..........

valid <= '0';
wait until rising_edge(clk);  -- initial sync

for i in 0 to 10 loop
  valid <= '1';
  wait until rising_edge(clk);
  valid <= '0';
end loop

в случае добавления задержек

Код

for i in 0 to 10 loop
  valid <= '1' after 1ns;
  wait until rising_edge(clk);
  valid <= '0' after 1ns;
end loop

Удачи!!

ЗЫ. Хотя на SV при использовании interface с clocking секцией все описывается намного красивее %)))

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

Насчет привязки к клоку и задание имитации tpd как вы привели в примере - спасибо, это действительно мне кажется правильным подходом.

SV тут не причем, речь идет о конкретном случае, VHDL, то что возможно/невозможно в других языках, мирах, не релевантно

Обычно поток данных сопровождается не только передним фронтом клока но и интервалом, в которм передаются данные, или импульсом начала потока. Проблем быть не должно. Хотя желательно работать по одному фронту клока.
Наверно надо продумать интерфейс передачи.

Вы правы. В приведенных мной кусках симуляции (да и кусках кода) видно что есть сигнал DV (Data Valid) который и "вырезает" окно в котором идут данные. По фронту DV, синхронно с клоком ессно начинается первое данное потока.
Насчет фронта - если учитывать задержку tpd входных данных по фронту клока - то действительно наверно можно работать например только по фронту. Сейчас пытаюсь симулировать tpd на входных данных и сигналах относительно входного клока в test benchе, видно что в таком случае действительно достаточно работать только по одному edge клока.