LVDS DDR данные из АЦП в ПЛИС Опции

[Ar-han]

Что не так делаю?
Почему вместо синуса вижу корявый меандр?
Не реагирует на изменение амплитуды сигнала.
С какой стороны младшие биты? (c D0 или с D6)
Тактирую ПЛИС по CLK_OUT от АЦП

АЦП ADS6145
http://www.ti.com/lit/ds/symlink/ads6145.pdf
Спасибо.

Код

   component IBUFGDS
  --    -- synopsys translate_off
      generic( DIFF_TERM : boolean :=  FALSE);
  --    -- synopsys translate_on
      port ( I  : in    std_logic;
             IB : in    std_logic;
             O  : out   std_logic);
   end component;
   attribute IOSTANDARD of IBUFGDS : component is "DEFAULT";
   attribute DIFF_TERM of IBUFGDS : component is "FALSE";
   attribute BOX_TYPE of IBUFGDS : component is "BLACK_BOX";
  
   component IBUFDS
      -- synopsys translate_off
      generic( DIFF_TERM : boolean :=  FALSE);
      -- synopsys translate_on
      port ( I  : in    std_logic;
             IB : in    std_logic;
             O  : out   std_logic);
   end component;
   attribute IOSTANDARD of IBUFDS : component is "DEFAULT";
   attribute DIFF_TERM of IBUFDS : component is "FALSE";
   attribute BOX_TYPE of IBUFDS : component is "BLACK_BOX";


begin

data_out <= out13 & out12 & out11 & out10 & out9 & out8 & out7 & out6 & out5 &
                out4 & out3 & out2 & out1 & out0 ;

clk_out <= USER_CLK;


   IBUFGDS_1 : IBUFGDS
      port map (I=>SMA_DIFF_CLK_IN_P,
                IB=>SMA_DIFF_CLK_IN_N,
                O=>USER_CLK);


   IBUFDS_1 : IBUFDS
      port map (I=>HDR2_28_SM_11_P,
                IB=>HDR2_26_SM_11_N,
                O=>DDR_1);
  
  
   IBUFDS_2 : IBUFDS
      port map (I=>HDR2_32_DIFF_3_P,
                IB=>HDR2_30_DIFF_3_N,
                O=>DDR_2);
....

process(USER_CLK)
begin

        if (USER_CLK = '1') then
      
        out0 <= DDR_0;
        out2 <= DDR_1;
        out4 <= DDR_2;
        out6 <= DDR_3;
        out8 <= DDR_4;
        out10<= DDR_5;
        out12<= DDR_6;
        

        elsif (USER_CLK = '0') then
        
        out1 <= DDR_0;
        out3 <= DDR_1;
        out5 <= DDR_2;
        out7 <= DDR_3;
        out9 <= DDR_4;
        out11 <= DDR_5;
        out13 <= DDR_6;

        end if;

end process;

[Golikov A.]

FIFO
1. Размер отправляемого пакета - любой задается через порог фифо не пусто. В любой момент можно изменить, даже на лету.
2. Число буферизуемых пакетов без потерь - ограничен только объемом памяти, число пакетов меняется на лету с их размером
3. Потери памяти (используемая физически, но не используемая для хранения данных) 0. Все пакеты лежат друг за другом байт в байт, выравнивания не требуется
4. Адрес чтения данных - один
5. Автомат управления адресом чтения - отсутствует

Вариант с 2 буферами
1. Размер отправляемого пакета - минимум ограничен заполняемостью буфера, если поставите 1 байт то оба буфера будут забиты. Второе ограничение ширина шины адреса, она определяет максимальную длину пакета
2. Число буферизуемых пакетов без потерь - 1. Чтобы их стало больше необходимо ставить еще блоки памяти. Усложнять мультиплексор выбор блока. На лету изменить с изменением размера пакета невозможно.
3. На каждый буфер вы используете один брам 18К, весь хвост 18К - размер пакета у вас не используется.
4. Адрес чтения пакета сменный, и зависит от размера пакета, с изменением размера пакета необходимо менять диапазон адресов
5. Необходим автомат управления адресом при чтении очередью, либо программные циклы с инкрементом

Достаточно или есть еще вопросы почему FIFO однозначно лучше? 2 буфера - решение для простоты, но если есть готовое FIFO надо брать его и использовать.

В чем собственно непрофессионализм - в использовании Linux

Нет, непрофессионализм - это на основе своего частного мнения и конечного числа экспериментов выдвигать нарушающие стандарт утверждения.

Это допустимо даже в очень нестуденческих проектах.

В очень не студенческих, но крайне плохих проектах. Проблема не в использовании UDP, проблема в неправильном его использовании. Кто мешает в UDP пакет вместе с данными положить заголовок с определяющий положение данных? Нет необходимости крутить тяжелый ТСР, но считать что UDP пакеты всегда будут идти друг за другом и никогда не потеряются - преступно!


Потому можете сколько угодно трясти готовыми проектами которые так работают. Я не изменю своего мнения. Проект построенный на таких допущениях - барахло!