Поясню.
По езернету принимаем данные об состоянии 1000 ОДИНАКОВЫХ распределенных устройств на скорости 10 Гбит/с по оптоволокну, обрабатываем и формируем "ответку". Которую тоже передаем по оптоволоку на 10Гбит/с
Т.к. устройства одинаковые, то алгоритм работы и логика обработки дампа от каждого устройства одинакова.

Отсюда возникает желание обрабатывать все дампы ПАРАЛЛЕЛЬНО.

Отсюда в голове появляется слово "ПЛИС".

Но возникает вопрос "Как?"

Я вижу это так. Есть память. Допустим 1 Мегабайт.
В эту память пишем принятые дампы из принятых пакетов, из неё же грузим данные в пакеты.
Тут пока ничего не обычного.

Необычное начинается тут:
Память должна быть разбита на 1000 сегментов и доступ к каждому сегменту должен быть возможен НЕЗАВИСИМО от других
ПЛИСина должна читать из 1000 дампов/сегментов ОДНОВРЕМЕННО и обрабатывать 1000 потоков параллельно и потом формированные данные 1000 потоков параллельно: каждый узел обработки пишет, читает собрабатывает свой дамп.

Пруфит? Увеличение скорости реакции в 1000 раз по сравнению с последовательной обработкой на MCU


Я объяснил несколько шероховато, поскольку не специалист по ПЛИС.

Меня интересует это реализуемо на ПЛИС.
И есть ли такая память, которая позволяет использовать её одновременно как единый блок и как совокупность дампов с независимым доступом к каждому дампу?

Т.е. при сериализации/десериализации память используется как неделимый блок.
А при обработке данных в памяти она должна использоваться ПЛИСиной как набор из 1000 независимых дампов с независимым доступом.

Такое есть в природе?

Или описанные мной задачи решаются как-то иначе?

Просто обычный MCU даже i7 не успеет обработать поток 10Гбит/сек (а есть мысли сделать даже 100Гб/с).
Нужно как-то распараллеливать обработку

А как?

Сообщение отредактировал Студент заборстроительного - Dec 23 2017, 11:07

https://www.amazon.com/Computer-Architectur...y/dp/012383872X

Скажите своими словами: на какой элементной базе решают такие задачи: сериазизация/десериализация потока 10Гбит/с из памяти и чтение/запись из памяти в 1000 потоков параллельно

Берёте ПЛИС Xilinx у которой количество BRAM > 1000 (Kintex7, Vertex7...) и организовываете на ней двухпортовую память.


Может память вообще не нужна? В ПЛИС же не только 1000 ОЗУ можно сделать, но и 1000 АЛУ.
Зачем складывать в память и асинхронно обрабатывать, когда пакет можно сразу отправлять на обработку соответствующему АЛУ синхронно?

Спасибо. Но не очень понятно. Я нуб в ПЛИСах.
Я понял только что мою задачу можно реализовать на ПЛИС. Так?


Не знаю. Я нуб в ПЛИС.
А если память не нужна, то где будет формироваться пакет для отправки по 10G эзернету?
И как будет выполняться сериализация/десереализация?

Сообщение отредактировал Студент заборстроительного - Dec 23 2017, 12:14

Нет.
Своими словами: "Эта задача не для вас. Пойдите и получите немного образования".

Скажите хотя бы это реализуемо на ПЛИС так как я описал?
Прием потока данных по 10G эзернету и его парсинг в 1000 потоков с помощью ПЛИС?


Естественно. Мы наймём ПЛИСовода со стороны. Мне нужно просто ТЗ написать.
Вот и выясняю: реализуемо это или нет: чтобы 1000 узлов ПЛИС читали данные из памяти параллельно, в 1000 потоков, а приемопередатчик, чтобы читал последовательно. Все подряд. Не замечая границ дампов

Неужели, Студент_ и Arjun, это одно и то же лицо?

Какая печаль!..

То что Вы описали легко реализует специалист среднего уровня. ПЛИС для того и созданы чтобы
создавать десятки, сотни и тысячи независимых узлов, которые работают параллельно.
С доступом памяти тоже самое, не проблема сделать двух, трех... сто портовую память.

Полагаю если Вы пишете ТЗ, Вам надо просто написать что Вы хотите, и пускай ПЛИСовод
сам решает каким образом это реализовать.
И не заморачивайтесь над вопросами реализуемости. Тоже самое ПЛИСовод сам подберет
элементную базу под проект, это его прямая задача.

Отлично.


Я слышал об этом. Поэтому и пришло в голову "ПЛИС" когда размышлял о реализации задачи


Вот "память" у меня больше всего сомнений вызывает.
Про двухпортовую память я слышал. А про N-портовую - нет.
Вы мне скажите. Это реально?
Чтобы 1000 схемных узлов ОДНОВРЕМЕННО (ПАРАЛЛЕЛЬНО) считывали данные из памяти. Причем из РАЗНЫХ дампов
Я просто хочу понять, как это выглядит ФИЗИЧЕСКИ: из одной микросхемы памяти торчат 1000 штук 20 битных шин адреса? Ведь получается 20000 контактов?



Я "заморачиваюсь", чтобы не попасть впросак. Не написать ТЗ такое, что его будет невозможно реализовать даже на самой современной элементной базе.

Но раз Вы говорите, что ничего сверх естественного в этой задаче нет. Все вполне реализуемо. И с проектом справится даже "середнячок" по ПЛИС, то тогда вопрос закрыт.
Спасибо за помощь.

Сообщение отредактировал Студент заборстроительного - Dec 23 2017, 21:45

У товарища реально раздвоение личности. Строчит под разными никами.
А может где и спорит сам с собой?

если потери не сильно критичны, то даже DPDK с 10 Гбитами справится, без необходимости изучения ПЛИС.

Как любят все ставить диагнозы. У меня параллельно не менее 3 ников, и вы не поверите сколько ников я тут уложил на форуме в борьбе
за свободу ежиков. Не менее двух десятков точно. И большая часть из них "свои".


Если объем памяти небольшой, то делается "в лоб" на внутренней памяти ПЛИС.
В Вашем случае это 1000 блоков двухпортовой памяти.

Если объем памяти большой, то создается куча FIFO и блок обмена с внешней DDR3,4 памятью.
Ну да 1000 блоков FIFO будут иметь "тысячи проводов" к блоку обмена с внешней памятью.

при проектировании в ПЛИС, нужно знать "сколько вешать в граммах", т.е. считать биты и такты.
ваша проблема в том, что вы рисуете 1000 одновременных обработчиков, без четкого понимания в их необходимости.
может, будет достаточно одного? или десяти? или ста? почему 1000? как считали и чем обосновываете необходимость?
далее про память. в ПЛИС не надо ничего хранить, нужно всё обрабатывать "на лету". если по алгоритму обрабатывать "на лету" невозможно, и рисуется необходимость хранить - нужна внешняя память.
и опять нужно считать биты и такты, поскольку доступ в память - всегда "бутылочное горлышко" с точки зрения пропускной способности.

для начала, посчитайте, сколько пакетов в секунду вам нужно обрабатывать. какой минимальный и максимальный размер пакета.
у вас в ПЛИС будет множество обрабатывающих блоков. прикиньте, какой разрядности будут их входные и выходные шины данных, и на какой частоте вы сможете работать.
опять пересчитайте биты и такты, и проверьте что вы обеспечиваете нужную производительность для минимального и максимального размера пакета. проверьте есть ли запас.

ну а дальше приходите сюда уже с выкладками и может, со схемой обрабатывающих блоков, тогда будут более конкретные советы.

про 1000-портовую память забудьте, так никто не делает. можно конечно сделать "для галочки" просто из прихоти что "так захотелось", но работать это будет с очень низкой тактовой, которая вас сразу не устроит по производительности.

для максимальной производительности, пакет в ПЛИС формируется не в памяти, а "на лету".
например. с АЦП есть поток данных.
он нарезается по 1024 байта, перекладывается на 32-битную шину данных, т.е. пакет "длится" 256 тактов. это блок формирования данных.
далее данные с этого блока потоком поступают на блок "дописывания к пакету заголовка".
Блок "дописывания к пакету заголовка" формирует в свою выходную шину N штук тактов с данными заголовка, после чего прозрачно передает данные со своего входа на выход (данные АЦП).
далее этот поток передается в блок ethernet MAC
ethernet MAC потоком передает данные наружу, дописывая впереди перед пакетом start sequence, выдавая биты пакета в линию наружу, вычисляя "на лету" FCS, и выдавая биты FCS в конце кадра ethernet.
и заметьте, ничего нигде специально в некоей "памяти" не хранится.
а как же дописываемый заголовок UDP/IP? так он на половину из констант, которые интегрируются в конечный автомат, а вторая половина хранится в регистрах, которые настраиваются при запуске системы.

Поддержу krux'а
подходить нужно более системно, посчитать потоки данных и пропускную способность критических узлов системы.
Паралеллить то на ПЛИС можно и это хорошо получается, но может так оказаться, что все выходные данные нужно
пропихнуть через бутылочное горлышко, что приведет к необходимости буферизации данных, выходному арбитражу и т.д.
А в итоге общая пропускная способность системы окажется такой же как и при последовательной обработке данных, но
но усилий разработчика и ресурсов ПЛИС будет потрачено много больше.