AMBA AXI, Проектирование interconnect-а на AMBA Опции

[_andrew_]

Необходимо сделать блок формирования кофигурируемых коммутаций абонентов шины AMBA AXI.
Такой вопрос, чем принципиально отличается AXI от предыдущей AHP(нашел подробное описание AHP на русском). Прочитал спецификацию на interconnect(PrimeCell AXI Configurable Interconnect PL300) - не совсем понятно(да и с английским так себе..) Если есть ссылки какие - буду весьма благодарен.

Насколько я понял необходимо сделать узел-мультиплексор с multi-layer и арбитра для выбора мастера и слэйва(с учетом возможных типов доступа к шине). Примерно так в общих чертах?


Может есть какая мегафункция? делать конечно все равно прийдется - но зато можно будет сравнить результат работы.

не могу найти "PrimeCell AXI Configurable Interconnect (PL300) Integration Manual", все время ссылаются в спецификации а нигде нет ее.

[_andrew_]

Более того, при использовании специальных меток - тэгов, фазы данных могут проходить даже в очередности, отличной от очередности фаз адресов...

Имеются ввиду теги AWID, ARID ...? так называемый interleaving?
тогда такой вопрос:

при различной размерности ID мастер добавляет к ID slava ... в примере в спецификации в одном случае добавил единички, в другом нолики...

еще. поправте меня пожалуйста , наверняка ошибаюсь :
допустим необходимо произвести обмен со слэйвом с его ID (если в общем
без VALID READY типов транзакций, блокировок и т п ,с нимим как раз вроде понятно)

1. мастер выставляет адресс, по memory map находим slave к которому обращается master. или же мастер выставляет ID слэйва к которому обращается... в общем если нетрудно , можете пояснить механизм определения пары мастер слэйв. читал 3 раза этот момент, но мой английский далек...

еще не совсем понятен(опять же из-за английского) поддержка TrustZone
что за чудо такое?



Еще что может быть интересно, так это порядок байтов и байт-перевороты.

не совсем понял что вы имеете ввиду... это что то из области выравнивания?

[scheme_ru]

Более того, при использовании специальных меток - тэгов, фазы данных могут проходить даже в очередности, отличной от очередности фаз адресов...

Имеются ввиду теги AWID, ARID ...?  так называемый interleaving?

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

тогда такой вопрос:

при различной размерности ID мастер добавляет к ID slava  ... в примере в спецификации в одном случае добавил единички, в другом нолики...

На этот вопрос в спецификации четко даны ответы в пп. 8.7 и 8.8. Рекомендуется, чтобы ширина ID в мастере была равна 4 битам, а ширина ID в слэйве равна 8 битам. Оставшиеся 4 бита к ID мастера должен добавлять сам интерконнект по принципу "географической адресации" статически таким образом, чтобы 4-битовая "база" ID у каждого мастера была уникальной в рамках интерконнекта. При такой схеме один мастер одновременно может обрабатывать до 16 перемешанных потоков, а в рамках интерконнекта может находиться до 16 мастеров.

еще. поправте меня пожалуйста , наверняка ошибаюсь  :
    допустим необходимо произвести обмен со слэйвом с его ID (если в общем
без VALID READY типов транзакций, блокировок и т п ,с нимим как раз вроде понятно)

  1. мастер выставляет адресс, по memory map находим slave к  которому обращается master.  или же мастер выставляет ID слэйва к которому обращается... в общем если нетрудно , можете пояснить механизм определения пары мастер слэйв. читал 3 раза этот момент, но мой английский далек...

У слэйвов нет ID, как их нет и у мастеров. ID - это атрибут транзакции, а не идентификатор слэйва или мастера, и он не используется для глобальной адресации внутри интерконнекта. ID нужны для того, чтобы участники взаимодействий в перемешанных потоках данных могли в правильном порядке собрать данные на получающей стороне, а также вернуть отклик соответствующему мастеру. Т.е. мастер, начиная транзакцию, назначает ей некоторый 4-битовый ID, затем к этому ID интерконнект добавляет "базовые" 4 бита, уникальные для данного мастера. Таким образом, вся транзакция в рамках интерконнекта характеризуется уникальным ID. Этот ID затем будет использоваться интерконнектом и слэйвом для манипулирования с потоками данных и откликов, т.к. каждый отклик и слово данных сопровождаются своим ID. Правила обработки транзакций с учетом этих ID приведены в спецификации AXI в главе 8 - основной перечень правил в п. 8.2.

А выборка слэйва производится только по адресу в соответствии с memory map, тэги тут никакой роли не играют.

  еще не совсем понятен(опять же из-за английского)  поддержка TrustZone
что за чудо такое?

Похоже, что Вы за базовый документ приняли PrimeCell AXI Configurable Interconnect (PL300) Technical Reference Manual, а не собственно спецификацию AMBA AXI Protocol v1.0 Specification. В самой AXI нет никакой TrustZone, поэтому не стоит себе забивать себе голову этим feature некоторой частной реализации интерконнекта AXI, который, по-видимому нужен был кому-то из первых клиентов-заказчиков PL300.

Еще что может быть интересно, так это порядок байтов и байт-перевороты.

не совсем понял что вы имеете ввиду... это что то из области выравнивания?

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

[Loki5000]

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

По какому принципу тогда коммутируется Канал данных операции записи?
Поле WID этого канала выставляется мастером, однако слэйв имеет право выполнять транзакции(с разными ID) в любом порядке. Значит ему могут понадобиться данные от другой транзакции. А мастер не имеет возможности определить данные какой именно транзакции нужно передать слэйву.

[scheme_ru]

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

По какому принципу тогда коммутируется Канал данных операции записи?
Поле WID этого канала выставляется мастером, однако слэйв имеет право выполнять транзакции(с разными ID) в любом порядке. Значит ему могут понадобиться данные от другой транзакции. А мастер не имеет возможности определить данные какой именно транзакции нужно передать слэйву.

Не совсем понял, в чем вопрос?
Мастер посылает данные с 4-битовыми WID не заботясь о том, кто и как эти данные потом разбирает. Единственное, что он отслеживает - это handshaking на каждое слово и статус передачи на канале отклика. Он никак не идентифицирует слэйва-получателя транзакции. Слэйв определяется интерконнектом по memory map, и только интерконнект должен помнить на какой слэйв скоммутирована транзакция с данным ID от данного мастера.
В слэйв данные приходят с 8-битовым WID, старшие разряды которого указывают на мастера-источника данных, а младшие на номер потока(транзакции), который этот мастер присвоил данной транзакции.
И при операциях записи это не "слэйв имеет право выполнять транзакции с разными ID в любом порядке", а мастер имеет право выставлять данные с разными ID в произвольном порядке. Либо интерконнект может одновременно коммутировать на слэйв потоки от нескольких мастеров. Слэйв же обязан разбирать данные именно в том порядке, в котором они к нему приходят (иначе на канале записи данных необходимо было бы ввести возможность отклоенения приема текущего слова данных типа Retry later или Get off and let the faster go first, после которого пропускался бы более быстрый поток, а потом снова бы возвращалось отложенное слово ).
Количество потоков с разными ID, которые способен обрабатывать слэйв, определяется количеством адресов, посланных на слэйв до того момента, пока слэйв не снимет сигнал готовности приема очередного адреса через handshaking сигналами valid и ready на канале адреса. Т.е., если слэйв подверждает прием каждого следующего адреса на канале адреса только после полного завершения предыдущего пакета (burst), это означает, что он способен одновременно обрабатывать лишь один поток. Если же он подтвердит прием, к примеру, 4-х новых адресов, а 5-го не подтвердит до тех пор, пока один из burst-ов не завершится, это означает, что он способен обрабатывать до 4-х параллельных потоков.

[Loki5000]

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

ВОТ! Вот в этом-то и состоит вопрос!
Если обязать слэйв принимать данные на запись в любой последовательности,
то количество логики со стороны слэйва выростает до безобразия!
Давайте разберемся:
В таком случае слэйв должен иметь некий буфер данных для записи, чтобы в любом случае иметь возможность принять данные от мастера.
Разбор получаемых данных может происходить, либо "на лету" (т.е. сразу рассортировываться по нескольким очередям), либо необходимо организовать выборку требуемых данных из единой очереди. Оба варианта требуют ощутимое количество аппаратуры (хотябы той же памяти). Так же не ясен размер этого буфера. Сколько может прийти "непоследовательных" данных?!
Т.к. по спецификации данные могут приходить раньше самого запроса на запись(фазы передачи адреса записи), то получается что ограничить их число можно только принятием некого дополнительного соглашения по работе Мастера. Например: данные на запись приходят не ранее такого-то количества фаз данных, и не позднее такого-то количества фаз данных относительно фазы передачи адреса. Что так же может добавить логики и Мастеру!
Получается что ядро AXI - максимально упрощено, а логика мастеров и слейвов таким образом сильно усложняется!
Вопросы:
1) Верны ли на ваш взгляд мои суждения?
2) Нет ли каких-нибудь идей по решению этого вопроса?
3) Возможна ли реализация "возможности отклонения приема текущего слова данных типа Retry later или Get off and let the faster go first" без отступления от спецификации?

[scheme_ru]

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

ВОТ! Вот в этом-то и состоит вопрос!
Если обязать слэйв принимать данные на запись в любой последовательности,
то количество логики со стороны слэйва выростает до безобразия!
Давайте разберемся:
В таком случае слэйв должен иметь некий буфер данных для записи, чтобы в любом случае иметь возможность принять данные от мастера.
Разбор получаемых данных может происходить, либо "на лету" (т.е. сразу рассортировываться по нескольким очередям), либо необходимо организовать выборку требуемых данных из единой очереди. Оба варианта требуют ощутимое количество аппаратуры (хотябы той же памяти). Так же не ясен размер этого буфера. Сколько может прийти "непоследовательных" данных?!
Т.к. по спецификации данные могут приходить раньше самого запроса на запись(фазы передачи адреса записи), то получается что ограничить их число можно только принятием некого дополнительного соглашения по работе Мастера. Например: данные на запись приходят не ранее такого-то количества фаз данных, и не позднее такого-то количества фаз данных относительно фазы передачи адреса. Что так же может добавить логики и Мастеру!
Получается что ядро AXI - максимально упрощено, а логика мастеров и слейвов таким образом сильно усложняется!
Вопросы:
1) Верны ли на ваш взгляд мои суждения?
2) Нет ли каких-нибудь идей по решению этого вопроса?
3) Возможна ли реализация "возможности отклонения приема текущего слова данных типа Retry later или Get off and let the faster go first" без отступления от спецификации?

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

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

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

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

[Loki5000]

Дабы не запутать все окончательно, попытаюсь внести ясность:
Мне по прежнему не ясны 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]

[Вопрос 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]

[Вопрос 1]

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

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

[Вопрос 2]

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

[P.S.]

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

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