Есть несколько тысяч однобитных сигналов. В каждом цикле любое их количество может быть активным. Надо последовательно перебрать все входы, и при "1" на входе, на выходе надо подать номер входящего сигнала и строб DATARDY. И так пока все активные сигналы не будут переданы. После чего выставляем строб готовности, защелкиваем новое состояние входов и повторяем процесс. Такой себе демультиплексер, только с поддержкой множественных активных сигналов.
Ситуация осложняется тем, что в среднем активных сигналов будет меньше 10% от общего количества. Поэтому было бы хорошо сократить число циклов, необходимых для просмотра всех входов.
Мои идеи:

- Машиной состояний пройтись в цикле по всем входам. Никакой оптимизации, количество циклов всегда постоянно и не зависит от входов.

- при помощи конструктива for i in 0 to n_inputs loop пройтись только по активным входам. К сожалению, я сомневаюсь что на несколько тысяч входных сигналов цикл сгенерирует хороший дизайн.

- При помощи OR построить что-то типа бинарного дерева поиска, перебирая только активные ветви. Ускорение перебора увеличением сложности. К тому же хорошо будет работать только на сгруппированых сигналах, имея "010101010" на входах никакого ускорения не получится.

- Спросить опытных людей, как бы они решили такую проблему. Цель синтеза Spartan 6.

Как вариант комбинация первого и второго. Сгруппировать в группы по 16 сигналов, и добавить параллельно дерево поиска. Если ни хотя б один сигнал в группе активен, его передать, если в группе все неактивные не передавать.
Далее сгруппировать по ОR группы, тогда можно отсекать по 4,8, 16 групп сразу.
Самый тяжелый случай будет когда будет активен каждый 16 сигнал по всему дизайну, придется передать все.
Плата за это, всегда разная длина цикла, плюс накладные расходы, чтобы разобраться с адресами активных битов.

А от этих 10% как часто будут "изменения состояний"?
Может быть надо передавать не сами "активные состояния", а их изменения? Возможно, при этом объем данных на передачу уменьшится?

может это поможет.... - возможное решение коммутации...
у Xilinx тоже есть аналогичные appnotes


Еще подумайте насчет использования CPLD там архитектура более подходящая для задачи... (мое мнение)

Это не отдельное устройство, а входящий кодер для нейронной сети. Сеть работает на сигналах Address-Event, и внутренние шины типа АЕ. Есть глобальный "медленный клок", который задает темп входящих данных в сеть (один образец по терминологии НС), и нормальный клок, который в несколько тысяч раз быстрее. Импульсы на входах могут измениться каждый "медленный клок" полностью. Вариант с передачей только разницы состояний не прокатит.
Как я понимаю, петля for годится только для синтеза небольших (<50) групп элементов.

Входные данные загружаются в регистр. Затем, пока не будут обработаны все сигналы, производится сдвиг и увеличение на 1 счетчика. При появлении на выходе регистра «1», выдаем значение счетчика в качестве искомого номера.

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

Огласите времянки 'медленного и быстрого' клока. И что делать, если вдруг будут активны все входные сигналы и за отведенное время их физически не удастся передать?

Есть такая память САМ - это то, что Вам возможно подойдет...

"Медленный клок" это 1/100 сек, быстрый - как позволит дизайн и плисина. Работа исследовательская, так что нету строгих рамок, но производительность важна.

Не совсем понял, как здесь можно использовать САМ.

В САМ записываются биты.
Если в САМ не 0, то читается адрес ненулевой строки.
Аналогично работают поисковые таблицы в свитчах.

При таком отношении частот вполне можно не заморачиваться и сделать как вы и описали в 1м посте, например с помощью длинного сдвигового регистра (как советовал kreakozeablik)
Производительность чего? Между 2мя 'медленными' клоками вы выкачаете все данные, а потом можете их обрабатывать хоть на 100MHz на отсчет

Вы лучше озаботьтесь как будете заводить в плисину 'несколько тысяч сигналов'. У нее банально не хватит ног

Данные поступают синхронно с "медленным клоком", а сама сеть асинхронна. Чем быстрее будет ответ на входной образец, тем лучше.

Тогда делите все входные сигналы на группы, и делайте параллельные шифраторы внутри них. Выходы сливайте попарно (или по 3/4/etc) в выходы. Их так же сливайте вместе. В результате получится дерево. Деревья смежных уровней соединяйте друг с другом через FIFO

Если есть, допустим, 100 тактов, разбиваем весь входной набор на группы по 100 бит.
Для каждой группы создаем сдвиговый регистр, счетчик и фифо.
На каждом из 100 тактов:
если крайний бит == 1, заносим значение счетчика в фифо.
увеличиваем счетчик,
сдвигаем регистр на 1 бит.

Остается только слить все фифо вместе...