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-х параллельных потоков.