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



Аналогично и при использовании RAM, мы сами определяем размер необходимй выборки, всё, что хранится в памяти и есть наша выборка. Сигнал синхронизации сигнализирует, когда буферы чтения/записи меняются местами, когда процессор может начинать вычитывать новые данные. Процессорное время тут также не задействуется. Реализовывалось всё это на Cyclone V и вычитку памяти осуществлял Sg-DMA (думаю, что-то похожее найдётся и у Xilinx), который и запихивал все данные в железный упаковщик UDP. По прерыванию происходит только обновление дескриптора для Sg-DMA, далее процессор выполняет какие-то свои задачи, всю работу по пересылке данных выполняет Sg-DMA.


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



Поделитесь тогда примером, чтоб человеку было от чего оттолкнуться.

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




В моём варианте двухпортовая память в один порт ацп пишет
по два значения (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, то сигнал приходил
без искажений.

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

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

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

64-битная шина GPIO была в самом начале, от неё перешёл на двухпортовую BRAM, повешанную на PLB шину.
Как мне лучше флаг заполнения памяти передать процессору? Сейчас его завожу на ногу внешнего прерывания. А как правильно? Тоже через корку какую делать обмен флагами?

Разделил по времени запись и чтение в двухпортовую память. Теперь сигнал не режется на куски, но какие-то ошибки возникают, снова запутался, порядок ног уже 5 раз проверил.
Пила на входе вместо диф. приемников рисуется правильно.

синус на входе


без сигнала с замкнутым входом


Может быть какие-то временные ограничения нужно указать сигналу, по которому защелкиваю данные в диф. приемниках?
Защелкиваю данные по сигналу clk_out с АЦП. Может нужно подвигать фазу защелкивания DCM блоком, или указать допустимый джиттер на этот сигнал (USER_CLK) ?
У меня сейчас так:


Сообщение отредактировал Ar-han - Jul 7 2014, 14:40

А что там с режимом SDR CMOS, можете джампер перебросить, чтобы включить его?
По второму рисунку видно, что данные от АЦП приёмник принимает неправильно, шуметь должно несколько разрядов АЦП относительно среднего значения 8192. Путаница с порядком следования бит у Вас осталась.

Это говорит о том, что запись данных в память и их вычитка из памяти работают нормально. Эту часть можно пока оставить.

Тут может влиять не только порядок ног (Вы его уже много раз проверяли), но и выровнены ли линии, какая фаза у клока относительно данных, она может отличаться для разных линий. Т.е. тут решением может быть либо переключение в SDR CMOS режим, где каждая линия будет соответствовать одному биту, либо реализовать SPI и сего помощью управлять АЦП, задать на выход тестовую последовательность 10...10 и тогда можно будет увидеть, какие именно биты перепутаны.


Временные ограничения прописать стоит, но основная проблема у Вас не в этом. Подвигать фазу PLL скорее всего не получится, если не ошибаюсь, то клок был заведён на неправильную ногу. Но даже если получится, где гарантия, что поправив для одной линии не испортите для другой.
Варианта дальнейших действий для успешного решения проблемы два:
1) Включить режим SDR CMOS.
2) Завести SPI, выдать тестовую последовательность, увидеть причину неправильного приёма данных.

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

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

Да, но для каждой линии может быть своя задержка, подбирать каждую, не зная правильно ли подобраны все остальные (только по результату можем определить), будет сложновато.



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

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

На входе синус, 2 МГц.

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



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

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



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

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


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



Спасибо!


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

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

Да, две одинаковые, но и адреса у них одинаковые, их выходы подключаются к шине поочереди мультиплексором (выше пример кода приводил). Со стороны процессора это как бы одна память. Интервал времени, когда одна собирает данные, вторая - "отдаёт" предыдущую выборку процессору. Ваша задача только синхронизацию сформировать (выше описывал).



Ну да, всё оказалось намного проще, чем я полагал.



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

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

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

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

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

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






трудности с разводкой и очевидно прирост производительности. Доступ микроблайза к данным AXI шины далеко не 1 такт. А доступ к акси-лайт ваще блокирующий. Так что обмен данными по шине - самый тормозящий момент работы микроблайза.

Да, так и есть, если UDP пакет большой (больше порядка 1500 байт), то LwIP пошлёт его за несколько IP-фрагментов, wireshark-ом Вы увидите эти фрагменты, если написать приёмник в любой среде, то там всё склеится автоматом, указываете только длинну данных, которую передаёте. Правда, для LwIP чтоб заработала фрагментация мне пришлось добавить задержку в цикле, где и происходит разделение на фрагменты, без неё как-то криво работало, часть фрагментов терялось. Пример того, что нужно для отправки UDP:

ну вот и правильный констраин



это говорит что фронты сигнала идут на частоте 110 МГц, 50% скважности и плавают на 100 пикосекунд. Откуда эти параметры? Не знаю, наверное какие то справочные данные. Главное что после разводки схема проверит все ли данные будут успевать вставать к фронтам (которые могут плавать на 100 пикосек).

и дополнительно проверит

что за 9.09 наносек до восходящего фронта данные на входах будут готовы, и будут неизменны еще 9.09 наносек...

есть такой же OFFSET = OUT для выходных ножек.

Так же кроме BEFORE есть AFTER.

про констраины надо читать UG625 (не знаю может есть уже более свежие)


Смысл в том что вы должны по мануалу вашего АЦП описать когда у вас будут появляться данные на входных ножка относительно сигнала клок. И тогда разводя сигнал внутри ПЛИС синтезатор будет учитывать задержки распространения и понимать все ли данные верно доходят к моменту защелкивания или нет (пути то у всех разные), а также проверять хватает ли времени между фронтами.

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



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

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

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



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


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

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

У меня нет времени и желания разбираться в предложенном варианте по 2 причинам
1. Вариант понятен и прост, сделать его тяп ляп просто, сделать его правильно с защитой и диагностикой сложно
2. Я не вижу преимуществ этого вариант перед вариантом с FIFO, ни в реализации ни в использовании.

Также я хочу заметить что подход

Весьма детский и непрофессиональный
Утверждения вида

Допустимы только на студенческих курсовых да и то претендующих на зачет не более...

Есть стандарт, в стандарте указано что гарантий нет, значит их нет! Если вы в одних идеальных условиях что-то проверили, и сегодня оно работает - это не дает вам права делать такие утверждения! Откуда вы знаете какие и где будут условия? По передавайте через вайфай на границе сигнала. Понаделают таких поделок, а потом у нас ракеты падают, говорят саботаж... Да я согласен - такой подход САБОТАЖ!

Простите, наболело... это на самом деле 0 и главная причина почему я не хочу разбираться в вашем варианте...