Подскажите как оптимальнее (fmax) реализовать на ПЛИС Опции

[novartis]

Есть поток данных 32 бит шириной. Данные в нем передаются по специфическому протоколу.
Поток характеризуется тремя наборами бит:
State - лежит в диапазоне от 1 до 20. Выделил 5 бит на этот сигнал.
Switch - четыре бита, возможны все варианты от 0 до 15
Skip - 15 бит. Если младший бит единица, то все остальные тоже единицы. Если второй бит - единица, то с 3 по 15 бит - тоже единицы. И так далее. Такая треугольная матрица получается.

На каждом такте из входного потока я вытаскиваю Switch (это старшие биты байт).
Еще если State = 1, то я переопределяю вектор Skip на основе принятого слова из потока данных.

Итак на каждом такте мне нужно перерасчитать State.

Если делать в лоб и перебирать все возможные состояния, то у меня есть 5 + 4 = 9 бит, которые могут быть любыми, а это 512 состояний. И еще есть вектор skip, который определяет еще 15 состояний.
И того 512*15 = 7680. Это получается нужно написать 7680 ифов (if ... elsif ... elsif ... .... else ...).

За несколько дней написал половину. Скомпилил. Не прохожу по частоте. Частота достаточно высокая (300 МГц, Аррия 10), понизить ее нельзя.
Если делать дальше, то еще хуже будет.

Сейчас думаю, как это можно реализовать по другому.
Буду признателен за любые советы.



Вот смотрю я на расчет CRC32, к примеру один из битов новой crc рассчитывается так:
newcrc(0) := d(31) xor d(30) xor d(29) xor d(28) xor d(26) xor d(25) xor d(24) xor d(16) xor d(12) xor d(10) xor d(9) xor d(6) xor d(0) xor c(0) xor c(6) xor c(9) xor c(10) xor c(12) xor c(16) xor c(24) xor c(25) xor c(26) xor c(28) xor c(29) xor c(30) xor c(31);
d - это данные, c - это предыдущая crc.
И в том же духе остальные 31 бит.
Может можно как то также (мысли вслух)?

[Golikov A.]

Смысл того что вы хотите непонятен. Вы пишите так как будто все знают что должна сделать ваша схема в ваших 7680 состояниях.

А поскольку никто не знает что она должна делать, то как вам советовать?

забавно что в вашей вселенной отменили for и case, иначе не понятно зачем так много if-else...

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

Ну и из общих соображений частоту можно поднять конвейером.

[iosifk]

Есть поток данных 32 бит шириной. Данные в нем передаются по специфическому протоколу.
Поток характеризуется тремя наборами бит:
State - лежит в диапазоне от 1 до 20. Выделил 5 бит на этот сигнал.
Switch - четыре бита, возможны все варианты от 0 до 15
Skip - 15 бит. Если младший бит единица, то все остальные тоже единицы. Если второй бит - единица, то с 3 по 15 бит - тоже единицы. И так далее. Такая треугольная матрица получается.

На каждом такте из входного потока я вытаскиваю Switch (это старшие биты байт).
Еще если State = 1, то я переопределяю вектор Skip на основе принятого слова из потока данных.

Итак на каждом такте мне нужно перерасчитать State.

Может можно как то также (мысли вслух)?

Не вдаваясь в Ваши тонкости...
Представим, что принимаем Ethernet. И там есть 6 байт адреса, если я не ошибаюсь... Давно дело было...
Так вот, можно принять данные в регистр, потом сделать на эти 6 байт схему сравнения... И угробить немеряно ресурсов и быстродействия.
А можно сделать сдвиговый регистр, куда перед приемом пакета записывать адрес с которым надо сравнивать. И схема сравнения должна быть сделана на ту разрядность, какая принимается из трансивера. Бит, тетрада или байт. В темпе приема пакета данные приходят из линии и сравниваются с тем, что есть в сдвиговом регистре. Ну и он так же сдвигается на бит, тетраду или байт. И самая вишенка на торте. Это триггер адреса. Если при очередном сравнении он не сбросится и простоит до конца сравнений, то адрес совпал. Если не сравнилось, то триггер сбрасывается и пакет - не наш...
Ну а в Вашем случае можно сделать несколько сдвиговых регистров, которые в темпе приема продешифрируют ситуацию...

[RobFPGA]

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

..
И того 512*15 = 7680. Это получается нужно написать 7680 ифов (if ... elsif ... elsif ... .... else ...).

За несколько дней написал половину. ...

Бывают же герои писать >7000 if ... else

Если я правильно понял - фактически у Вас получается автомат всего с 32 состояниями (State 5 bit) и 4 + 4 входами (Switch + FindFirstOne(Skip) ) и 5+4 бит выходами (NexState, SkipOut)
В лоб это - BRAM на 8К x 9 bit . Но не факт что самое быстрое.

При one-hot кодировании может и на логике быстрее будет.
Основные задержки тут скорее всего в FindFirstOne(Skip)

Удачи! Rob.

[novartis]

автомат всего с 32 состояниями (State 5 bit) и 4 + 4 входами (Switch + FindFirstOne(Skip) )

Может я чего то не понимаю.
На каждом состоянии автомата (State 5 bit) есть сигнал с 4 + 4 входа (Switch + FindFirstOne(Skip) ).
То есть у меня 32 состояния автомата, на каждом из которых мне нужно дешифрировать сигнал с входа (8 бит). Причем дешифраторы разные, для каждого из 32 состояний свой дешифратор.
5+8 = 13 => 2**13 = 8192. Все равно придется стать героем.

[RobFPGA]

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

Может я чего то не понимаю.
...
5+8 = 13 => 2**13 = 8192. Все равно придется стать героем.

Ну если Вам так хочется - но может будет проще стать космонавтом

Все зависит от того что надо получить на выходе, от алгоритма протокола.
Ведь состояний то всего 32 значит и переходов на них столько же.
Значит надо смотреть как объединять логику на входах в зависимости протокола.
В простейшем варианте используя casex можно будет уменьшить Ваши героические достижения.

Удачи! Rob.

P.S. Кажется мне что Вы парсер для FAST ваяете

[novartis]

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

Можете привести простейший пример?

Кажется мне что Вы парсер для FAST ваяете

Ага

[Golikov A.]

Пожалуйста, пожалуйста, пожалуйста, пусть FAST будет китайским телескопом, а не этой этой высокоскоростной торговлей...

Эти товарищи любят все сделать за 1 такт, при этом совсем не считают что обычно 2 такта на частоте 500 это быстрее чем 1 такт на 150...

[Mad_max]

За несколько дней написал половину.

А завтра поменяется темплейт и будете все заново переписывать