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

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


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

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

А линк не подскажете ?
очень интересно изучить

А линк не подскажете ?
очень интересно изучить

[/quote]


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

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

Как это нет доков? Сперва, читая эту ветку, я думал, что речь идет именно о переведенных спецификациях. Понятно, что их пока и в помине нет. Что же касается англоязычных, то смотрите сразу первоисточник (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 компоненты там же.

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

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

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

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

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

написал письмецо в ARM ответили что действотельно Implementation Guide поставляется только с компонентом... буду довольствоваться тем что есть
да еще с учем моих познаний в английском у меня класные перспективы...
все выходные - чтение спецификаций, думаю к понедельнику созреют конкретные вопросы. а пока пару очен простых и глупых вопросоов...
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. Думаю, на Ваши вопросы ответ здесь приведен. Что касается остального - изучайте спецификацию, судя по диаграммам, циклы не такие и сложные.

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

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

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

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

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

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



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

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

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



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




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

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




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




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

По какому принципу тогда коммутируется Канал данных операции записи?
Поле 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-х параллельных потоков.

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

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

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



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

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

[Вопрос 1]

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

В фазе передачи адреса записи, интерконнект определяет к какому слэйву идет обращение по 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.]
в ответ на последний пост:

Я имел ввиду Пункт "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." Т.е. количество защелок между интерфейсом мастера и слэйва, по разным каналам может быть разным (Латентность каналов может быть разной). Если латентность канала адреса записи больше латентности канала данных записи, то теоретически может возникнуть ситуация, когда данные появятся на интерфейсе слэйва раньше чем соответствующая фаза адреса.

[Вопрос 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., т.е. данное предложение однозначно говорит о том, что перестановкой данных от разных транзакций слэйв заниматься не обязан.



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

[Вопрос 1]

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

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

[Вопрос 2]

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

[P.S.]


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

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

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

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

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

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

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

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

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

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

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

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



вот бяка то какая

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

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

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

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

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