Jump to content

    

Принять и ПАРАЛЛЕЛЬНО распарсить поток 10Гбит/с. Как решаются такие задачи?

Поясню.

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

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

 

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

 

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

 

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

 

Я вижу это так. Есть память. Допустим 1 Мегабайт.

В эту память пишем принятые дампы из принятых пакетов, из неё же грузим данные в пакеты.

Тут пока ничего не обычного.

 

Необычное начинается тут:

Память должна быть разбита на 1000 сегментов и доступ к каждому сегменту должен быть возможен НЕЗАВИСИМО от других

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

 

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

 

 

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

 

Меня интересует это реализуемо на ПЛИС.

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

 

Т.е. при сериализации/десериализации память используется как неделимый блок.

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

 

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

 

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

 

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

Нужно как-то распараллеливать обработку

 

А как?

Edited by Студент заборстроительного

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Память должна быть разбита на 1000 сегментов и доступ к каждому сегменту должен быть возможен НЕЗАВИСИМО от других

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

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

 

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

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

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

 

 

 

Share this post


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

Спасибо. Но не очень понятно. Я нуб в ПЛИСах.

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

 

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

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

Не знаю. Я нуб в ПЛИС.

А если память не нужна, то где будет формироваться пакет для отправки по 10G эзернету?

И как будет выполняться сериализация/десереализация?

Edited by Студент заборстроительного

Share this post


Link to post
Share on other sites
Скажите своими словами

Нет.

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

Share this post


Link to post
Share on other sites
Нет.

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

Скажите хотя бы это реализуемо на ПЛИС так как я описал?

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

 

Эта задача не для вас.

Естественно. Мы наймём ПЛИСовода со стороны. Мне нужно просто ТЗ написать.

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

Share this post


Link to post
Share on other sites
Скажите хотя бы это реализуемо на ПЛИС так как я описал?

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

 

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

Share this post


Link to post
Share on other sites
Поясню...

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

создавать десятки, сотни и тысячи независимых узлов, которые работают параллельно.

С доступом памяти тоже самое, не проблема сделать двух, трех... сто портовую память.

 

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

сам решает каким образом это реализовать.

И не заморачивайтесь над вопросами реализуемости. Тоже самое ПЛИСовод сам подберет

элементную базу под проект, это его прямая задача.

 

 

Share this post


Link to post
Share on other sites
То что Вы описали легко реализует специалист среднего уровня.

Отлично. :yeah:

 

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

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

 

С доступом памяти тоже самое, не проблема сделать двух, трех... сто портовую память.

Вот "память" у меня больше всего сомнений вызывает.

Про двухпортовую память я слышал. А про N-портовую - нет.

Вы мне скажите. Это реально?

Чтобы 1000 схемных узлов ОДНОВРЕМЕННО (ПАРАЛЛЕЛЬНО) считывали данные из памяти. Причем из РАЗНЫХ дампов

Я просто хочу понять, как это выглядит ФИЗИЧЕСКИ: из одной микросхемы памяти торчат 1000 штук 20 битных шин адреса? Ведь получается 20000 контактов?

 

 

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

сам решает каким образом это реализовать.

И не заморачивайтесь над вопросами реализуемости. Тоже самое ПЛИСовод сам подберет

элементную базу под проект, это его прямая задача.

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

 

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

Спасибо за помощь.

Edited by Студент заборстроительного

Share this post


Link to post
Share on other sites
Неужели, Студент_ и Arjun, это одно и то же лицо?

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

У товарища реально раздвоение личности. Строчит под разными никами.

А может где и спорит сам с собой? :cranky:

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
А может где и спорит сам с собой? :cranky:

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

за свободу ежиков. Не менее двух десятков точно. И большая часть из них "свои".

 

Про двухпортовую память я слышал. А про N-портовую - нет.

Вы мне скажите. Это реально?

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

В Вашем случае это 1000 блоков двухпортовой памяти.

 

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

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

Share this post


Link to post
Share on other sites

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

ваша проблема в том, что вы рисуете 1000 одновременных обработчиков, без четкого понимания в их необходимости.

может, будет достаточно одного? или десяти? или ста? почему 1000? как считали и чем обосновываете необходимость?

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

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

 

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

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

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

 

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

 

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

 

для максимальной производительности, пакет в ПЛИС формируется не в памяти, а "на лету".

например. с АЦП есть поток данных.

он нарезается по 1024 байта, перекладывается на 32-битную шину данных, т.е. пакет "длится" 256 тактов. это блок формирования данных.

далее данные с этого блока потоком поступают на блок "дописывания к пакету заголовка".

Блок "дописывания к пакету заголовка" формирует в свою выходную шину N штук тактов с данными заголовка, после чего прозрачно передает данные со своего входа на выход (данные АЦП).

далее этот поток передается в блок ethernet MAC

ethernet MAC потоком передает данные наружу, дописывая впереди перед пакетом start sequence, выдавая биты пакета в линию наружу, вычисляя "на лету" FCS, и выдавая биты FCS в конце кадра ethernet.

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

а как же дописываемый заголовок UDP/IP? так он на половину из констант, которые интегрируются в конечный автомат, а вторая половина хранится в регистрах, которые настраиваются при запуске системы.

Share this post


Link to post
Share on other sites

Поддержу krux'а

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

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

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

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

но усилий разработчика и ресурсов ПЛИС будет потрачено много больше.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this