[scheme_ru 0]

Слэйв же обязан разбирать данные именно в том порядке, в котором они к нему приходят (иначе на канале записи данных необходимо было бы ввести возможность отклоенения приема текущего слова данных типа Retry later или Get off and let the faster go first, после которого пропускался бы более быстрый поток, а потом снова бы возвращалось отложенное слово  ). 

<{POST_SNAPBACK}>

 

ВОТ! Вот в этом-то и состоит вопрос!

Если обязать слэйв принимать данные на запись в любой последовательности,

то количество логики со стороны слэйва выростает до безобразия!

Давайте разберемся:

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

Разбор получаемых данных может происходить, либо "на лету" (т.е. сразу рассортировываться по нескольким очередям), либо необходимо организовать выборку требуемых данных из единой очереди. Оба варианта требуют ощутимое количество аппаратуры (хотябы той же памяти). Так же не ясен размер этого буфера. Сколько может прийти "непоследовательных" данных?!

Т.к. по спецификации данные могут приходить раньше самого запроса на запись(фазы передачи адреса записи), то получается что ограничить их число можно только принятием некого дополнительного соглашения по работе Мастера. Например: данные на запись приходят не ранее такого-то количества фаз данных, и не позднее такого-то количества фаз данных относительно фазы передачи адреса. Что так же может добавить логики и Мастеру!

Получается что ядро AXI - максимально упрощено, а логика мастеров и слейвов таким образом сильно усложняется!

Вопросы:

1) Верны ли на ваш взгляд мои суждения?

2) Нет ли каких-нибудь идей по решению этого вопроса?

3) Возможна ли реализация "возможности отклонения приема текущего слова данных типа Retry later или Get off and let the faster go first" без отступления от спецификации?

<{POST_SNAPBACK}>

 

 

Да ну, не сгущайте краски, все совсем не так мрачно.

 

Во-первых, никто не заставляет слэйв принимать данные на каждом такте или с неприемлимо высокой для него скоростью. Как только внутренние ресурсы заполняются - слэйв снимает сигнал готовности READY - и все, шина данных висит, пока внутренние ресурсы не освободятся и слэйв не будет способен продолжить прием, о чем он потом снова просигнализирует активизацией сигнала READY. Никаких мегабуферов не нужно, можно даже одним регистром обойтись, и вся игра идет на блокировании/разблокировании шины механизмом handshaking.

Проблема тут только одна: в случае, если слэйв одновременно реализует два интерфейса, существенно различающихся по производительности (напр., последовательный порт и синхронную память), то потоки на запись в медленный интерфейс могут блокировать потоки на запись в быстрый интерфейс. Да и то, это локальная блокировка, т.е. она актуальна лишь для данного слэйва и лишь для порта связи слэйва с интерконнектом. Мастер она не сильно напряжет: если мастер умеет работать с несколькими потоками, то он параллельно сможет работать с остальными слэйвами, и на производительностях тех обменов локальная блокировка в одном из слэйвов не скажется. Но вообще, отсюда сразу следует рекомендация - желательно в одном слэйве реализовывать интерфейсы, близкие по производительностям, чтобы не было таких затыков, когда производительность быстрого интерфейса блокировками фактически сведется к производительности медленного интерфейса.

 

Т.к. по спецификации данные могут приходить раньше самого запроса на запись(фазы передачи адреса записи)

 

Вот с этим утверждением совершенно не согласен. Где это в спецификации такое говорится? Это что, получается, что по AXI могут "гулять" неприкаянные данные, которые вроде уже есть, но по какому адресу их нужно направить еще не известно, и к какому burst-у они относятся, тоже непонятно? Откуда же берутся такие данные, разве какой-то мастер может сначала послать данные, а потом вдогонку пустить адрес и размер burst-а??? Где же эти данные "пережидают" момента, пока придет указание, куда их нужно направить - в недрах интерконнекта или по умолчанию, на всякий случай, рассылаются всем слэйвам, а там уж, когда адрес придет - видно будет, кому они достались по ошибке?

Нет, телега впереди лошади в AXI ходить не умеет. Сначала адресная фаза, в которой указывается адрес, размер burst-а (!), а также характеристики транзакции (тэги и дополнительные атрибуты), а уже только потом идут данные. И никак иначе.

[Loki5000 0]

Дабы не запутать все окончательно, попытаюсь внести ясность:

Мне по прежнему не ясны 2 вопроса:

 

[Вопрос 1]

 

выдержка из предпоследнего поста:

Не совсем понял, в чем вопрос?

Мастер посылает данные с 4-битовыми WID не заботясь о том, кто и как эти данные потом разбирает. Единственное, что он отслеживает - это handshaking на каждое слово и статус передачи на канале отклика. Он никак не идентифицирует слэйва-получателя транзакции. Слэйв определяется интерконнектом по memory map, и только интерконнект должен помнить на какой слэйв скоммутирована транзакция с данным ID от данного мастера.

В фазе передачи адреса записи, интерконнект определяет к какому слэйву идет обращение по memory map. Но в канале передачи данных записи никакого адреса уже нет, есть только WID, которое совпадает с переданным ранее AWID. Получается интерконнект должен адресовать эти данный тому слэйву, к которому была адресована первая из незавершенных транзакций фаза адреса записи с таким ID.

Например, рассмотрим такую последовательность событий:

1. Maстер-1 передает адрес записи Слэйву-1 с AWID=1;

2. Мастер-1 передает адрес записи Слэйву-2 с AWID=1; (ведь ID определяется внутренним потоком Мастера, и ни что не мешает этому потоку быть направленному нескольким слэйвам(поочередно например))

3. Мастер-1 выставляет готовность данных для записи с WID=1;

(Интерконнект должен адресовать эти данные Слэйву-1)

4. После завершения предыдущего обмена, Мастер-1 снова выставляет готовность данных для записи с WID=1;

(Интерконнект должен адресовать эти данные Слэйву-2)

 

Т.е. интерконнект должен иметь некий стек соединений каждого мастера со слэвами по каналу адреса, чтобы потом корректно соединять соответствующий канал данных.

Все верно???

 

[Вопрос 2]

 

выдержка из того же предпоследнего поста:

Слэйв же обязан разбирать данные именно в том порядке, в котором они к нему приходят...

Иными словами получается, что последовательность исполнения транзакций записи определяется: а) последовательностью предоставления данных для записи (по соответствующему каналу) Мастерами, б) Арбитром канала данных записи. А слэйв обязан выполнять транзакции именно в этой результирующей последовательности. Менять эту последовательность слэйв не имеет право. Что подтверждается фразой: "The slave interface must never stall the acceptance of write data in an attempt to change the order of the write data."(пункт "8.5 Write data interleaving")

Кстати, согласно тому же пункту: "By default, the write data interleaving depth of any interface is one." получается, что по-умолчанию слэйв вообще не поддерживает перестановку данных для записи (или поддерживает перестановку только одной пары транзакций, смотря как понимать глубину равную единице). Но если к одному слэйву имеют доступ N мастеров, то в случае одновременного предоставления мастерами данных для записи, арбитр соответствующего канала вправе выбрать любого из мастеров, в том числе и последнего кто предоставил адрес для записи. А значит глубина поддерживаемой перестановки транзакций слэйвом никак не может быть меньше числа мастеров имеющих доступ к этому слэйву!

 

Чтобы не быть более голословным, опишу реально решаемую задачу:

 

Есть Слэйв, который организует доступ к разделяемому ресурсу - Памяти. Несколько Мастеров имеет доступ к этому Слэйву. Для организации максимально эффективного использования разделяемого ресурса необходим эффективный арбитраж доступа к этому ресурсу. Иными словами Слэйв должен иметь возможность переставлять запросы к разделяемому ресурсу (с разными ID). Получается что AXI, хоть и позиционируется как шина, для организации сверх-быстрого доступа к разделяемым ресурсам, не позволяет этого сделать!

Единственный видимый пока мною выход, это создание нескольких виртуальных Слэйвов на шине, чтобы иметь возможность переставлять запросы от этих Слэйвов. Однако такое решение неизбежно увеличивает ширину мультиплексоров в интерконнекте!

Есть ли другие идеи???

 

 

[P.S.]

в ответ на последний пост:

Где это в спецификации такое говорится?  Это что, получается, что по AXI могут "гулять" неприкаянные данные, которые вроде уже есть, но по какому адресу их нужно направить еще не известно, и к какому burst-у они относятся, тоже непонятно? Откуда же берутся такие данные, разве какой-то мастер может сначала послать данные, а потом вдогонку пустить адрес и размер burst-а??? Где же эти данные "пережидают" момента, пока придет указание, куда их нужно направить - в недрах интерконнекта или по умолчанию, на всякий случай, рассылаются всем слэйвам, а там уж, когда адрес придет - видно будет, кому они достались по ошибке?

Нет, телега впереди лошади в AXI ходить не умеет. Сначала адресная фаза, в которой указывается адрес, размер burst-а (!), а также характеристики транзакции (тэги и дополнительные атрибуты), а уже только потом идут данные. И никак иначе.

Я имел ввиду Пункт "1.2.3 Register slices", цитата: "Each AXI channel transfers information in only one direction, and there is no requirement for a fixed relationship between the various channels." Т.е. количество защелок между интерфейсом мастера и слэйва, по разным каналам может быть разным (Латентность каналов может быть разной). Если латентность канала адреса записи больше латентности канала данных записи, то теоретически может возникнуть ситуация, когда данные появятся на интерфейсе слэйва раньше чем соответствующая фаза адреса.

[scheme_ru 0]

[Вопрос 1]

Так, да не совсем. В спецификации AXI п. 8.2.:

"The data for a sequence of write transactions with the same AWID value must

complete in the same order that the master issued the addresses in." Другими словами, если AWID одинаковые, но адреса разные, то сначала должна быть полностью завершена транзакция, соответствующая первому адресу, т.е. слэйву 1. Затем только мастер начнет выставлять данные, соответствующие второй транзакции, т.е. слэйву 2. Вы так и написали.

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

 

[Вопрос 2]

 

Зачем слэйву вообще переставлять транзакции? Пусть в сквозном режиме как данные приходят, так он их и перенаправляет дальше потребителям - например, в память.

Фраза о "slave must never stall..." говорит о том, что потребители разных потоков (ID) в слэйве должны обладать одинаковой производительностью, чтобы избежать взаимной блокировки потоков. То, что я в предыдущем посте назвал рекомендацией, в спецификации, оказывается, идет со словом must-обязательно.

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

 

Особняком стоит вопрос сохранения строгой последовательности событий в рамках AXI. Да, последовательность событий может нарушаться (тот же пример с одновременным запросом от нескольких мастеров - понятно, что на слэйв запросы придут в той очередности, которую назначит им интерконнект - последовательность событий изменится, вместо одновременного запроса образовалась очередь во времени), и нижнеуровневый протокол коммутации AXI это не волнует. В AXI говорится:

"If two write transactions with different AWID values access the same or overlapping

address locations then the processing order is not defined. A higher-level protocol must ensure the correct order of transaction processing." А с точки зрения слэйва и интерконнекта транзакции от разных мастеров имеют разный AWID., т.е. данное предложение однозначно говорит о том, что перестановкой данных от разных транзакций слэйв заниматься не обязан.

 

 

Я имел ввиду Пункт "1.2.3 Register slices", цитата: "Each AXI channel transfers information in only one direction, and there is no requirement for a fixed relationship between the various channels." Т.е. количество защелок между интерфейсом мастера и слэйва, по разным каналам может быть разным (Латентность каналов может быть разной). Если латентность канала адреса записи больше латентности канала данных записи, то теоретически может возникнуть ситуация, когда данные появятся на интерфейсе слэйва раньше чем соответствующая фаза адреса.

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

1. Сначала происходит handshaking на канале адреса.

2. Если выполнено 1., то разрешен прием данных и соответствующие handshaking на канале данных.

Иначе получалась бы та нерабериха с блуждающими данными, о которой я писал в прошлом сообщении.

[Loki5000 0]

[Вопрос 1]

 

По вопросу 1 считаю что консенсус достигнут!

 

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

P.S. моя собственная реализация интерконнекта работает немного по другому (хотя и не противоречит спецификации), но это связано с особенностями конкретной решаемой задачи.

 

[Вопрос 2]

 

У меня ситуация намного интереснее! Потребитель-то как раз у меня не один!

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

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

 

[P.S.]

 

1. Сначала происходит handshaking на канале адреса.

2. Если выполнено 1., то разрешен прием данных и соответствующие handshaking на канале данных.

Согласен! Причем именно из-за упомянутого при обсуждении вопроса 1 механизма повторения коммутаций на каналах данных (через стэк или без оного).

[_andrew_ 0]

всем спасибо, начинаю делать

 

кстати никто не подскажет интересной ссылочки по TCL-скриптам...

[Krys 2]

Я сейчас изучаю AXI4. Перечитал данное обсуждение, всё как в анекдоте: всё в этом обсуждении предельно понятно, непонятно только как керосин по проводам течёт )))

А именно: что конкретно подразумевают под outstanding? Есть разные интерпретации: outstanding address, outstanding transaction, outstanding feature support. Что всё это означает? В дословном переводе - выдающийся. Но не пойму, что в них такого выдающегося )))

Может кто-нибудь объяснить, как этим пользоваться, пожалуйста?

Читал это, ясности особо не прибавило. Вроде где-то что-то понятно, но не кристально понятно. В спецификации на протокол прошёлся поиском - тоже ничего особо не разъясняется, просто этот термин используется как данность.

[blackfin 32]

А именно: что конкретно подразумевают под outstanding? Есть разные интерпретации: outstanding address, outstanding transaction, outstanding feature support. Что всё это означает? В дословном переводе - выдающийся.

outstanding: ожидающий выполнения

 

[Krys 2]

Спасибо. Но всё равно непонятно. Зачем вообще употреблять этот термин? Чтобы указать, что эти транзакции ещё не выполнены? Т.е. разделяется на выполненные и не выполненные транзакции? Т.е. варианта всего 2 с применением этого термина или как?

 

[des00 25]

Спасибо. Но всё равно непонятно. Зачем вообще употреблять этот термин? Чтобы указать, что эти транзакции ещё не выполнены? Т.е. разделяется на выполненные и не выполненные транзакции? Т.е. варианта всего 2 с применением этого термина или как?

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

 

ЗЫ. ЕМНИП в стандарте на акси это на вейвформах разрисовано. И сделать мост, который поддерживает такие фенечки, не так то просто.

[Krys 2]

а как в таком примере слово outstanding применимо?

 

Попробую конкретизировать вопрос на примере. Вот например датащит, там на странице 47 есть такая фраза:

Note: For AXI4-Lite SI slots and MI slots, the ACCEPTANCE and ISSUING parameters, respectively, are ignored and only one outstanding transaction at a time is allowed.

Говорится что только одна ожидающая транзакция разрешена. Вот как тут понимать outstanding? Чисто по формальной логике из этого предложения следует, что существуют ещё другие транзакции, которые не outstanding, которые могут быть запрещены, либо разрешены в другом количестве. Зачем они в данном предложении применили термин outstanding? Можно подумать если не применить этот термин, то речь может идти о разрешении уже совершённых транзакций... естественно даже без употребления этого слова, что разрешать можно только те транзакции, которые ещё не совершены. Зачем они конкретизируют?

Это как написали бы "горячее пламя". Да, наверное, в экзотических случаях пламя бывает и холодное. Но применив слово горячее, зачем-то на этом акцентировали внимание, хотя и так по умолчанию подразумевается, что пламя горячее.

ds768_axi_interconnect.pdf

[Timmy 1]

а как в таком примере слово outstanding применимо?

 

Попробую конкретизировать вопрос на примере. Вот например датащит, там на странице 47 есть такая фраза: Говорится что только одна ожидающая транзакция разрешена. Вот как тут понимать outstanding? Чисто по формальной логике из этого предложения следует, что существуют ещё другие транзакции, которые не outstanding, которые могут быть запрещены, либо разрешены в другом количестве. Зачем они в данном предложении применили термин outstanding? Можно подумать если не применить этот термин, то речь может идти о разрешении уже совершённых транзакций... естественно даже без употребления этого слова, что разрешать можно только те транзакции, которые ещё не совершены. Зачем они конкретизируют?

Это как написали бы "горячее пламя". Да, наверное, в экзотических случаях пламя бывает и холодное. Но применив слово горячее, зачем-то на этом акцентировали внимание, хотя и так по умолчанию подразумевается, что пламя горячее.

Применительно к сетевой транзакции правильный перевод - начатая, но ещё незавершённая, выполняемая на текущий момент, транзакция. Вот мастер выставил в канале адреса запрос, и с этого момента транзакция будет считаться outstanding, пока мастер не получит подтвержение завершения данной транзацкии по каналу чтения/подтверждения записи. multiple outstanding предполагает, что мастер выставит конвейером кучу запросов на транзакции, не дожидаясь последовательно подтверждения ранее начатых, а если сказано only one otstanding, значит, мастер, выставив запрос, должен ждать его подтверждения, и только потом может выставлять следующий. Например, на шине Wishbone в принципе нельзя сделать multiple outstanding transactions, какое безобразие;).

[des00 25]

Зачем они конкретизируют?

ИМХО лучше всего изучать спецификацию на AXI не по даташитам на корки, а по оригинальной спецификации. Почитайте ARM AMBA4 где дана спецификация шины AXI. В спецификации приведены виды транзакций, модели исполнения транзакций, ограничения спецификации. И только потом стоит идти от общего к частному, т.е. реализации спецификации вендором.

 

 

а если сказано only one otstanding, значит, мастер, выставив запрос, должен ждать его подтверждения, и только потом может выставлять следующий.

вот бяка то какая :)

 

[Krys 2]

Timmy, спасибо, так понятнее

[GAYVER 2]

у нас АКСИ лайт и мы сделали немного по-другому ))

 

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

 

при этом если прийдет запрос от более приоритетного мастера - следующим в конвеер попадет его запрос, которому присвоится другой ИД-к. но это при условии что в конвеере интерконнекта адреса-данные идут ровно. если конвеер адресов забит, а данных нет - интерконнект будет "долавливать" данные от мастера, ведущего текущую передачу. таким образом слейв может получать перемешанные потоки, его АКСИ часть максимально примитивная. интерконнект тоже не сильно громоздкий.

 

вопрос в другом - если в системе очень много слейвов... тут да - такая система будет слегка избыточной. так же как и полнофункциональный интерконнект (1 блоком) в системе с 1-2 слейвами. в общем каждому выбирать вариант по своей задаче )). видимо поэтому реализацию интерконнекта и отдали конечному пользователю ))