AXI DataMover (S2MM) сразу после сброса готов принять 4 слова данных из стрима, хотя никакой команды на это ещё не было, как я понимаю, он сразу после сброса не должен держать Ready в 1 Опции

[Krys]

Здравствуйте. Такая вот проблема. AXI DataMover (S2MM) сразу после сброса готов принять 4 слова данных из стрима, хотя никакой команды на это ещё не было, как я понимаю, он сразу после сброса не должен держать Ready в 1, пока не поступит команда.
Вот осциллограммы из ChipScope Analyzer:


Так выглядит описание в файле *.mhs:

CODE

BEGIN axi_datamover
PARAMETER INSTANCE = axi_datamover_y
PARAMETER HW_VER = 4.02.a
PARAMETER C_INCLUDE_MM2S = 0
PARAMETER C_INCLUDE_S2MM = 1
PARAMETER C_INCLUDE_S2MM_DRE = 0
PARAMETER C_S2MM_BTT_USED = 23
PARAMETER C_S2MM_INCLUDE_SF = 0
PARAMETER C_S2MM_BURST_SIZE = 256
PARAMETER C_INCLUDE_S2MM_STSFIFO = 1
PARAMETER C_S2MM_STSCMD_FIFO_DEPTH = 1
PARAMETER C_S2MM_STSCMD_IS_ASYNC = 1
PARAMETER C_M_AXI_S2MM_ID_WIDTH = 3
PARAMETER C_S2MM_ADDR_PIPE_DEPTH = 4
BUS_INTERFACE M_AXI_S2MM = axi4_0
BUS_INTERFACE S_AXIS_S2MM_CMD = axi_dma_ctrl_y_M_AXIS_CMD
BUS_INTERFACE M_AXIS_S2MM_STS = axi_datamover_y_M_AXIS_S2MM_STS
BUS_INTERFACE S_AXIS_S2MM = axi_stream_fft_core_0_Y_AXIS
PORT m_axi_s2mm_aclk = clk_75_0000MHzPLL0
PORT m_axis_s2mm_cmdsts_aresetn = DIP_Switches_4Bits_TRI_I[0]
PORT m_axi_s2mm_aresetn = DIP_Switches_4Bits_TRI_I[0]
PORT m_axis_s2mm_cmdsts_awclk = axi_dma_ctrl_y_axis_aclk_0

END

Я использовал плату SP-605 со SPARTAN-6. Софт - ISE 14.7 (Planahead + XPS).

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

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

[Alexey_Rostov]

просмотрел форум xilinx, ваш пост и сопутствующие посты. Обнаружил следующее

The product guide (PG022) for axi_datamover_v4_02_a incorrectly defines bit 23 in Table 3-2 and Table 3-5 as Type and describes as RSVD. The correct description of the bit is as follows:

Bit 23, when set to 1, enables incremental AXI4 transactions. When it is set to 0, it allows Keyhole (FIXED address AXI4) transactions.

The behavior of this bit has changed from v3.00a to v4.02a..This issue will be fixed in 2013.1 documentation.

у меня этот бит всегда ноль. В этом случае инкрементации не происходит, может поэтому после записи одного 32 разрядного слова датамувер переключает реади в ноль?
завтра обязательно проверю

[Krys]

у меня этот бит всегда ноль. В этом случае инкрементации не происходит, может поэтому после записи одного 32 разрядного слова датамувер переключает реади в ноль?
завтра обязательно проверю

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


Совет: длинные исходники нужно прятать под теги codebox (хотя их и нет в стандартном наборе инструментов), модераторы мне обращали на это внимание.
Посмотрел этот файл *.mhs, там у Вашего датамувера фифо команд 4 слова. Теоретически статус интерфейс наверное может в таком случае быть не подключенным. Сейчас посмотрел свой файл, у меня фифо команд 1 слово, т.е. его фактически нет. Попробуйте так. Может, доходить команды будут до датамувера, а не застаиваться в фифо. Только интерфейс статуса надо обязательно подключить, дать реади ему.

результаты функционального моделирования в modelsim
на рисунке виден реади на 4 такта

Да, тут ничего необычного, всё в рамках уже полученных объяснений от Xilinx. Единственное, что на первой осциллограмме у Вас обе тактовых имеют одинаковую частоту, а на следующей уже разную. Это говорит о том, что Вы проводили эксперименты при разных условиях, а это неправильно (хотя в данном случае вряд ли в этом причина).

почему сигнал реади (s_axi_s2mm_tready) при появлении сигнала данных (s_axi_s2mm_tvalid) принимает нулевое значение????
То есть при наличии данных и изменении содержимого cmd регистра датамувер пишет после нескольких тактов s_axi_s2mm_tvalid что не готов их принять???

Ну а что тут такого? Вы похоже, так и не поняли логику этой недокументированной фичи, которая является главным топиком в этой ветке ))) Попробуйте ещё раз перечитать или задавайте вопросы конкретно. Реади принимает нулевое значение не сразу, а только спустя 4 такта, т.е. успевает скушать 4 слова - всё как надо, всё как описано в первом сообщении.

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

Кроме того предлагаю для наглядности оба сброса датамувера подсоединить к одному источнику, чтобы не было желания предполагать, что разница моментов сброса как-то влияет. Да и на одну тактовую можно для начала перейти в домене датамувера. Т.е. Вы можете оставить командный интерфейс асинхронным, но подать тактовую ту же самую, что и на интерфейс данных. А вообще может даже лучше для простоты пока отказаться от асинхронного интерфейса. Чтобы не ломать голову лишними причинами.

И ещё у Вас используется сигнал tlast я смотрю. Предлагаю для начала его не использовать, и пересылать такие команды, чтобы датамувер на ласт не обращал внимания. У меня в начале в этом была загвоздка. А потом я понял, что ласт мне вообще не нужен, только лишняя логика.

почему сигнал реади (s_axi_s2mm_tready)
... при появлении сигнала данных (s_axi_s2mm_tvalid)
...
... после нескольких тактов s_axi_s2mm_tvalid
...
вот картина если я отключаю проверку s_axi_s2mm_tready
... s_axi_s2mm_tready не проверяется....

Вот Вы пишете s_axi_s2mm, а на самом деле наверняка должно быть s_axis_s2mm. Я потому и просил приводить полное имя сигнала, т.к. это разные вещи. _axi_ - это полная шина, которая идёт от датамувера к интерконнекту и далее в память. А _axis_ - это сигналы стрима. Их важно отличать.

И ещё Вы ничего не рассказали про сигнал tkeep, зачем он Вам и вообще что он делает.

[Alexey_Rostov]

Вот Вы пишете s_axi_s2mm, а на самом деле наверняка должно быть s_axis_s2mm. Я потому и просил приводить полное имя сигнала, т.к. это разные вещи. _axi_ - это полная шина, которая идёт от датамувера к интерконнекту и далее в память. А _axis_ - это сигналы стрима. Их важно отличать.

безусловно речь идет s_axis_s2mm

Ну а что тут такого? Вы похоже, так и не поняли логику этой недокументированной фичи, которая является главным топиком в этой ветке ))) Попробуйте ещё раз перечитать или задавайте вопросы конкретно. Реади принимает нулевое значение не сразу, а только спустя 4 такта, т.е. успевает скушать 4 слова - всё как надо, всё как описано в первом сообщении.

попробовал сначала передать 4 слова и далее поток. Ситуация не изменилась.

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

не совсем ясно. Логика проекта следующая: стрим ядро (мастер стрим для s2mm датамувера) получает валид от фифо как только началось наполнение, но реади в фифо для стрима не передает. Ждет пока фифо наполнится(запись в фифо происходит на меньшей частоте чем считывание). Это позволяет перейти от медленного клока потока к клоку для записи в ДДР, те буферизация. При считывании мастер стрим дает фифо сигнал реади, и стрим пошел в s2mm датамувера.

Если так не делать, то поток будет на медленной частоте подаваться в датамувер. Тогда в составе датамувера должно быть фифо для накопления burst для трансфера. Очень может быть загвоздка в этом моменте. Как только внутреннее фифо датамувера наполняется, происходит трансфер. Размер фифо выставляется в настройках датамувера (burst size). Задумывался об этом...

И ещё у Вас используется сигнал tlast я смотрю. Предлагаю для начала его не использовать, и пересылать такие команды, чтобы датамувер на ласт не обращал внимания. У меня в начале в этом была загвоздка. А потом я понял, что ласт мне вообще не нужен, только лишняя логика.

вы имеете в виду состав команды в cmd регистре, при которой датамувер не обращает внимание на ласт сигнал? не совсем ясно...

И ещё Вы ничего не рассказали про сигнал tkeep, зачем он Вам и вообще что он делает.

tkeep я сейчас не использую. Но вообще сигнал выставляет стробы побайтной записи/считывания на AXI4 (побайтная адресация ).

[Krys]

безусловно речь идет s_axis_s2mm

Внимательнее ) Запутать собеседника можно капитально )

попробовал сначала передать 4 слова и далее поток. Ситуация не изменилась.

Теперь мне не совсем ясно данное предложение. Т.е. Вы двумя раздельными командами датамуверу сначала дали дали команду переслать 4 слова, а затем другой командой оставшиеся? Я предлагаю вообще не разделять на первые 4 слова и на всё остальное. Если следовать логике, которую я описывал выше и которую я считаю стандартной для фифо, то валид на выходе из фифо в датамувер будет сразу, как только есть хоть одно слово для передачи. Но датамувер их есть не должен, пока не дана команда. И реади он без команды не выставит (исключение - первые 4 слова).

не совсем ясно. Логика проекта следующая: стрим ядро (мастер стрим для s2mm датамувера) получает валид от фифо

Мне непонятно, что Вы подразумеваете под стрим ядром и что под фифо? Я понимаю так: есть генератор медленной последовательности, которая подключена к фифо (у Вас это называется фифо для стрима). Фифо буферизирует и отдаёт пачки в датамувер. Стрим ядро это тот самый генератор медленной последовательности? Или стрим ядро - это датамувер + память + AXI Interconnect?

При считывании мастер стрим дает фифо сигнал реади, и стрим пошел в s2mm датамувера.

Вы применяете термин мастер стрим, фифо для стрима, датамувер. Предлагаю не запутывать самопридуманными терминами, где это не надо. Очень тяжело распутывать )) Судя по данному предложению, сигнал реади даёт датамувер в направлении вашего "фифо для стрима"? Если я правильно распутал...

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

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

Тогда в составе датамувера должно быть фифо для накопления burst для трансфера. Очень может быть загвоздка в этом моменте. Как только внутреннее фифо датамувера наполняется, происходит трансфер. Размер фифо выставляется в настройках датамувера (burst size). Задумывался об этом...

Это только когда C_S2MM_INCLUDE_SF = 1. У Вас не так. Да и у меня тоже. И работает. Причина не в этом. Экспериментально проверено, что если команда на передачу началась, а в стриме ничего нет, то датамувер блокирует всю шину AXI в DDR до окончания передачи. Чтобы блокировки не произошло, и другие устройства могли иметь доступ к памяти, в случае C_S2MM_INCLUDE_SF = 0 пользователь сам должен следить, чтобы в фифо, откуда будет выдаваться стрим на датамувер, имело достаточно данных, чтобы провести полную пересылку числа байтов, указанных в команде датамувера.

вы имеете в виду состав команды в cmd регистре, при которой датамувер не обращает внимание на ласт сигнал? не совсем ясно...

Ага.

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

Ну короче жду разъяснений.

[Alexey_Rostov]

Мне непонятно, что Вы подразумеваете под стрим ядром и что под фифо? Я понимаю так: есть генератор медленной последовательности, которая подключена к фифо (у Вас это называется фифо для стрима). Фифо буферизирует и отдаёт пачки в датамувер. Стрим ядро это тот самый генератор медленной последовательности? Или стрим ядро - это датамувер + память + AXI Interconnect?

для разъяснения привожу собранный в xps проект

итак, ddr + axi4 + datamover + master_strm (user IP или мой мастер стрим)
master_strm подключен к datamover как мастер (M_AXIS) для s2mm через интерфейс axi stream, slave порты (S_AXIS) выведены "наружу" и подключены к выходу fifo (там где происходит буферизация потока). на вход fifo подключен генератор медленной последовательности.

Вы применяете термин мастер стрим, фифо для стрима, датамувер. Предлагаю не запутывать самопридуманными терминами, где это не надо. Очень тяжело распутывать )) Судя по данному предложению, сигнал реади даёт датамувер в направлении вашего "фифо для стрима"? Если я правильно распутал...

Прошу прощения за запутанность)) сигнал реади для fifo формирует master_strm по наполнению fifo. По этому сигналу данные из fifo потоком через master_strm подаются на вход datamover s_axis_s2mm_tdata.

То есть master_srm я использую как мастер стрима для s_axis_s2mm моего datamover. Это позволяет контролировать наполнение fifo. До этого делал иначе: просто выводил сигналы s_axis_s2mm (_tvalid, _tlast, _tready ...) наружу и прикручивал к ним генератор медленной последовательности.

Это только когда C_S2MM_INCLUDE_SF = 1. У Вас не так. Да и у меня тоже. И работает. Причина не в этом. Экспериментально проверено, что если команда на передачу началась, а в стриме ничего нет, то датамувер блокирует всю шину AXI в DDR до окончания передачи. Чтобы блокировки не произошло, и другие устройства могли иметь доступ к памяти, в случае C_S2MM_INCLUDE_SF = 0 пользователь сам должен следить, чтобы в фифо, откуда будет выдаваться стрим на датамувер, имело достаточно данных, чтобы провести полную пересылку числа байтов, указанных в команде датамувера.

за разъяснение отдельное спасибо.

Сообщение отредактировал farbius - Dec 24 2014, 05:22