[_andrew_ 0]

Необходимо сделать блок формирования кофигурируемых коммутаций абонентов шины AMBA AXI.

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

 

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

 

 

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

 

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

[des00 25]

AHP(нашел подробное описание AHP на русском).

<{POST_SNAPBACK}>

 

А линк не подскажете ?

очень интересно изучить:)

[PorychikKize 4]

А линк не подскажете ?

очень интересно изучить:)

<{POST_SNAPBACK}>

 

 

Да-да, сслылочку в студию, плиз! :-) или, м.б. файл прямо на мыло? :-)

[_andrew_ 0]

линка нет:) все в твердой копии в книге.

а во тпо AXI нет:(((((( срочно надо делать а доков даже на английском нет..

[scheme_ru 0]

линка нет:) все в твердой копии в книге.

а во тпо AXI нет:(((((( срочно надо делать а доков даже на английском нет..

<{POST_SNAPBACK}>

 

Как это нет доков? Сперва, читая эту ветку, я думал, что речь идет именно о переведенных спецификациях. Понятно, что их пока и в помине нет. Что же касается англоязычных, то смотрите сразу первоисточник (AMBA - это шина от ARM) - на сайте www.arm.com

 

The AMBA AXI specification is open, and can be downloaded free of any charges.

 

Ссылка на загрузку в конце текста. Сначала, правда, простенькую регистрацию придется пройти.

 

 

Собственно, там все три типа AMBA можно и загрузить: APB, AHB и AXI.

Спецификации на PrimeCell AXI компоненты там же.

[_andrew_ 0]

не считайте мен идиотом:) но я не нашел "PrimeCell AXI Configurable Interconnect (PL300) Implementation Guide (ARM DII 0121)" на сайте:\ нашел только Technical Reference Manual... а там ссылка как раз на Implementation Guide которой собственно и не найду...

[scheme_ru 0]

не считайте мен идиотом:) но я не нашел "PrimeCell AXI Configurable Interconnect (PL300) Implementation Guide (ARM DII 0121)" на сайте:\ нашел только Technical Reference Manual... а там ссылка как раз на  Implementation Guide которой собственно и не найду...

<{POST_SNAPBACK}>

 

У меня встречный вопрос - а зачем, собственно, ее искать? Не думаю, что в этих документах скрыта какая-то панацея :) Делать все равно придется самому. Тех спецификаций, что есть на сайте, достаточно для понимания принципов работы AXI и понимания работы компонента PL300 - описание архитектуры, сигналов и даже временные диаграммы присутствуют. Что касается документов, на которые они ссылаются (типа Implementation Guide), то я подозреваю, что этот документ поставляется вместе с компонентом и содержит в себе описание того, как пользоваться GUI или TCL -скриптами по конфигурированию арбитра: какие кнопки нажимать, какие параметры куда вводить и что они означают. Конечно, это может быть полезным для понимания того, как реализован сам компонент, но, думаю, мало что в этом смысле добавит: перечень конфигурируемых опций и их описаний уже есть в Technical Reference, а то, как именно их задавать через GUI или TCL не так-то и важно (если, конечно, перед Вами не стоит задача создания именно похожего TCL-скрипта по конфигурированию арбитра помимо создания RTL-модели).

 

Арбитр AXI придется делать самостоятельно, шина относительно новая, вряд ли удастся где-то подсмотреть. В качестве примера конфигурируемых арбитров могу посоветовать познакомиться с арбитром шины AHB, предлагаемом в свободной распространяемой GRLIB IP Library. Там есть и описание, и примеры использования, и tcl-скрипты для конфигурирования. Реализовано все на VHDL. Только это, все же AHB, а не AXI, и разница в некоторых местах существенная. Кроме того, там мне не нравится сам принцип арбитрации - активен только один мастер в один момент времени, даже если обращения идут к разным слэйвам. Но это все особенности реализации, и всего лишь пример.

[oval 0]

не считайте мен идиотом:) но я не нашел "PrimeCell AXI Configurable Interconnect (PL300) Implementation Guide (ARM DII 0121)" на сайте:\ нашел только Technical Reference Manual... а там ссылка как раз на  Implementation Guide которой собственно и не найду...

<{POST_SNAPBACK}>

Я в свое время тоже не нашел. Можно посмотреть у Synopsys'а, там есть кое что. Вообщем в результате подумали и сделали сами.

 

Полностью согласен с scheme_ru.

[_andrew_ 0]

написал письмецо в ARM ответили что действотельно Implementation Guide поставляется только с компонентом... буду довольствоваться тем что есть

да еще с учем моих познаний в английском у меня класные перспективы...

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

1. каким образом определяется пара master / slave , по адресу?

2. в момент времени может происходить одновременный обмен нескольких пар master/slave?

у меня есть подробное описание AHP (на русском с примером реализации), если не трудно, можно отметить моменты принципиального различия?

заранее спасибо!

 

кстати спасибо за ссылку, сечас качаю, посмотрю вечером...

[scheme_ru 0]

...думаю к понедельнику созреют конкретные вопросы. а пока пару очен простых и глупых вопросоов...

1. каким образом определяется пара master / slave  , по адресу?

2. в момент времени может происходить одновременный обмен нескольких пар master/slave?

у меня есть подробное описание AHP (на русском с примером реализации), если не трудно, можно отметить моменты принципиального различия?

 

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

 

Но отвечу.

 

Основные особенности шины AXI - это пакетная организация (burst-based) обмена данными и наличие 5-ти независимых каналов. Каналы следующие:

1. Канал адреса операций записи.

2. Канал данных операций записи.

3. Канал отклика операций записи.

4. Канал адреса операций чтения.

5. Канал данных/отклика операций чтения.

 

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

 

Как видно из перечня каналов, сигналы записи и чтения полностью разнесены, включая адресные линии. Т.е. один мастер, равно как и один слэйв, в один момент времени могут участвовать одновременно независимо в двух циклах: один цикл операции записи, второй операции чтения.

 

Операция чтения происходит в две фазы (address information to be issued ahead of the actual data transfer): на адресной фазе мастер выставляет на адресном канале операций чтения адрес и размер пакета данных (а также дополнительные атрибуты - lock type, protection type, cache type), на фазе данных получает с канала данных операций чтения пакет считанных данных и/или отклик. Операция записи отличается тем, что в ней к фазе данных добавлена еще фаза отклика на канале отклика операции записи. (Впрочем, фазы - это мой термин, который я здесь использую для удобства, и "фазы" данных и отклика в операции записи нельзя однозначно разделить по времени как идущие друг за другом).

 

Смысл независимости каналов в том, что адресные фазы могут идти друг за другом, независимо от того, прошли ли уже соответствующие им фазы данных или нет, т.е. циклы могут быть конвейеризированы (support for multiple outstanding transactions). Более того, при использовании специальных меток - тэгов, фазы данных могут проходить даже в очередности, отличной от очередности фаз адресов (support for out-of-order completion of transactions.). Т.е. сперва, например, может придти ответ от более быстрого устройства, к которому мастер обратился во втором адресном цикле, а уж затем с задержкой придет ответ от медленного устройства, к которому мастер обратился в первом адресном цикле.

 

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

громоздким. Ширина шин данных от 8 битов до 1024 в порядке геометрической прогрессии с показателем 2 (8, 16, 32, ..., 1024). Шина инвариантна к порядку байтов в слове, т.е. поддерживается как little, так и big endianity.

 

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

[_andrew_ 0]

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

 

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

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

 

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

 

еще. поправте меня пожалуйста , наверняка ошибаюсь:) :

допустим необходимо произвести обмен со слэйвом с его ID (если в общем

без VALID READY типов транзакций, блокировок и т п ,с нимим как раз вроде понятно)

 

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

 

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

что за чудо такое?

 

 

 

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

 

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

[scheme_ru 0]

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

 

Имеются ввиду теги 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 0]

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

По какому принципу тогда коммутируется Канал данных операции записи?

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

[scheme_ru 0]

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

По какому принципу тогда коммутируется Канал данных операции записи?

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

<{POST_SNAPBACK}>

 

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

Мастер посылает данные с 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 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" без отступления от спецификации?