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

Ответить

novartis 0

21 марта, 2017

Опубликовано 21 марта, 2017 · Жалоба

Есть поток данных 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 0

21 марта, 2017

Опубликовано 21 марта, 2017 · Жалоба

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

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

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

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

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

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

iosifk 3

21 марта, 2017

Опубликовано 21 марта, 2017 · Жалоба

Есть поток данных 32 бит шириной. Данные в нем передаются по специфическому протоколу.
Поток характеризуется тремя наборами бит:

State - лежит в диапазоне от 1 до 20. Выделил 5 бит на этот сигнал.

Switch - четыре бита, возможны все варианты от 0 до 15

Skip - 15 бит. Если младший бит единица, то все остальные тоже единицы. Если второй бит - единица, то с 3 по 15 бит - тоже единицы. И так далее. Такая треугольная матрица получается.

На каждом такте из входного потока я вытаскиваю Switch (это старшие биты байт).

Еще если State = 1, то я переопределяю вектор Skip на основе принятого слова из потока данных.

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

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

Не вдаваясь в Ваши тонкости...

Представим, что принимаем Ethernet. И там есть 6 байт адреса, если я не ошибаюсь... Давно дело было... :)

Так вот, можно принять данные в регистр, потом сделать на эти 6 байт схему сравнения... И угробить немеряно ресурсов и быстродействия.

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

Ну а в Вашем случае можно сделать несколько сдвиговых регистров, которые в темпе приема продешифрируют ситуацию...

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

RobFPGA 27

21 марта, 2017

Опубликовано 21 марта, 2017 · Жалоба

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

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

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

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

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

В лоб это - BRAM на 8К x 9 bit . Но не факт что самое быстрое.

При one-hot кодировании может и на логике быстрее будет.

Основные задержки тут скорее всего в FindFirstOne(Skip)

Удачи! Rob.

Цитата

Поделиться сообщением

Ссылка на сообщение

Поделиться на другие сайты

novartis 0

21 марта, 2017

Опубликовано 21 марта, 2017 · Жалоба

автомат всего с 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. Все равно придется стать героем.