[GAYVER 2]

Моделирую данную айпишку. Настройки по минимуму - в режиме SAMD, без буферов, фифошек, регистров, разных регионов, итд итп. В  конфигурации 2 мастера/4 слэйва. Один из слэйвов с переходом на акси лайт. Пока столкнулся с 2 моментами:

1. После начального сброса RREADY внутри кроссбара на мастер интерфейсе (к слэйвам) устанавливается в единицу. При этом на слэйв интерфейсах (со стороны мастеров) этот сигнал стоит в нуле, как и задается в модели. В процессе работы рэдик к слэйву все время стоит в единице, хотя мастер держит его в нуле и поднимает только на момент чтения

2. Зависает запись при обращении к следующему слэйву. В тестбенче последовательно идут циклы записи/чтения от каждого мастера к каждому слэйву. При этом последовательное обращение к одному и тому же слэйву проходит без сбоев.  Как только меняется адрес - в интерконнект приходит адрес с валидом, из интреконнекта валид к слэйвам не выходит. При этом все адреса верные и ошибок декодирования нет

 

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

 

зы

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

 

на скринах в общем случае должна быть видна ситуация с рэдиком

со стороны мастера

 

со стороны слэйва

 

 

[des00 25]

из описания ничего не понятно, на скринах классический акси, корка точно рабочая и проблем с ней не было, делал 2 мастера, 16 слейвов. А про зависание, скорее всего в карте сегментов ошиблись, байты со словами перепутали, а генерацию ошибки адресации не добавили в интерконнект. 

а про подстройку под себя, не замечал явных не соответствий спецификации. скорее, уже у вас разночтение, скачайте xapp1168 по акси, с примерами исходного кода разных мастеров и слейвов. затем копи-паст) 

[GAYVER 2]

3 часа назад, des00 сказал:

из описания ничего не понятно, на скринах классический акси, корка точно рабочая и проблем с ней не было, делал 2 мастера, 16 слейвов. А про зависание, скорее всего в карте сегментов ошиблись, байты со словами перепутали, а генерацию ошибки адресации не добавили в интерконнект. 

а про подстройку под себя, не замечал явных не соответствий спецификации. скорее, уже у вас разночтение, скачайте xapp1168 по акси, с примерами исходного кода разных мастеров и слейвов. затем копи-паст) 

 

не знаю как понятней объяснить :). 1 - РРЭДИ на выходе корки не реагирует на изменение РРЭДИ на ее входе. И на скрине это видно - на мастере он вздергивается в 1 только на момент чтения,  слэйву же выходит все время единица. За исключением непонятного перепада в ноль при первом обращении... 2 - залипает, скорее всего,  арбитр адресов. Потому как не происходит переключения канала на другого слэйва. Карта, кусок ТБ и результат ниже

 

    //=========================================================
    //0号主机写任务
    task task_m0_w(input [31:0] addr_start);
    begin
        addr_start_0 = addr_start;
        en_w_0       = '1;
        #PERIOD;
        en_w_0       = '0;
        #400;
    end
    endtask

    //=========================================================
    //0еЏ·дё»жњєиЇ»д»»еЉЎ
    task task_m0_r(input [31:0] addr_start);
    begin
        addr_start_0 = addr_start;
        en_r_0       = '1;
        #PERIOD;
        en_r_0       = '0;
        #400;
    end
    endtask
      
      
...........................................
      
    initial begin
        //复位&初始化
        task_init;
     
        #200;
        task_m0_w(32'h0800_0011);
        task_m0_r(32'h0800_0011);       
 
       
        #200;
        task_m0_w(32'h0800_0011);
        task_m0_r(32'h0800_0011); 
        

        #200;
        task_m0_w(32'h1000_0011);
        task_m0_r(32'h1000_0011); 
                       
        #400;
        $stop;
    end

 

 

 

механизм отлова ошибок генерится автоматом, если в системе более одного мастер интерфейса (слэйва) и явно не указано обратное ( C_RANGE_CHECK принудительно не установлен в 0).

к тому же где то в глубинах корки:

 

    assign mi_awvalid = aa_mi_awtarget_hot & {C_NUM_MASTER_SLOTS+1{mi_awvalid_en}};
    assign mi_awready_mux = |(aa_mi_awtarget_hot & mi_awready);
    assign M_AXI_AWVALID = mi_awvalid[0+:C_NUM_MASTER_SLOTS];  // Slot C_NUM_MASTER_SLOTS+1 is the error handler
    assign mi_awready[0+:C_NUM_MASTER_SLOTS] = M_AXI_AWREADY;
    assign sa_wm_awvalid = aa_mi_awtarget_hot & {C_NUM_MASTER_SLOTS+1{sa_wm_awvalid_en}};
    assign sa_wm_awready_mux = |(aa_mi_awtarget_hot & sa_wm_awready);

 

------------------------------------------------------------------------------------------------------------

 

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

 

[des00 25]

35 minutes ago, GAYVER said:

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

Хотя бы писать англоязычные термины на родном языке, а не в транслите. RREADY может зависеть от RVALID, но не обязательно.

Quote

The master interface uses the RREADY signal to indicate that it accepts the data. The default state of RREADY can be HIGH, but only if the master is able to accept read data immediately, whenever it starts a read transaction.

У вас же мастера подключаются к слейв портам интерконнекта, а слейвы к мастер портам. Внутри там вполне возможен один регистр для перетактирования, запись в него, со стороны слейва может быть всегда, а вот потом, при неготовности мастера, он должен упасть. Такой ситуации у вас, в модельном окружении не видно, но зато паузу, когда интереконнект через слейв порт выдает данные на чтение в мастер видно, также как и мастер порт интерконекта тормозит чтение, роняя RREADY. Похоже на классическую реализацию на 1-2 регистрах.

Quote

2 - залипает, скорее всего,  арбитр адресов. Потому как не происходит переключения канала на другого слэйва. Карта, кусок ТБ и результат ниже

Это давно уже выяснилось бы, эту корку использует много кто. Скорее не корректное использование, в частности ваши функции тестебнча, вызывают у меня сомнение к корректности описания. 

На BRESP нет кода SLVERR, поэтому, адрес корректен и ушел в систему на декодирование, а вот почему такой залип, надо смотреть глубже что происходит, может у вас там не round-robin, а какой-нибудь квитируемый арбитр. Или интерконнект занят каким-нибудь каналом, не завершив или не корректно завершив транзакцию. Нужно брать документацию, стандарт на акси и изучать что вы там сделали в тестбенче

ЗЫ. Посмотрел ваши картинки внимательнее, почему на них BRESP не в OKAY, состоянии, а в неопределенном?

[GAYVER 2]

59 минут назад, des00 сказал:

Это давно уже выяснилось бы, эту корку использует много кто. Скорее не корректное использование, в частности ваши функции тестебнча, вызывают у меня сомнение к корректности описания. 

На BRESP нет кода SLVERR, поэтому, адрес корректен и ушел в систему на декодирование, а вот почему такой залип, надо смотреть глубже что происходит, может у вас там не round-robin, а какой-нибудь квитируемый арбитр. Или интерконнект занят каким-нибудь каналом, не завершив или не корректно завершив транзакцию. Нужно брать документацию, стандарт на акси и изучать что вы там сделали в тестбенче

ЗЫ. Посмотрел ваши картинки внимательнее, почему на них BRESP не в OKAY, состоянии, а в неопределенном?

Слэйвы не отвечают по BRESP.  его дергает только интерконнект при ошибке адресации.

 

Система действительно не полный round-robin. Второй мастер с приоритетом 1, первый с нулевым (участвующем в round-robin). Но обращение везде идет от первого мастера. Второй никак не задействован. Транзакции, по идее, завершаются корректно - несколько подряд к одному слэйву вполне себе проходят. Причем чтение-запись - что записали, то и проверочно вычитали

 

 

59 минут назад, des00 сказал:

У вас же мастера подключаются к слейв портам интерконнекта, а слейвы к мастер портам. Внутри там вполне возможен один регистр для перетактирования, запись в него, со стороны слейва может быть всегда, а вот потом, при неготовности мастера, он должен упасть. Такой ситуации у вас, в модельном окружении не видно, но зато паузу, когда интереконнект через слейв порт выдает данные на чтение в мастер видно, также как и мастер порт интерконекта тормозит чтение, роняя RREADY. Похоже на классическую реализацию на 1-2 регистрах.

надо будет действительно попробовать убрать готовность на мастере во время чтения

[warrior-2001 0]

1 час назад, GAYVER сказал:

Слэйвы не отвечают по BRESP.

Так повесьте там всегда валидность и okay. На модели неопределённость может быть причиной "залипания"!

Изменено 14 мая, 2020 пользователем warrior-2001
очепятался

[des00 25]

6 hours ago, GAYVER said:

Слэйвы не отвечают по BRESP.  его дергает только интерконнект при ошибке адресации.

Это что-то новое, у слейва должен быть этот канал. Он входит в качестве обязательного канала шины и возвращает OKAY, EXOKAY, SLVERR, DECERR ошибки. Если такой логики в слейве нет, то он должен вернуть OKAY и поставить BVALID в единицу, как @warrior-2001 написал.

Спецификация акси не разделяет порты мастер/слейв интерконнекта и мастер/слейв модули. Она оговаривает как должен работать интерфейс мастер-слейв. Нарушаете спецификацию или видите ее не так, как она описана - будут проблемы). Покурите ее внимательнее, хотя бы разделы A/B)

[GAYVER 2]

В 14.05.2020 в 19:11, des00 сказал:

Это что-то новое, у слейва должен быть этот канал. Он входит в качестве обязательного канала шины и возвращает OKAY, EXOKAY, SLVERR, DECERR ошибки. Если такой логики в слейве нет, то он должен вернуть OKAY и поставить BVALID в единицу, как @warrior-2001 написал.

Спецификация акси не разделяет порты мастер/слейв интерконнекта и мастер/слейв модули. Она оговаривает как должен работать интерфейс мастер-слейв. Нарушаете спецификацию или видите ее не так, как она описана - будут проблемы). Покурите ее внимательнее, хотя бы разделы A/B)

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

 

Спецификация разделяет мастер/слэйв интерфейсы. Хилинх дает определения мастер/слэйв интрфейсам интерконнекта, мастер/слэйв слотам, итд

 

[RobFPGA 27]

Приветствую!

22 minutes ago, GAYVER said:

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

Прикольная  позиция -  раз мне не нужно то должно работать и так. То что у вас там что то не обрабатывается это ваши же и проблемы. Интерконнект является slave (правильным)  для вашего мастера  и соответственно мастером(тоже правильным) для ваших слейвов. 

По протоколу AXI транзакция записи оканчивается только по получению  статуса по шине BRESP.   Пока  интерконнект не увидел окончание транзакции он (в зависимости от настроек и параметров) может и не переключатся на обработку других транзакций. 

Ну и вообще  - посылать на X.. вход  незнакомого модуля  при симуляции неэтично и опасно  - можно нарваться на грубый ответ 

Удачи! Rob.

[GAYVER 2]

25 минут назад, RobFPGA сказал:

Ну и вообще  - посылать на X.. вход  незнакомого модуля  при симуляции неэтично и опасно  - можно нарваться на грубый ответ 

Поэтому при соединении интерконнекта и мастеров-слэйвов, соответствующие входы/выходы этого канала были заземлены. Неопределенку рожает сам интерконнект.  От транзакции к транзакции в пределах одного слэйва, при этом, он переходит. Влиять на арбитраж, повторюсь, BRESP не должен был. И пока меня эта неопределенка не касалась, и все функционировало как и должно было - я в нее не влазил :). Сейчас буду ковырять - кто ее там делает...

 

зы

таки да, тупанул - надо было сразу делать все как надо, а не постепенно наращивая функционал, по мере отладки предыдущего

 

ззы

еще было замечено интересное в связке интерконнект/конвертер протокола акси лайт (хилинховые корки). В качестве слэйва для интерконнекта выступает конвертер, за которым стоит конЕчный слэйв. В последней передаче по чтению, конвертер выставляет сначала RLAST, и на следующем такте данные и RVALID. А интерконнект заканчивает передачу увидев RLAST. И то ли интерконнект не ловит связку RLAST=1 && RVALID=1, то ли конвертер не одновременно их выставляет... Кто некорректно работает - не понятно. В спецификации не вспомню явных требований на этот счет

[warrior-2001 0]

В 15.05.2020 в 21:15, GAYVER сказал:

В спецификации не вспомню явных требований на этот сче

А они есть!

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

[GAYVER 2]

В 18.05.2020 в 09:50, warrior-2001 сказал:

А они есть!

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

1 - в каком конкретно разделе обозначена связь RLAST-RVALID-RREADY? конкретно по тактам - "этот сигнал может выставляться раньше/позже этого сигнала" или "должны выставляться одновременно", итд. я не нашел.

2 - оба модуля - ИП ядра хилинха, что исключает какую-либо МОЮ вольную трактовку

 

[warrior-2001 0]

16 часов назад, GAYVER сказал:

1 - в каком конкретно разделе обозначена связь RLAST-RVALID-RREADY? конкретно по тактам - "этот сигнал может выставляться раньше/позже этого сигнала" или "должны выставляться одновременно", итд. я не нашел.

A3.3.1 Dependencies between channel handshake signals

Write transaction dependencies