[yes 18]

мне с точки зрения здравого смысла всегда казалось, что outstandings - это возможность системы обеспечить какое-то количество одновременных незавершенных транзакций (типа capability), а in-flight это реазизация этой возможности, сколько реально незавершенных транзакций "бегает" в рабочем состоянии, то есть in-flight <= outstandings.

и соответственно (опять здравый смысл - каких-то внятных определений я не нашел) имеет смысл считать outstandings/in-flights на конкретном пути маcтер-интерконнект-слэйв, а не по всей больнице

=================

на практике имею мастер, который может испустить 4 AR запроса, интерконект (от PULP), который имеет память, например, глубиной 8 запросов, и слэйв, который сугубо последовательный, задержка случайно зависит от адреса, накакой оптимизации, то есть переупорядочивания запросов (как в SDRAM контроллере) невозможно в принципе, нет смысла (по-моему) принимать несколько запросов, на 1 запрос - то есть получил адрес - опустил ARREADY

причем память в интерконнекте - это не конвеер/FIFO, а специальная память, которая работает не обязательно in-order, то есть для разных RID запросы могут обрабатываться не по порядку (что неважно для этого примера)

при этом мой оппонент говорит, что так как в слэйве аутстендингов 1, то число аутстэндингов min(4,8,1)=1 и значит система имеет 1 outstandings и будет плохо работать - то есть латенси интерконнекта будет влиять на пропускную способность.

но в то же время, я с приблизительно такой же системой имел дело раньше и там вполне работало что 4 транзакции были "in-flight", то есть ARVALID у слэйва всегда был готов, backpresure не распространялась, то есть ARREADY у мастера всегда 1. получалось in-flight=4>min(4,8,1).  

приводить какие-то вэйформы я не могу, не тот уровень дискуссии (да и надо время, чтобы эти вэйформы получить).

--------------------------------

ИИ стал на сторону оппонента (что число оутстэндингов определяется как минимум чисел мастера/слэйва/интерконнекта) и приводит какие-то непонятные мне объяснения.

собственно вопрос - в чем я ошибаюсь, почему outstandings для приведенной выше системы min(4,8,1)=1, а не например 8 - размер памяти в интерконнекте? какой может быть сценарий, если я сделаю память запросов в слэйве (например, на 4 запроса)? то есть если я соберу систему в которой outstandings min(4,4,4)=4, как это может дать выигрышь на практике?

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

 

[RobFPGA 76]

1 hour ago, yes said:

ИИ стал на сторону оппонента (что число оутстэндингов определяется как минимум чисел мастера/слэйва/интерконнекта) и приводит какие-то непонятные мне объяснения.

Тут интересен конкретный вопрос задаваемый ИИ ...

1 hour ago, yes said:

собственно вопрос - в чем я ошибаюсь, почему outstandings для приведенной выше системы min(4,8,1)=1, а не например 8 - размер памяти в интерконнекте? какой может быть сценарий, если я сделаю память запросов в слэйве (например, на 4 запроса)? то есть если я соберу систему в которой outstandings min(4,4,4)=4, как это может дать выигрышь на практике?

Опять же как вы и говорили важен контекст для outstanding transactions.
Для  мастера слэйв (и соответсвенно для слэйва мастер) это то что висит непосредственно на другом конце шины, а не что то там за туманом интерконнектов.  
В этом контексте есть два разных значения outstanding transactions min(4,8) и min(8,1) и нет смысла их смешивать. 
  
Не знаю чем апеллировал ваш оппонент но выигрыш при мастер outstanding=4 по сравнению с outstanding=1 будет (для серии последовательных запросов).
Так как уменьшается latency на выдачу очередной транзакции на слэйв как минимум на величину латенси на хопе мастер - интерконнект.

1 hour ago, yes said:

а корневой вопрос - что мешает мне переложить поддержку outstandings на интерконнект (готовое IP) и не делать ее в слэйве? при каком сценарии работы (допустем еще есть мастера и слейвы и они как хотят взаимодействуют) скажется отсутствие аутстэндингов у слэйва?

Ничего не мешает. Чем ближе к слейву переносится поддержка множественный транзакций тем больше убирается влияние latency хопов на пути от мастер к слэйву (для серии транзакций).
Поддержка множественный транзакций непосредственно в слэйве нужна если позволяет уменьшить latency ответа самого слэйва.  

[yes 18]

23 hours ago, RobFPGA said:

Тут интересен конкретный вопрос задаваемый ИИ ...

воспроизводить беседу с ИИ слишком муторно, ну и понятно, что ловить ИИ на противоречиях - "специальная олимпиада". я описал систему - мастер 4 запроса, интерконект, допустим, 8 (я там хотел какой-то пример с двумя мастерами рассмотреть, но не добрался), слэйв 1 аутстендинг (то есть AR может брать до предыдущего RLAST), задал вопрос : сколько в системе аутстендингов - получил твердый ответ 1 с формулой min(m,i,s), ссылками на арм и т.д. тогда начал спрашивать а сколько in-flight может быть, а почему так, а что такое вообще аутстендинг.

-----------------

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

а так, я могу написать калькулятор/симулятор на питоне, который посчитает "баблы" в конвейере и выдаст пропускную способность.
но в моем представлении, на этот калькулятор, в рассматриваемом случае, не окажет влияние количество аутстендингов у слэйва. (то есть все просто, если я чего-то не просмотрел, о чем тоже интересно).

если удлинить конвейер между интерконнектом и слэйвом (добавить несколько AXI SLICE), то тогда возможность слэйва поддерживать несколько in-flight транзакций начнет играть роль, чтобы замаскировать задержки на этих слайсах - то есть да, я признаю, что может влиять, но это не рассматриваемый случай

-----------------

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

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

[RobFPGA 76]

On 11/11/2025 at 1:11 PM, yes said:

задал вопрос : сколько в системе аутстендингов - получил твердый ответ 1 с формулой min(m,i,s), ссылками на арм и т.д. тогда начал спрашивать а сколько in-flight может быть, а почему так, а что такое вообще аутстендинг.

Теперь понятно упорство ИИ ...  
Как уже говорил, и ARM со мной в этом соглашается ..., AXI это шина типа точка-точка.
Соответственно нет значения outstanding для системы. Значение оutstanding имеет смысл только для каждого хопа (пары мастер-слэйв) на шине.   

[yes 18]

спасибо. 

вряд ли мне поможет отрицание определений, признаваемых оппонентом, но, по крайней мере, такое определение сильно упрощает разбор "сценариев"

 

[fpga_dev 10]

Я бы не стал так глубоко копать (и тем более спорить с ИИ). Критерий истины это практика и подсчёт баблов на бумажке (или наблюдение оных в ILA) вполне себе рабочий метод. На мой взгляд разницы между терминами outstanding и in-flight нету. Первое чаще упоминается в доках второе более разговорное но никогда не встречал чтобы их как-то противопоставляли. И то и другое означает кол-во транзакций улетевших вдаль но обещавших вернуться, т.е. с момента напр. arvalid=1,arready=1 до соотв. rvalid=1,rready=1,rlast=1 Каких-то более формальных определений я не видел.

Формула  min(m,i,s) режет глаз, может ИИ перепутал и речь идёт о пропускной способности? Вообще мне кажется что интерконнект нельзя описать одним числом, нужно как минимум 2 (для слейва с 0 и oo числом outstanding). Тогда формула будет min(m,i0+s,ioo), т.е минимум длины пути внутри мастера, внутри интерконнекта и через слейв+интерконнект.

В вашем случае вы конечно правы и outstanding 4 будет работать лучше чем 1. Однако задержка интерконнекта играет тут важную роль. Производительность определяется самым медленным звеном в данном случае слейвом, дальше считаем если слейв требует N циклов на транзакцию и задержка на круг у нас M циклов то нужно как минимум ceil(M/N) outstanding со стороны мастера.  Если у ваз задержка в интерконнекте скажем 5 циклов а слейву нужно 10 то увеличивать outstanding у мастера больше 2 смысла нет.

Просто увеличение outstanding со стороны слейва без увеличения пропускной способности ничего не даст и вдобавок потребует соотв. увеличения со стороны мастера чтобы остаться при своих. Но обычно они взаимосвязаны.

 

[dxp 157]

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

На мой взгляд разницы между терминами outstanding и in-flight нету. Первое чаще упоминается в доках второе более разговорное но никогда не встречал чтобы их как-то противопоставляли.

In-flight вообще мне не попадалось до этой темы, не помню в спеках такого термина. 

Дикпик, например, считает, что outstanding -- это начатые и незавершённые, а in-flight -- это те, данные которых в этот момент передаются. Например, в канале адреса хендшейк произошёл, транзакция становится outstanding, но сами данные пока не передаются. А вот когда данные полетели, то это, типа, уже in-flight. Смысл такого деления по мнению дикпика в том, что in-flight показывает загруженность каналов передачи данных. На мой взгляд, просто натяжка, харатерная для LLM.

Я попросил его найти упоминания в доках ARM про in-flight и привести цитату. Он ничо не нашёл, а погуглив выдал только ссылку на эту тему. 

У меня вопрос: откуда этот термин "in-flight" взялся?

[blackfin 70]

On 11/14/2025 at 10:05 AM, dxp said:

У меня вопрос: откуда этот термин "in-flight" взялся?

В стандарте PCI Express часто используют этот термин:

Quote

A Downstream Port may use this provision to redo some parts of the Transmitter Equalization process using software help or some other implementation specific means while ensuring no transactions are in flight on the Link to avoid any timeouts.

 

[dxp 157]

Про PCIe вопросов нет, но тут-то речь про AXI, и там я встречал только outstanding. Читаю тему и заподозревал, может я что-то упустил. Не люблю такие пробелы оставлять, отсюда и вопрос.

[fpga_dev 10]

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

[fpga_dev 10]

Да извините  ошибся в предыдущем посте, транзакция считается  outstanding с момента аыставления адреса и arvalid/awvalid поскольку с этого момента отменить её уже нельзя.

[blackfin 70]

.

[yes 18]

я не уверен, что in-flight это общеупотребимый термин для AXI, может это в каких-то моих кругах принято. используется как результат работы (в противопоставление outstanding которое обозначает возможность). то есть с момента AR/AW до RLAST/B - независимо от того что на W/R. 

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

-------

наверно, чтобы свободнее оперировать терминами и "синхронизовать" их значения надо по каким-то конференциям ездить, доклады и статьи читать, но нет времени на это... 

[RobFPGA 76]

3 minutes ago, yes said:

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

Да скорее из сетевого. Правильнее было бы называть это сегментом, но уж извиняйте с чем больше работаешь теми терминами по привычке оперируешь.