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", все время ссылаются в спецификации а нигде нет ее.

[Krys]

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

[GAYVER]

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

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

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

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