Привет Всем!
Собираю систему в qsys, состоящую из контроллера памяти DDR и двух моих модулей, которые являются мастерами Аvalon-ММ, которые должны независимо друг от друга обращаться к ДДР.
Если по отдельности каждый модуль работает с ДДР нормально, то при сподключении к ДДР двух модуляй, оба или перестают работать или работают с ошибками.
Как подключать к одному слейву несколько мастеров?
Полная версия этой страницы: QSYS
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
ваши модули должны поддерживать арбитраж, чтобы не было конфликтов
Цитата(vadimuzzz @ Mar 1 2013, 13:59) 
ваши модули должны поддерживать арбитраж, чтобы не было конфликтов
Как это сделать? Где почитать?
Цитата(Styv @ Mar 1 2013, 17:37)
Как это сделать? Где почитать?
спеки на шину:
http://www.altera.com/literature/manual/mnl_avalon_spec.pdf
см. в сторону waitrequest, коллизии через него разруливаются. контроль валидности адресов тоже за вашими модулями.
Цитата(vadimuzzz @ Mar 1 2013, 15:22)
спеки на шину:
http://www.altera.com/literature/manual/mnl_avalon_spec.pdf
см. в сторону waitrequest, коллизии через него разруливаются. контроль валидности адресов тоже за вашими модулями.
http://www.altera.com/literature/manual/mnl_avalon_spec.pdf
см. в сторону waitrequest, коллизии через него разруливаются. контроль валидности адресов тоже за вашими модулями.
Можно использовать Mutex.
По сути это флаг занятость общего ресурса. каждый мастер смотрит по нему свободность ресурса и если ресурс свободен то лезет в него предварительно выставив флаг на занято. Второй мастер наткнувшись на занято должен ждать пока ресурс не освободится. Не смотрите на то, что эта фича для ниоса. Её можно использовать с тем же успехом и без ниоса.
интересно конечно. Но из даташита непонятно как пользоваться этим mutex. Есть опыт?
а что за ошибки такие? Вообще, если чтение/запись бурстами, то арбитраж самому делать не надо, надо только учесть waitrequest.
Цитата
Если по отдельности каждый модуль работает с ДДР нормально, то при сподключении к ДДР двух модуляй, оба или перестают работать или работают с ошибками.
а что за ошибки такие? Вообще, если чтение/запись бурстами, то арбитраж самому делать не надо, надо только учесть waitrequest.
Ещё есть такая штука как "multi-port front end"
http://www.altera.com/literature/an/an637....front%20end%20(
http://www.altera.com/literature/an/an637....front%20end%20(
Цитата(torik @ Mar 7 2013, 15:31)
интересно конечно. Но из даташита непонятно как пользоваться этим 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 );
/* 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;
}
{
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"
Цитата
Ещё есть такая штука как "multi-port front end"
Да, интересная штуковина.
Но все-таки вопрос - разве шина авалон не занимается арбитражом самостоятельно, когда к ней бурстами обращаешься?
Все ведь нормально работает без всяких дополнительных компонентов.
Цитата(torik @ Mar 11 2013, 10:06)
Да, интересная штуковина.
Но все-таки вопрос - разве шина авалон не занимается арбитражом самостоятельно, когда к ней бурстами обращаешься?
Все ведь нормально работает без всяких дополнительных компонентов.
Но все-таки вопрос - разве шина авалон не занимается арбитражом самостоятельно, когда к ней бурстами обращаешься?
Все ведь нормально работает без всяких дополнительных компонентов.
Да, стандартных средств хватает до тех пор пока адресные пространства не начинают пересекаться. я делал псевдодвухпортовую память. один мастер только писал , другой только читал. Дак вот, без мютекса система отказалась работать. никакие таймауты между операциями не давали результата. обмена не было вообще, даже неправильного. Поставил Mutex и наступило сразу же счастье. никаких сбоев, все работает как часы.
сделайте нормальный тестбенч с BFM, тогда и вылезут все баги, из-за которых multi-master автоматом не получается.
Цитата
сделайте нормальный тестбенч с BFM, тогда и вылезут все баги, из-за которых multi-master автоматом не получается.
Это надо пробовать. А где есть примеры?
Вернемся к mutex:
- допустим, есть три мастера (один пишет видео и два читают)
- у mutex только один слейв, все три мастера на него подключать? У mutex даже нет сигнала waitrequest, что получится когда одновременно два или три мастера инициируют запись в него (или чтение)
- нужно в каждом мастере делать автомат состояния, который при необходимости совершить транзакцию будет постоянно пытаться писать/читать mutex? Тогда представим что хотя бы два мастера пытаются это делать одновременно, где гарантия что не будет ситуации когда только один мастер (самый большой поток) будет все время захватывать mutex, не давая остальным шину?
Цитата(torik @ Mar 13 2013, 09:25)
Это надо пробовать. А где есть примеры?
Вернемся к mutex:
- допустим, есть три мастера (один пишет видео и два читают)
- у mutex только один слейв, все три мастера на него подключать? У mutex даже нет сигнала waitrequest, что получится когда одновременно два или три мастера инициируют запись в него (или чтение)
- нужно в каждом мастере делать автомат состояния, который при необходимости совершить транзакцию будет постоянно пытаться писать/читать mutex? Тогда представим что хотя бы два мастера пытаются это делать одновременно, где гарантия что не будет ситуации когда только один мастер (самый большой поток) будет все время захватывать mutex, не давая остальным шину?
Вернемся к mutex:
- допустим, есть три мастера (один пишет видео и два читают)
- у mutex только один слейв, все три мастера на него подключать? У mutex даже нет сигнала waitrequest, что получится когда одновременно два или три мастера инициируют запись в него (или чтение)
- нужно в каждом мастере делать автомат состояния, который при необходимости совершить транзакцию будет постоянно пытаться писать/читать mutex? Тогда представим что хотя бы два мастера пытаются это делать одновременно, где гарантия что не будет ситуации когда только один мастер (самый большой поток) будет все время захватывать mutex, не давая остальным шину?
у регистра mutex правило "кто первый, тот и папа". При захвате шины мастер должен проверить, что именно его данные записались в регистр mutex. все остальные - неудачники =)
Если интервалы между обращениями правильные, то каждый мастер успеет слазить с память. А если все трое лопатят постоянно не оставляя времени на работу других, то никаким образом не удастся наладить обмен.
Цитата(torik @ Mar 13 2013, 08:25)
..А где есть примеры?
AlteraWiki: Simulating Designs with Lower-Level Qsys Systems
AN351: Simulating Nios II Embedded Processor Designs
(Ошибка 504)
Цитата(Styv @ Mar 1 2013, 15:31)
Собираю систему в qsys, состоящую из контроллера памяти DDR и двух моих модулей, которые являются мастерами Аvalon-ММ, которые должны независимо друг от друга обращаться к ДДР.
Если по отдельности каждый модуль работает с ДДР нормально, то при сподключении к ДДР двух модуляй, оба или перестают работать или работают с ошибками.
Если по отдельности каждый модуль работает с ДДР нормально, то при сподключении к ДДР двух модуляй, оба или перестают работать или работают с ошибками.
Я собрал такую систему. Контроллер ддр и два моих Avalon-MM которые независимо работают с ддр, т.е. DMA. Работает, ошибок не наблюдаю. Ни каких мютексов не пользую. Арбитраж сама шина авалон разруливает. Естественно использую сигнал waitrequest на шине.
Цитата
Как подключать к одному слейву несколько мастеров?
я использовал сигналы шины
Код
master_address,
master_readdata,
master_writedata,
master_cs,
master_waitrequest,
master_byteenable,
master_write,
master_read,
master_readdata,
master_writedata,
master_cs,
master_waitrequest,
master_byteenable,
master_write,
master_read,
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.