[Styv 0]

Привет Всем!

 

Собираю систему в qsys, состоящую из контроллера памяти DDR и двух моих модулей, которые являются мастерами Аvalon-ММ, которые должны независимо друг от друга обращаться к ДДР.

 

Если по отдельности каждый модуль работает с ДДР нормально, то при сподключении к ДДР двух модуляй, оба или перестают работать или работают с ошибками.

 

Как подключать к одному слейву несколько мастеров?

 

[vadimuzzz 0]

ваши модули должны поддерживать арбитраж, чтобы не было конфликтов

[Styv 0]

ваши модули должны поддерживать арбитраж, чтобы не было конфликтов

 

Как это сделать? Где почитать?

[vadimuzzz 0]

Как это сделать? Где почитать?

спеки на шину:

http://www.altera.com/literature/manual/mnl_avalon_spec.pdf

см. в сторону waitrequest, коллизии через него разруливаются. контроль валидности адресов тоже за вашими модулями.

[wpost 0]

спеки на шину:

http://www.altera.com/literature/manual/mnl_avalon_spec.pdf

см. в сторону waitrequest, коллизии через него разруливаются. контроль валидности адресов тоже за вашими модулями.

 

Можно использовать Mutex.

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

Изменено 1 марта, 2013 пользователем wpost

[torik 0]

интересно конечно. Но из даташита непонятно как пользоваться этим mutex. Есть опыт?

 

Если по отдельности каждый модуль работает с ДДР нормально, то при сподключении к ДДР двух модуляй, оба или перестают работать или работают с ошибками.

а что за ошибки такие? Вообще, если чтение/запись бурстами, то арбитраж самому делать не надо, надо только учесть waitrequest.

[ISK 0]

Ещё есть такая штука как "multi-port front end"

 

http://www.altera.com/literature/an/an637....front%20end%20(

[wpost 0]

интересно конечно. Но из даташита непонятно как пользоваться этим mutex. Есть опыт?

 

да, опыт есть. там все просто.

Если из ниоса, то вообще все просто...

#include <altera_avalon_mutex.h>
/* get the mutex device handle */
alt_mutex_dev* mutex = altera_avalon_mutex_open( ”/dev/mutex” );
/* acquire the mutex, setting the value to one */
altera_avalon_mutex_lock( mutex, 1 );
/*
* Access a shared resource here.
* Здесь защищенный код. можно пользоваться общим ресурсом.
*/
/* release the lock */
altera_avalon_mutex_unlock( mutex );

Естественно, любое обращение любого мастера к общему ресурсу нужно заключать между altera_avalon_mutex_lock и altera_avalon_mutex_unlock( mutex ). Значение 1 взято просто для примера.

 

Если без ниоса, то примерно так:

 

захват шины происходит путем записи в регистр mutex двух идентификаторов: OWNER - номер процессора (CPU ID), и VALUE - идентификатор процесса, который хочет занять устройство (любое число не 0)

после чего проверяется факт удачного захвата (вдруг нас опередили)

 

static int alt_mutex_trylock( alt_mutex_dev* dev, alt_u32 value )
{
  alt_u32 id, data, check;
  int ret_code = -1;

  NIOS2_READ_CPUID(id);

  /* the data we want the mutex to hold */
  data = (id << ALTERA_AVALON_MUTEX_MUTEX_OWNER_OFST) | value;

  /* attempt to write to the mutex */
  IOWR_ALTERA_AVALON_MUTEX_MUTEX(dev->mutex_base, data);
  
  check = IORD_ALTERA_AVALON_MUTEX_MUTEX(dev->mutex_base);

  if ( check == data)
  {
    ret_code = 0;
  }

  return ret_code;
}

 

Проверка что устройство свободно заключается в прочтении регистра mutex. Если VALUE = 0 то путь свободен, можно лезть.

 

чтобы освободить устройство нужно записать 1 в регистр reset.

 

в первом приближении это все. подробнее посмотрите в папке "с:\altera\11.0\ip\altera\sopc_builder_ip\altera_avalon_mutex\HAL\src"

Изменено 9 марта, 2013 пользователем wpost

[torik 0]

Ещё есть такая штука как "multi-port front end"

 

Да, интересная штуковина.

Но все-таки вопрос - разве шина авалон не занимается арбитражом самостоятельно, когда к ней бурстами обращаешься?

Все ведь нормально работает без всяких дополнительных компонентов.

[wpost 0]

Да, интересная штуковина.

Но все-таки вопрос - разве шина авалон не занимается арбитражом самостоятельно, когда к ней бурстами обращаешься?

Все ведь нормально работает без всяких дополнительных компонентов.

 

Да, стандартных средств хватает до тех пор пока адресные пространства не начинают пересекаться. я делал псевдодвухпортовую память. один мастер только писал , другой только читал. Дак вот, без мютекса система отказалась работать. никакие таймауты между операциями не давали результата. обмена не было вообще, даже неправильного. Поставил Mutex и наступило сразу же счастье. никаких сбоев, все работает как часы.

[krux 8]

сделайте нормальный тестбенч с BFM, тогда и вылезут все баги, из-за которых multi-master автоматом не получается.

[torik 0]

сделайте нормальный тестбенч с BFM, тогда и вылезут все баги, из-за которых multi-master автоматом не получается.

Это надо пробовать. А где есть примеры?

 

Вернемся к mutex:

- допустим, есть три мастера (один пишет видео и два читают)

- у mutex только один слейв, все три мастера на него подключать? У mutex даже нет сигнала waitrequest, что получится когда одновременно два или три мастера инициируют запись в него (или чтение)

- нужно в каждом мастере делать автомат состояния, который при необходимости совершить транзакцию будет постоянно пытаться писать/читать mutex? Тогда представим что хотя бы два мастера пытаются это делать одновременно, где гарантия что не будет ситуации когда только один мастер (самый большой поток) будет все время захватывать mutex, не давая остальным шину?

[wpost 0]

Это надо пробовать. А где есть примеры?

 

Вернемся к mutex:

- допустим, есть три мастера (один пишет видео и два читают)

- у mutex только один слейв, все три мастера на него подключать? У mutex даже нет сигнала waitrequest, что получится когда одновременно два или три мастера инициируют запись в него (или чтение)

- нужно в каждом мастере делать автомат состояния, который при необходимости совершить транзакцию будет постоянно пытаться писать/читать mutex? Тогда представим что хотя бы два мастера пытаются это делать одновременно, где гарантия что не будет ситуации когда только один мастер (самый большой поток) будет все время захватывать mutex, не давая остальным шину?

 

у регистра mutex правило "кто первый, тот и папа". При захвате шины мастер должен проверить, что именно его данные записались в регистр mutex. все остальные - неудачники =)

Если интервалы между обращениями правильные, то каждый мастер успеет слазить с память. А если все трое лопатят постоянно не оставляя времени на работу других, то никаким образом не удастся наладить обмен.

[Kuzmi4 0]

..А где есть примеры?

AlteraWiki: Simulating Designs with Lower-Level Qsys Systems

AN351: Simulating Nios II Embedded Processor Designs

[Kuzmi4 0]

(Ошибка 504)