[Vadim_nsk 0]

В двух словах. Во-первых, это мой первый опыт с Zynq, во-вторых, не могу уловить суть работы с потоковой шиной AXI-Stream. Или не понимаю сообщений от тайминг-аналайзера.

Теперь подробней...

Перед собственно запуском АЦП, наслушавшись как в Zynq все быстро и удобно, посмотрев несколько видео, и почитав несколько статей, создал простой проект, где Microblaze для конфигурирования в будущем АЦП и ЦАП, а ARM уже для работы с данными. Есть общая память между Zynq и Microblaze, есть общая периферия. Частота работа с периферией 50 Мгц. Раньше делал со стороны ARM 100 МГц, сейчас сделал поменьше. Не уверен, что выходную частоту процессорного ядра можно использовать в FPGA безболезненно, поэтому пропустил на всякий случай клок через Clock-wizard.

Создал пару кастомных компонентов куда в дальнейшем перекочует работа с АЦП и ЦАП соответственно. И для проверки "скелета" все соединил и собрал. Сообщения про времянки уверяют меня, что ничего не работает. Пробовал вставлять регистры, вставил двухклоковую FIFO, опустил частоту работы с портом HP до смешных значений. Увеличил разрядность с 32 до 64 разрядов, завел два выхода в компоненте и использовал сразу два порта HP, помня рекомендацию Xilinx, что подключать нужно к портам через один, т.е. к 0 и 2 или к 1 и 3.

Можно услышать от опытных людей критику по структуре проекта в целом и рекомендации по констрейнам? Я так понял, что как и для спартан-6 констрейны нужно прописывать только ко входной частоте, а производные клоки просчитываются автоматически. Тут также?

Проект размещу по ссылке, т.к. его размер превышает ограничение в 5 Мб: EK-Z7-ZC702-G_Zynq_MB

Изменено 15 февраля, 2020 пользователем Vadim_nsk

[Vadim_nsk 0]

Общая структура проекта. Тут понатыкано всяких VIP клоков просто уже от безысходности, понимаю, что они работают лишь на этапе симуляции, но думал, может выдадут сообщение об ошибке. Но, нет.

Часть микроблейза:

Часть Zynq:

Смущающее меня сообщение:

Отчет тайминг-аналайзера:

И вот эти пути пугают больше всего:

И почему-то с добавлением регистров или FIFO в интерконнекторы или отдельных FIFO ситуацию не улучшают, а порой ухудшают. Кто как делает свои компоненты и сажает их на пор HP?

[RobFPGA 27]

Приветствую!

Тяжело пытаться заглотить  целого слона  Слишком много всего и сразу. А у вас слон да еще и с "моськой" Microblaze  

Попытайтесь "кушать" по кусочку  запуская систему  по блочно.  Временно отсекая второстепенные блоки и лепя пустышки имитаторы на их место. 

Ну и по структуре -  подумайте а реально ли нужна "моська"?  Ведь чем проще железо тем  легче запускать.  Ну а если все же нужна - то попытайтесь  выделить MB систему на отдельный BD  с минимум связей с BD Zynq  и опять же - запустить отдельно.  

Удачи! Rob.

 

[Dimidrol 0]

Здравый смысл подсказывает, что MB в этой системе лишний. 

[Vadim_nsk 0]

1 hour ago, Dimidrol said:

Здравый смысл подсказывает, что MB в этой системе лишний. 

Да тут как раз все просто. На ARM в дальнейшем будет поднят Linux. На отладочной плате ввиду дефицита свободных пинов реализован SPI до генераторов плат АЦП и ЦАП через мост IICtoSPI, да еще и сам IIC через разветвитель на отладочной плате сделан. На реальном железе потом все будет отдельно, но сейчас вот так монструозно. А программист ARM это программист высокого уровня и объяснять ему как настроить генератор для компенсации фаз в разных АЦП, есть там еще какой-то раздатчик клоков (сам еще не изучал что это за зверь), да еще и чтобы все это протолкнуть через 2-3 моста, а потом еще мне же и искать в обнимку с осциллографом, почему же не работает "железо" с написанным этим программистом драйвером. Тут я как раз в большей степени с вами согласен, поэтому отделил мух от котлет и откусил эту часть от ARM, поместив в MB. Но сохранил возможность доступа к этой периферии со стороны ARM. Хотя на данном этапе можно и удалить всю эту часть. Просто она особняком стоит, в сообщениях не фигурирует, а вся проблема как раз в связке АЦП -> AXI_FIFO -> AXI_DMA_ -> AXI_Interconnect -> Zynq_HP. Но если тяжело воспринимать это отдельно от остального, в понедельник откушу все лишнее и попробую снова, но думаю, проблема останется.

[Vadim_nsk 0]

11 hours ago, Vadim_nsk said:

Как и следовало ожидать...

а в тайминге ничего не изменилось.

Меня одного пугают времена в 24 нс?

У кого-то может есть рабочий "пустой" проект, который можно было бы посмотреть и взять за основу. Просто кастомный AXI-stream компонент прикрутить к порту HP Zynq. Если не ошибаюсь, без DMA и AXI_Interconnect он это не позволит сделать. Т.е. получится что-то вроде моего, только у меня 2 HP порта задействовано.

Изменено 16 февраля, 2020 пользователем Vadim_nsk

[gosha-z 2]

Предлагаю оттолкнуться от задачи, а не от предполагаемого ее решения. Структурную схему девайса можете изобразить?

[Vadim_nsk 0]

 

7 hours ago, gosha-z said:

Предлагаю оттолкнуться от задачи, а не от предполагаемого ее решения. Структурную схему девайса можете изобразить?

Необходимо к плате EK-Z7-ZC702-G  через разъем FMC подключить модуль АЦП SFM-4A250. Несовместимость разъемов FMC в данном случае можно считать задачей уже решенной.

Модуль АЦП SFM-4A250 содержит в своем составе два двухканальных АЦП ADS62P49 разрядностью 14 бит с рабочей частотой 250 МГц. Также в составе модуля имеется программируемый генератор и программируемый раздатчик тактового сигнала.

Но прежде чем бросаться на амбразуру и писать компонент захвата данных с шины АЦП, решил набросать часть схемы до Zynq. Компонент захвата данных АЦП оформил в виде кастомного, т.к. в дальнейшем туда потребуется дописать код, относящийся уже собственно к разрабатываемому прибору. Но пока достаточно и просто оцифровки данных с АЦП и их передачу в память DDR Zynq.

DMA в проект добавляется автоматически, я бы его не добавлял и формировал запись собственными средствами в нужную область памяти. Но при создании порта AXI_Full его не удается подключить к Zynq_HP, а при создании AXI_Stream и подключении его к Zynq_HP, он автоматом добавляет туда еще DMA и AXI_Interconnect. Ну, добавляет и добавляет. Вот только по частоте этот слоеный пирог не проходит... :-(

 

Упрощенный вариант

Изменено 17 февраля, 2020 пользователем Vadim_nsk

[des00 25]

10 hours ago, Vadim_nsk said:

Меня одного пугают времена в 24 нс?.

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

[Bad0512 2]

Мои 5 копеек в тему.

1. Микроблейз вам скорее всего не нужен. Если есть встроенный АРМ - зачем ещё плодить сущности?

2. АРМ можно легко запрограммить самому, тут (о боже!!!) можно обойтись без "программистов высокого уровня". Достаточно собрать под sdk (снейчас это называется Vitis) своё

небольшое bare metal приложение. Если ваша цель - доказать работоспособность железа, то этот путь очень даже подходит.

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

корок (с учетом диалектов протоколов под разные мелкие девайсы) вы угробите гораздо больше времени, чем на отладку bit bang драйвера. Ну то есть идея проста как валенок - заводите

все ноги от низкоскоростных протоколов на Zynq GPIO и дергаете ими как вам захочется.

4. Посчитатйте потоки данных с ваших АЦП/ЦАП и убедитесь, что производительности присоединенных AXI stream шин достаточно для вашей задачи. Если недостаточно - примите меры.

5. Ваше bare metal application может потом быть использовано для factory testing. В отличие от линуха, оно может спокойно уместиться во внутренней RAM и тестировать внешнюю DDR на предмет исправности.

[DASM 0]

Согласен по всем 5ти пунктам. А "высокого уровня" - в обводный канал с тазиком цемента :D

" вы угробите гораздо больше времени, чем на отладку bit bang драйвера" - тоже редко понимаю мольбы о помощи "помогите разобраться с регистрами i2c в проце таком-то" - а им этот и2с нужен блин один раз на 100 кГц сконфигурить какой-нить один чип. Даже читать его бывает не надо, только записать. И вместо 30-ти строк битбэнга начинаются бубны чуть не с ДМА - (без шуток, видел такое извращение - ради 15 байт).

[Vadim_nsk 0]

5 minutes ago, DASM said:

Согласен по всем 5ти пунктам. А "высокого уровня" - в обводный канал с тазиком цемента :D

" вы угробите гораздо больше времени, чем на отладку bit bang драйвера" - тоже редко понимаю мольбы о помощи "помогите разобраться с регистрами i2c в проце таком-то" - а им этот и2с нужен блин один раз на 100 кГц сконфигурить какой-нить один чип. Даже читать его бывает не надо, только записать. И вместо 30-ти строк битбэнга начинаются бубны чуть не с ДМА - (без шуток, видел такое извращение - ради 15 байт).

Я вас услышал, учел, выбросил MB, собрал систему без него, но ситуация осталась без изменения. Тайминг 16 нс, и я не могу его снизить до нормального уровня и не понимаю что для этого нужно сделать.

[gosha-z 2]

1. Если все соединения через FMC - выгоняете один SPI (у которого как раз три CS) и оба I2C контроллера в EMIO и никакие микроблейзы вам не нужны.

2. Подозреваю, что тайминг у вас разъехался из-за того, что Vivado увел IDDR блоки подальше от входных буферов, есть у него такая фишка при разводке на практически пустых кристаллах. Прибейте гвоздями входные IDDR рядом с входными пинами - станет значительно лучше.

3. Для всего софта у вас есть bare metal драйвера - все готовое и никакого шаманства с битбенгом.

[Bad0512 2]

46 minutes ago, Vadim_nsk said:

Я вас услышал, учел, выбросил MB, собрал систему без него, но ситуация осталась без изменения. Тайминг 16 нс, и я не могу его снизить до нормального уровня и не понимаю что для этого нужно сделать.

трудно гадать на кофейной гуще. Тайминг может расползтись по самым разным причинам. Приложите отчет по таймингу, хотя бы самые критичные цепи.

[Vadim_nsk 0]

13 minutes ago, Bad0512 said:

трудно гадать на кофейной гуще. Тайминг может расползтись по самым разным причинам. Приложите отчет по таймингу, хотя бы самые критичные цепи.

Помогите мне пожалуйста в этом немного. У меня есть файл: timing_1.rpx, но к сожалению я в нем не могу найти вот это: