[svedach 0]

Добрый день.

Есть кастомное ядро, которое через Xilinx DataMover и AXI SmartConnect (обслуживает еще других мастеров) пишет пару десятков байт в DDR. Полный путь такой:

После записи (проверяется статус по шине s2mm sts) ядро генерирует прерывание. По прерыванию ARM забирает данные из памяти, при этом не забыв инвалидировать кеш (Xil_DCacheInvalidateRange((uint32_t)_mu_hw_vals, (valSize | 0xFF))).

Вопрос состоит в следующем: как мне быть уверенным, что когда ARM отрабатывает прерывание, данные уже реально дошли до DDR - т.е. прошли через AXI SmartConnect и внутренности PS?

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

Есть ли какой-то механизм, обеспечивающий ожидание, что вся цепочка завершена и данные действительно записались в DDR? Или может я неправильно выстроил цепочку и надо зайти с драгой стороны?

[alexadmin 0]

А добавьте в данные счетчик!

[svedach 0]

2 минуты назад, alexadmin сказал:

А добавьте в данные счетчик!

Это конечно можно, только не совсем понимаю, что это даст. Я почти уверен, что к моменту обработки прерывания весь путь данными еще не пройден и я увижу данные с латентностью 1 прерывание. Мне нужно в момент обработки прерывания гарантированно иметь данные в ДДР...

[alexadmin 0]

Счетчик даст возможность контроля. Задержка вряд ли велика (негде данным там оседать надолго). В конце-концов можно откалибровать это время и добавить задержку формирования прерывания (с запасом). Вряд ли ведь от ARM'а требуется наносекундная реакция на прерывание.

[RobFPGA 27]

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

9 hours ago, svedach said:

Это конечно можно, только не совсем понимаю, что это даст. Я почти уверен, что к моменту обработки прерывания весь путь данными еще не пройден и я увижу данные с латентностью 1 прерывание. Мне нужно в момент обработки прерывания гарантированно иметь данные в ДДР...

Окончанием транзакции записи по шине AXI  является прием подтверждения по каналу bresp/bvalid/bready.  Это подтверждение генерируется в конечном получателе транзакции, в данном случае в контроллере памяти, и по цепочке шины возвращается в источник транзакции.

 
На  сколько помню  (давно уже datamover нe пользовал)  только получение последнего bresp сигнализирует что вся DMA пересылка окончена. Так что скорее всего когда  прерывание сгенерировано данные уже давно лежат  в памяти.  Но неплохо бы  вам это проверить на симе  чтобы  быть в этом уверенным.  

Удачи Rob.    

[svedach 0]

2 часа назад, RobFPGA сказал:

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

Окончанием транзакции записи по шине AXI  является прием подтверждения по каналу bresp/bvalid/bready.  Это это подтверждение генерируется в конечном получателе транзакции, в данном случае в контроллере памяти, и по цепочке шины возвращается в источник транзакции.

 
На  сколько помню  (давно уже datamover нe пользовал)  только получение последнего bresp сигнализирует что вся DMA пересылка окончена. Так что скорее всего когда  прерывание сгенерировано данные уже давно лежат  в памяти.  Но неплохо бы  вам это проверить на симе  чтобы  быть в этом уверенным.  

Удачи Rob.    

Спасибо, Rob. Умом тоже это понимал, но вдруг там FIFO какие есть или что-то иное...

Вобщем проблема решена. Вместо анализа s2mm sts, ожидаю сигнал s2mm_wr_xfer_cmplt и после него формирую прерывание. При этом все работает как ожидается.

Спасибо всем, откликнувшимся!

[warrior-2001 0]

Добрый день!

Добавлю ложку дёгтя.

Не помню, как у Xilinx Но у Intel есть возможность включения режима reordering для контроллеров DDR.

Если стек задать большим и очереди фифо в памяти ПЛИС установить жирные, то интерфейс контроллера DDR - AMBa AXI4 выдаст последний BVALID, однако данных в самой памяти физически ещё не будет!

В ПЛИС я успевал вычитывать из памяти старые данные, ибо лез туда, куда "не долетели" данные из очереди фифо. Однако это было тестирование ради тестирования. Когда за дело брался ARM процессор - данные давно уже были по своим адресам.

[RobFPGA 27]

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

1 hour ago, warrior-2001 said:

...

Не помню, как у Xilinx Но у Intel есть возможность включения режима reordering для контроллеров DDR.

Если стек задать большим и очереди фифо в памяти ПЛИС установить жирные, то интерфейс контроллера DDR - AMBa AXI4 выдаст последний BVALID, однако данных в самой памяти физически ещё не будет!

В ПЛИС я успевал вычитывать из памяти старые данные, ибо лез туда, куда "не долетели" данные из очереди фифо. Однако это было тестирование ради тестирования. Когда за дело брался ARM процессор - данные давно уже были по своим адресам.

Обычно reordering  работает с разными банками, то-есть  по сути с разными адресами и работает внутри самого контроллера.  Обычно при этом в контроллере еще и должна отслеживается такая ситуация с доступом к одному и тому же адресу находящемуся в конвейере контроллера. Но естественно это надо смотреть доки конкретного контроллера. Но опять же - чтобы начать что то читать надо сначала получить  прерывание  

О каких "жирных" FIFO вы говорите?   Задержки на пути шины AXI  для случая TC на это не влияют - ведь генерировать  прерывание  он будет  только получив последний bresp. 
Другое  дело если генерировать транзакции  чтения не дожидаясь окончания или  одновременно с записью.  Тут  даже сложно сказать как арбитраж самой AXI шины сработает.   

Ну или если цепочка шины AXI заканчивается не в контроллере памяти, а в каком либо меж-шинном bridge в котором неправильно реализовано  подтверждение записи. 
Типа  раз сюда данные добрались то и ладно, можно сразу отправлять bresp.   Ну тут уж от разработчика все зависит.

     

Удачи! Rob.

[lexx 0]

Я при обращении по AXI делал счётчик, который инкрементировал или декрементировал по grant и bresp. Нельзя точно сказать когда данные будут в DDR пока значения счётчика не будут равны нулю. Либо считать максимально допустимое значение счётчика, при заранее известном объёме передаваемых данных.

Если используется port_id, то bresp также обладает id и порядок записи с разными id в этом случае не гарантирован.

 

После возврата bresp мастеру данные обязаны быть в DDR или контроллер сам решает это на своём уровне, но если результат отличается, то имплементация отличается от стандарта.

 

Как вариант, переходите на OCP,  там таких проблем нет.

Изменено 21 апреля, 2021 пользователем lexx

[warrior-2001 0]

20.04.2021 в 17:54, RobFPGA сказал:

...

О каких "жирных" FIFO вы говорите?   Задержки на пути шины AXI  для случая TC на это не влияют - ведь генерировать  прерывание  он будет  только получив последний bresp. 
Другое  дело если генерировать транзакции  чтения не дожидаясь окончания или  одновременно с записью.  Тут  даже сложно сказать как арбитраж самой AXI шины сработает.   

...

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

Вот пример - в Qsys система, где есть переход между AMBA AXI И вот таким многопортовым контроллером памяти.

Как только по Ambа заканчивается транзакция - формируется bresp, а данные ещё бегут по аванолу в фифо соответствующего порта - и это поток. А с другого порта (пустого) мой блок тестирования сразу начинает читать. В Quartus 10 pro уже другой контроллер памяти и там такого не получится, но вот раньше возможность создать гонки при доступе к памяти была!

Изменено 22 апреля, 2021 пользователем warrior-2001
опечатки