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;

[VladimirB]

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

АЦП ADS6145...

ПЛИС и инструментарий не указан - ХЗ чем вы там синтезите,

но по своему опыту скажу: с такими аппаратными фичами Xilinx как DDR, SERDES, PLL, IODELAY и др. лучше ИМХО
обращаться путём наглого вставления примитивов в HDL, иначе ISE будет тупить очень сильно (он конечно тупит и с примитивами - но значительно меньше). Дифференциальные буферы не поленились вставить в ввиде примитивов - вот и IDDR нужно также.

Там у IDDR, есть помниться несколько режимов работы, задающихся генериками. А что вам тут ваш синтезатор сделал из вашего кода ХЗ? И вставил ли он вообще IDDR? И если вставил, то с какими настройками?

И ещё режет глаз:
generic( DIFF_TERM : boolean := FALSE);
это так и задумано? место на плате много и снаружи не поленились резюки по 100Ом запаять?

P.S. и ещё не ясно, что с клоком из АЦП - на какой тип ноги он заведен (GCLK, MRCC, SRCC или CLOCK_DEDICATED_ROUTE = false) ?
P.S.2 констреинты есть какие-нибудь?

[doom13]

Дифференциальные буферы не поленились вставить в ввиде примитивов - вот и IDDR нужно также.

Вот тут, похоже, правда, а то из Вашего процесса какая-то ерунда должна синтезироваться, а не DDR-буфер.

[druzhin]

У меня есть рабочие проекты на Spartan-6 по приёму данных с АЦП LTC2157.

Есть даже в двух экземплярах - и на SERDES, и на IDDR.

[Ar-han]

У меня есть рабочие проекты на Spartan-6 по приёму данных с АЦП LTC2157.

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

Да, и расскажите, как Вы считываете свои данные с памяти, а то что-то дружно тут много всего наговорили.

В моём варианте двухпортовая память в один порт ацп пишет
по два значения (14бит) в один регистр (32бит), а
вторым портом она на PLB шине (пока что микроблейза):

#define XPAR_XPS_SHARED_BRAM_IF_CNTLR_BASEADDR 0xA0000000


Указатель на эту память:
#define pData ((char*)0xA0000000)

копирую:
memcpy(pbuf_to_be_sent->payload,pData,STR_SIZE);

отправляю:
err = udp_send(pcb, pbuf_to_be_sent);

Хочу научиться понимать и работать со всеми вариантами обмена данными,
но пока иду от простого к сложному.
Не пинайте сильно, не всегда с новыми понятиями легко разобраться, такими как DMA.

Периодически, даю команду читать ацп и писать в память до заполнения,
складывая два значения в один регистр.
Дергаю ногу прерывания микроблейза флагом, что память заполнена,
по этому прерыванию пытаюсь читать данные и отправлять пакет.

Пока что заткнулся на прерывании микроблейза. Упорно не хочет работать, хотя раньше с ним проблем не было. (Может я импульс короткий даю на прерывание? он порядка 100 ns)

До этого, писал в эту память 4 мкс сигнала, ждал 200 ms и снова писал,
а проц выгребал оттуда 10 раз в секунду данные со своей, уж не знаю какой скоростью, и посылал пакеты.
В таком варианте сигнал приходил порезанный на несколько кусков в разных фазах.
При этом, если снизить частоту тактирования АЦП раз в 10, то сигнал приходил
без искажений.

Я пока только учусь, хочу попробовать как не правильно делать и как правильно.
Всем большое спасибо за поддержку.

[doom13]

Откуда тогда дискуссия про GPIO и вычитку с его помощью данных Так и нужно - память как бы внешняя получается.

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

[Ar-han]

в варианте с двумя буферами памяти, которые переключаются поочереди чтение и запись независимы. Записывающая и вычитывающая стороны работают самостоятельно никак не оказывая влияния друг на друга.

Правильно ли я понимаю, что память с двумя буферами, это две одинаковые корки BRAM, с разными адресами, на одной шине (PLB) ?
Кстати, интересно, можно ли двухпортовую BRAM повесить на LMB шину? У меня, вроде бы, получалось, но были проблемы, и не удалось её корректно использовать.

С приёмом данных сначала разберитесь, потом будете искать более оптимальные пути.

Приём данных, кажется, удалось победить.

Теперь вопрос по флагам, флаг процессору - по внешнему прерыванию. Ок. Это сделал. Измеренная wireshark -ом скорость получилась 2940 пакетов в сек по 1 кБайту.
Теперь как мне передать от процессора флаг, что память прочитана? Первое, что приходит в голову - это GPIO, но подозреваю, что это не оптимально.
Сейчас использую microblaze на частоте 100 Мгц, интересно, что даст повышение частоты?
Хочу перейти на powerPC, только не соображу как на PowerPC запустить UDP пакеты. Под PowerPC тестовое приложение с эхо сервером организовано через TCP протокол.
Насколько я понял, если сделать большие UDP пакеты, то lwip сама их разрежет, и отошлет кусками.
Но кажется, UDP не поддерживает нумерацию пакетов, значит, рассчитывать, что они склеятся на стороны компа не приходится. Значит самому нужно их резать кусками, нумеровать, и склеивать на компе?

У вас прописаны констрайны, за сколько данные до фронта клока должны стоять и сколько после? Это весьма полезные констрайны!

Нет, не прописаны, буду рад подсказке, с констрейнами еще не успел разобраться.
Если, можно, ткните где почитать про констрейны.
Правильно ли я понимаю, что констрейны пишутся руками в UCF файле, рядом с распиновкой ног?
Где-то я слышал, что они удобно прописываются в PlanAhead, только с ходу не нашел.

У меня есть пример констрейна для входного сигнала:

Код

NET "CLOCK_110" TNM_NET = CLOCK_110;
TIMESPEC TS_CLOCK_110 = PERIOD "CLOCK_110" 110 MHz HIGH 50% INPUT_JITTER 100 ps;
OFFSET = IN 9.09091 ns VALID 9.09091 ns BEFORE "CLOCK_110" RISING;

Можно ли таким же образом указать ограничения на тактовый сигнал, который рождается после диф. приёмников - USER_CLK?
Из каких соображений выбирается JITTER ?

Код

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

   IBUFDS_6 : IBUFDS
      port map (I=>HDR2_64_SM_9_P,
                IB=>HDR2_62_SM_9_N,
                O=>DDR_6);
  
   IDDR_6 : IDDR    
      port map (C=>USER_CLK,
                CE=>VPP,
                D=>DDR_6,    
                R=>GRND,
                S=>GRND,
                Q1=>out12,
                Q2=>out13);

Спасибо!

Ура, всё заработало! Нашел еще одну дурацкую ошибку, пихал данные в память по совершенно другой частоте, не по той, на которой они защелкивались в диф. приемниках.

Только не понятно, откуда брался шум при отсутствии входного сигнала.

Сообщение отредактировал Ar-han - Jul 9 2014, 05:45

[doom13]

Только не понятно, откуда брался шум при отсутствии входного сигнала.

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

Брать 2 корки памяти, городить к их шине мультиплексор, да еще поддерживающий на одном из концов PLB или AXI шину, городить модуль переключения мультиплексора, ответный сигнал запрета записи в память.

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

Мне одному кажется это мраком?

Вы так и не разобрались в предложенном варианте, просмотрите, что советовалось, ещё раз и это не будет мраком. Нормальный вариант решения поставленной задачи, единственный недостаток - двойной объём памяти для хранения текущего и предыдущего пакета, но для FIFO, думаю получится примерно также (если делать, чтоб ничего не переполнялось и не перезатиралось).

Взяли FIFO, с одного конца АЦП пихает данные, с другого процессор их забирает. Нет никакой надобности следить заполнен первый буфер или второй, запрещать переключения и прочее... Появились данные на выходе, вычитали их и отправили. Пошли свои дела делать, вернулись опять поглядели, есть данные? считали и отправили. Все! Внутри FIFO будут те же блоки BRAM + весьма эффективная обвязка

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

UDP - если вы бирете большой пакет, больше чем лезет через сеть, стэк его порежет и отправить, на другом конце стэк его склеит и вернет. Пакет UDP придет либо целиком, либо не придет вообще. Отсутствие нумерации относится к тому что если вы пошлете 2 пакета UDP никто не знает как они придут и никто не гарантирует что они придут в той же последовательности как вы их отправляли, могут поменяться местами. Более того нет гарантии что один пакет не придет 2 раза (если потеряется что-то в обмене и отправляющий узел продублирует пакет).

Писал уже, если передача данных происходит не между континентами, то всё будет нормально с UDP даже при отправке фрагментированных IP-пакетов, никаких потерь и путаницы пакетов и фрагментов пакета не будет.

То есть другими словами если вы хотите слать байтовый поток через UDP - вы обламаетесь, данные должны быть промаркированы внутри, иметь заголовки и прочую фигню. Если же хотите поток с гарантией отсутствия повторений и потерь, то это ТСР.

Не обломаетесь, всё будет работать. Под передачу данных от АЦП (более-менее скоростных) использовать TCP никто не будет.
Из собственного опыта - используется UDP, поток данных 655.36 Mbit/s, длина данных в UDP-пакете 32 kB, это всё отправляется с использованием фрагментации IP по 1024 байта в каждом фрагменте. Всё нормально работает без всяких потерь, есть проблемы с приёмом под Windows, но комп с Linux всё нормально принимает и обрабатывает.

Да, кстати, при реализации, для сбора данных с АЦП использовалась именно память с двойной буферизацией.