[fpga_dev 11]

11 hours ago, alexPec said:

делает всю кэш в диапазоне "грязной" и процессор при обращении к данным из этого диапазона берет их из физической памяти, а не из кэша.

Здесь ошибка в терминах, что может быть важно для понимания процесса. "Грязные" данные (dirty cacheline) это те которые были изменены процессором в кеше но ещё не записаны в память. Они могут быть вытеснены из кеша в память в любой момент (cacheline eviction). "Чистые" это когда данные в кеше не менялись процессором с момента последнего чтения из/записи в память. Invalid это когда данные только в памяти но не в кеше (линия помечается как свободная но может быть занята чем то другим в любой момент)

[dxp 198]

9 часов назад, alexPec сказал:

А! Сначала invalidate, потом данные закачиваем в память?

У меня в Zynq-7000 данные заливаются в память (DDR) через AXI_HP0 со стороны PL, потом PL мечет прерывание PS, там проц делает Xil_DCacheInvalidateRange, после этого читает данные, они правильны. Какая разница, когда сказать, что кэш-линии невалидны, до или после? После инвалидации обращение будет в любом случае к памяти. Если это делать сильно до, то есть вероятность, что в эту область кэша будет что-то записано со стороны процессора, тогда эта линия уже не будет считаться невалидной. Конечно, тут зависит от политике кэша и от того, в какой канала попала запись. 

1 час назад, fpga_dev сказал:

В теории на  Ultrascale+ можно все сделать  cache coherent и обойтись без танцев с бубном. 

Для этого нужно подключаться через S_AXI_HPCx, выставить правильный AxCACHE и ещё кое-что по мелочи.

Ничего не путаете? Это ACP (Accelerated Coherency Port) умеет поддерживать когерентность кэшей при записи в память,т.к. гонит транзакции через SCU. А HPx работают напрямую с памятью, мимо кэшей, откуда там аппаратная когерентность возьмётся?

[fpga_dev 11]

19 minutes ago, dxp said:

Ничего не путаете?

В ultrascale есть S_AXI_HPCn (I/O cache coherent) и S_AXI_HPn (non-coherent) плюс ещё ACP (2-way coherent). Но с ACP работать тяжело, он вообще для другого (если хотите делать свой собственный когерентный кеш то вам сюда). В Zynq-7000 HPC нет.  И именно поэтому наши программизды US+ любят а Zync не очень.

А разница когда делать Invalidate существенная. Пока вы не сделали flush, clean (что тоже самое) или invalidate, остаётся шанс что у вас в этом диапазоне есть в кеше грязные данные которые в любой момент могут быть слиты в память в результате eviction

Edited December 25, 2025 by fpga_dev

[fpga_dev 11]

Вот ещё пример:

https://adaptivesupport.amd.com/s/article/69446

[dxp 198]

29 минут назад, fpga_dev сказал:

Но с ACP работать тяжело

В чём состоит тяжесть?

29 минут назад, fpga_dev сказал:

он вообще для другого

Поясните? Для чего для другого?

29 минут назад, fpga_dev сказал:

А разница когда делать Invalidate существенная. Пока вы не сделали flush, clean (что тоже самое) или invalidate, остаётся шанс что у вас в этом диапазоне есть в кеше грязные данные которые в любой момент могут быть слиты в память в результате eviction

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

[fpga_dev 11]

24 minutes ago, dxp said:

В чём состоит тяжесть?

Там вроде размер бёрста фиксированный под размер линии кеша и byte enables нет? Потом он лезет напрямую в L1 кеш и при больших объёмах данных может вынести его нафиг, что будет сильно тормозить процессор.

26 minutes ago, dxp said:

Для чего для другого?

В основном чтобы минимизировать latency между процессором и акселератором при небольших объёмах данных. Те акселератор лезет процессору прямо в моск. А по поводу своего собственного кеша это я с ACE перепутал (у ultrascale есть ещё и такой), у него есть канал  arsnoop что позволяет синхронизировать свой кеш с кешем zynq.

А про invalidate я привёл цитату, у A53 нет отдельно invalidate, только clean+invalidate, что означает если у вас в кеше осталось что-то несохраненное с прошлого раза то оно будет вывалено в память когда вы делаете invalidate и если сделать это поздно то это пойдёт поверх новых данных от DMA.

И да, 7000 и ultrascale отличаются в таких важных мелочах.

[alexPec 6]

1 час назад, fpga_dev сказал:

Пока вы не сделали flush, clean (что тоже самое) или invalidate, остаётся шанс что у вас в этом диапазоне есть в кеше грязные данные которые в любой момент могут быть слиты в память в результате eviction

 

Скорее всего как раз мой случай. Я запускаю транзакцию, она проходит, и где-то входе транзакции или после данные из кэша сливаются в память (где были уже полезные данные, а их затерли кэшем), до того как я прочитаю оттуда данные транзакции. А после этого можно кэш сделать invalidate - ничего не поменяется, т.к. в память кэш уже  слил свои данные и затер мои. Если же мы до транзакции делаем invalidate, то кэш уже не будет сливать свои данные в память, а при обращении к памяти прочитаются данные из нее. Пока что вижу это единственное объяснение такому поведению кэша.

[dxp 198]

7 часов назад, fpga_dev сказал:

Там вроде размер бёрста фиксированный под размер линии кеша и byte enables нет?

А, вы про Zynq MPSoC. Про этот нюансов не знаю. в 7000 это обычный AXI3, такой же как и HPx.

7 часов назад, fpga_dev сказал:

Потом он лезет напрямую в L1 кеш и при больших объёмах данных может вынести его нафиг, что будет сильно тормозить процессор.

Это да, и в этом и весь смысл -- кидать данные, которые процу нужны. В противном случае процу каждый раз надо делать инвалидацию перед обращением. А про "вынести моск" процу -- да, так и есть, об этом в доке написано. Есть некий баланс между оперативностью и загруженностью аппаратуры кэша. Нарушение баланса, как обычно, ни к чему хорошему не приводит.