[Maverick_ 15]

возможно это натолкнет на мысль - Ping Pong FIFO

http://cospandesign.github.io/fpga,fifo/2016/05/02/ppfifo.html  (работоспособность описания не проверял)

PS  Идея использовать плюсы двойного буфера (давблбуффер) . Для хранения данных со всех источников использовать даблбуфер. Хранить начальные адреса пакетов (вместе с длиной пакета) в отдельной памяти - можно это сделать для каждого источника отдельно. Чтобы оперативно можно производить пактное чтение с даблбуффера для каждого источника. Отдельно через регистр передавать количество пакетов записанных в даблбуффер. Сбрасывать указатели адресов памяти как только даблбуффер переключился, например.

Это просто как мысли ...

 

[Opex 0]

11 hours ago, RobFPGA said:

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

А чтобы кэш лучше работал, увеличим его глубину! Постойте...

Если серьезно, во время поиска может освободиться приемник, и тогда можно ошибочно взять элемент вне очереди. Кэш на один элемент хорошо сочетается с защитой от этого.

[des00 25]

26 minutes ago, Opex said:

Если серьезно, во время поиска может освободиться приемник, и тогда можно ошибочно взять элемент вне очереди. Кэш на один элемент хорошо сочетается с защитой от этого.

@RobFPGA тоже прав, можно пройти все FIFO и не найти свободного, а само FIFO уже перетрясено на одно слово и кеш надо будет вернуть) В случае с двумя FIFO я фиксировал флаги готовности на время поиска) Как то работало, но похоже недотестировал, т.к читаю обсуждение  и прихожу к мысли что все это не очень хорошо ложиться в систему, логичнее наверное сделать на каждый приемник небольшое FIFO на SRL элементах, которые наполняются из большого FIFO, с учетом описанного вами метода. Ну и на выходе малых FIFO по RRA арбитру на основе FIFO empty & receiver ready нагружать блок математики. receiver ready это сигнал от приемника что он готов принять блок максимального размера. 

[RobFPGA 35]

40 minutes ago, Maverick_ said:

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

Как раз множество FIFO и арбитр на стороне чтение проще некуда.  Для  данного применения, а это фактически  сортировка приходящих пакетов по разным каналам, самое простое и быстрое решение.  Но вот за неэкономное использование памяти на эти FIFO естественно жаба и душит.  
 

1 hour ago, des00 said:

можно пройти все FIFO и не найти свободного, а само FIFO уже перетрясено на одно слово и кеш надо будет вернуть

С этим можно побороться  заведя  на каждый канал  битовую  маску на глубину FIFO. Соответственно отмечая при записи соответствующий бит в канале индекс которого пишется. И перемещая/стирая когда элемент перемешается/извлекается из FIFO. Сразу будет видно какие каналы  присутствуют в FIFO и  не запускать поиск для  отсутствующих.  Заодно можно быстро находить и позицию первого элемент для каждого канала. 
Ну или просто счетчики числа элементов для каждого канала. Чтобы не запускать поиск при 0 для свободного канала. 
Тогда  вырисовывается вполне  хорошая структура - FIFO, при записи одновременно инкремент  счетчика соотв. канала. Затем блок чтения/поиска из FIFO по схеме @Opex при ненулевом счетчике и свободном месте в малом выходном FIFO на 1-32 элемента для каждого канала, и записью в оное найденных индексов и декремент канального счетчика.          

[blackfin 28]

1 hour ago, des00 said:

... логичнее наверное сделать на каждый приемник небольшое FIFO на SRL элементах, которые наполняются из большого FIFO, с учетом описанного вами метода. Ну и на выходе малых FIFO по RRA арбитру на основе FIFO empty & receiver ready нагружать блок математики.

IMHO, всё уже украдено придумано до нас:

 

 

См: PG035. Размеры всех FIFO можно выбирать редакторе.

 

Проще или экономнее вряд ли получится.

[Opex 0]

2 hours ago, des00 said:

можно пройти все FIFO и не найти свободного, а само FIFO уже перетрясено на одно слово и кеш надо будет вернуть

Ну и пусть оно все сдвинется на одно слово, не вижу тут проблемы. Лежало в памяти N слов, N и осталось, адреса только увеличились на 1 у всех.

[des00 25]

6 minutes ago, Opex said:

Ну и пусть оно все сдвинется на одно слово, не вижу тут проблемы. Лежало в памяти N слов, N и осталось, адреса только увеличились на 1 у всех.

запись со стороны порта записи идет случайно и постоянно. Там с последним словом могут быть проблемы. Нужно будет на +1 поправить адрес записи при возникновении конфликта переписывания хвоста и добавления нового хвоста. Но это решаемо)

1 hour ago, blackfin said:

IMHO, всё уже украдено придумано до нас:

Проще или экономнее вряд ли получится.

вот как раз от этого я и хочу уйти) 

[RobFPGA 35]

4 minutes ago, Opex said:

Ну и пусть оно все сдвинется на одно слово, не вижу тут проблемы. Лежало в памяти N слов, N и осталось, адреса только увеличились на 1 у всех.

Проблема  в синхронизации с  портом записи при совпадении момента обработки последнего прочитанного слова с записью нового. Надо как минимум тормозить запись нового слова  в этот момент.  Вариант со счетчиками  по каналам позволит избежать этого и вообще не запускать поиск при таком раскладе.