Приветствую!
О... , даааа! Красный забор^2! Это конечно все радикально меняет ... (толстая шутка !)
Я никогда не возьмусь за разработку системы с такой постановкой задачи.
Я пытаюсь Вам донести мысль что НЕЛЬЗЯ выбирать архитектуру системы не зная КОНКРЕТНЫХ требований алгоритмов ее работы. Вот ведь предложенная мной УНИВЕРСАЛЬНАЯ архитектура с 1000 FPGA Вам ведь почему то не понравилась.
Вам уже отвечали что в общем случае МОЖНО! Ну а "частные случаи" - тип памяти, объем, диаграмма доступа, суммарный throughput, тип/расположение, и будет ли это достаточно для Вашей обшей задачи это ведь НEВАЖНО!
Ой не говорите ....

Удачи! Rob.

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


Общим ответом в поставленном вопросе будет ссылка на сайты плисопроизводителей с указанием "ищите плис у которой будет не меньше 1000 блоков памяти (очень грубо смотрите по числу умножителей в плис)". Что касается тех деталей - чуть выше написал.

А есть ли вообще устройства, способные одновременно по одному каналу (шине данных) прочитать 1000 ячеек памяти с разными адресами? Если не ошибаюсь, то их нет, следовательно Вашу задачу, в такой постановке, не решить.

Почему "по одному каналу"?
Мне тут что-то говорили про многопортовую память

Мне кажется, что прикол вообще не в этом.
представим себе физический объект с 1000 датчиков. Объект может быть 2-х типов.
1. Что-то вроде стенда для испытаний чего-то быстро-меняющегося, например плазмы... Тогда надо просто достаточно быстро записать данные по 1000 каналам в 1000 компьютеров и только потом их обрабатывать...
2. Речь идет об Объекте Управления. Которым надо рулить в реальном времени. Но тогда задается основной вопрос не о времени доставки сообщений, а о времени реагирования. И далее встанет вопрос об алгоритме управления и об исполнительных механизмах. Реальные механизмы - это доли секунд. К чему тогда разговоры о "нс"? А как ТС хочет реализовать алгоритм управления, если он заявляет, что устройство должно быть "универсальным" и не зависеть от "проекта"??? На аппаратной реализации языка Си??? Или еще каким либо образом.
3. А если это быстрое устройство, облепленное умными датчиками? А кто будет проводить согласование временных меток от датчиков? Ведь как не подстраивай часы в датчиках за "нс" они расползутся...
4. Теперь вопрос о сети... 1000 датчиков они где расположены? В прямой видимости? Или через свитчи? А свитчи тоже исказят время, если временной метки нет в пакете... Ну и так далее.

Вообще все это похоже на лохотрон. Ну скучно перед праздником... Вот и тема появилась потрепаться.... 1000 датчиков из памяти читать одновременно... Смешно и грустно...

Прошу прощения, понимал как доступ к внешней оперативной памяти.
Внутри плис, можно "создать" аналог многопортовой памяти, но это детали проектирования, которые требуют раскрытия некоторых деталей обработки.
Вполне возможно, что раскрыв "несущественную деталь" Вы, не раскрывая сверхсекретного алгоритма, сможете получить ответ как на одной плис, обработать 64КБ данных за определенный промежуток времени много меньший скорости приема и не потерять при этом никакой информативной части результатов.


А мне напоминает моих начальников. То они начитавшись\наслушавшись о плис с блеском в глазах приходят "да там такие возможности!!!", а после некоторых бесед "мне сказали плис все может, а ты меня к земле приколачиваешь, да еще и говоришь что дел не на 15 минут, как рассказывал привлеченный консультант".
И как всегда, никакой конкретики.

Вы зря стараетесь меня "выудить" у меня детали ноу-хау нашей системы управления и "развести", чтобы я забесплатно устроил Вам ликбез по современным АСУТП. Хотя у меня ест чем возразить и дополнить по каждому из перечисленных Вами пунктов. Но я "калач тёртый". И на "слабо рассказать?" не ведусь

И повторяю Вас. Не надо пытаться научить меня как избежать необходимости принимать и обрабатывать в реалтайме поток 10G.
Я про эти способы прекрасно в курсе.

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


Если Вам скучно - сходите на фишки.нет и петросян.ком.
А тут серьёзный технический форум

Если Вы всё знаете зачем тогда спрашиваете ?


Задача имеет решение только если известно как в потоке замешаны данные ! Т.е надо знать как формируется поток !
Какой применяется алгоритм для обработки данных ?
Очень странно, что такой профессионал, как Вы, этого не понимаете !
Пока можно сказать что:
В некоторых FPGA есть трансиверы для приема/передачи потока 10Гбит/с, при имеющейся постановки задачи большего сказать нельзя.
Допустим Вы приняли поток 10Гбит/с. Распарсили его паралельно, обработали вашим супер-алгоритмом. Как вы данные будете обратно отдавать ?

Потому, что:
1) в голове есть архиважный алгоритм с запредельными характеристиками;
2) кто-то из окружения бросил фразу "делай на плис - она всё может";
3) дальше расчетов на бумаге\в матлабе ничего не сделано. И все уперлось в те самые детали, о которых ТС не желает ничего говорить.
Вообще, тема по моему, лишена продолжения - уже прозвучали слова о том что ничего не скажу - все необходимое дано выше.

Более того, ТС мог давным давно проверить работу своего алгоритма в Матлабе и посчитать затраты на обработку, пропускную способность и все остальное.
Что и предлагаю сделать ТС, а нам всем удачи и весело отметить Новый Год!

С наступающим Новым Годом!

Приветствую!
Ой как неуважитеоьно по отношению к собеседникам! Ведь судя по всему это Вы пытаетесь выудить ноу-хау "...как же черт возми это можно сделать ..." и забесплатно получить техническое решение для Вашей системы управления. Ай ай ай.
А зачем ? Ведь Вы же уже все знаете:

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

Удачи! Rob.

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


Просто достало слушать ликбез по устройству АСУТП. Коими я занимаюсь лет 30.
Мне не по устройству АСУТП инфа нужна, а по ПЛИС. Точнее их возможностей в части реализации описанной задачи. И я честно признался, что я нуб в ПЛИС (но не в АСУТП) А мне вместо ПЛИС начинают объяснят АЗЫ устройства АСУТП. Вот я и вспылил


Когда эти замечания по существу я к ним внимателен. А когда эти замечания с целью увести тему в сторону - меня это выводит из себя.

Вот же задача.


Что тут не понятного?

Вы нуб, но почему-то решили, что можете судить по существу вопрос или не по существу, когда его задают те, кто в вопросе не нуб.
Это та причина, по которой вас считают на этом форуме не специалистом по АСУТП, а недалеким болтуном.

Решением задачи "в лоб" было предложено товарищем RobFPGA. Других разумных решений в рамках поставленой задачи быть не может из-за недостатка исходных данных.
Ваше описание 1000 параллельных процессов - есть результат ошибочного суждения.
У вас могут данные с датчиков собираться как угодно: параллельно, перпендикулярно - это значение не имеет !
Имеет значение что, данные с датчика как-то обрабатываются и упаковываются в ethernet кадры, которые передаются по линку 10gb/s.
FPGA ловит эти данные и начинает обработку по какому-то алгоритму. Результат обработки выдает по каналу 10gb/s.
Я нарисовал картинку как я представляю Вашу задачу:


Так вот самой важной информацией является то, как данные с датчиков запакованы в Ethernet кадр. И по какому алгоритму данные с датчиков будут обрабатываться. В простейшем случае - это конвейер, который будет обрабатывать данные темпе приёма этих кадров и отправлять на передачу по каналу 10gb/s.
Я до сих пор не могу понять откуда у вас взялось 1000 параллельных потоков !
Но при любом варианте у вас данные будут приниматься и отправляться последовательно.

Ув. плисоводы , да ответьте же уже наконец то, ТС либо "ДА" либо "НЕТ" и пойдём уже бухать что ли.
С наступающим Новым Годом всех!

1000 потоков у ТС берутся перед обработкой. Приняв весь этот 10 гигабитный шалман (еще большой вопрос что там с заполненностью, может, как уже говорили он принимает раз в час свои 64КБ и гигабиты избыточны), ТС желает его тут же на лету разобрать по обработчикам. Т.е. в его понимании каждый новый принятый бит направить к своему узлу обработки. Но при этом сильно скрывает (от себя?) тот факт, что перед тем как получить 1000 потоков, ему надо разделить блоки данных от каждого формирователя к каждому узлу обработки, выполнив тем самым обратную задачу относительно приведенной блок-схемы. И когда до него дойдет что на получение блока данных в 64 КБ понадобится 64 мкс, тогда станет понятно, что все требования по обработке за наносекунды станут никчемны.
Остается ТС посчитать, сможет его алгоритм уложиться в 64 мкс или нет. Если сможет - надо искать плис у которой будет как минимум 1000 умножителей и 10G приемо-передатчик и пытаться передложить работу на нее.
А еще правильнее, приняв 10G данные, раскидать по блокам и отправить на обработку в графическую карту - та точно должна смочь обсчитать всего коня.

С наступающим Новым годом!

Этакого коня можно локально обсчитать на простеньком Virtex Ultrascale+ в 2000-ногом корпусе.
Ну или нельзя, нужно больше конкретики.

Давайте ответим человеку. Каждый свое мнение. Он посчитает вероятность исходя из ответов Отвечаем только ДА или НЕТ!
ДА!

Всех с наступающим Новым годом! выполнения констрейнов и соответсвия поведения проектов в симуляции и реальности!!!

50/50-использовали
звонок другу - не помог
осталась только помощь зала
НЕТ!

Это несправедливо, требовать ответа только с вариантами "Да" и "Нет"!
Правильнее дополнить вариантами:
"Наверное Да";
"Наверное Нет";
"Скорее Да";
"Скорее Нет";
"Возможно при/если...";
"Невозможно при/если...".
Ну а конкретнее, думаю если использовать Stratix V GS, то можно реализовать, но есть шанс лупануть из пушки по стае воробьёв. Ибо умножителей много, а что делать с 640 байтами в одном узле?
Обиднее будет посчитать их сумму потратив несколько сотен тысяч деревянных на плис, плату (особенно своей разработки) и все для того, чтобы засветить пару светодиодов.

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

Все же крайне очевидно. Прилетает из вселенной поток в 10Gb/s. 10 гигабит в секунду.
Его надо:
1. распотрошить на блоки по 64 байта
2. каждый блок 64 байта обработать каким то образом, пускай это будет сдвиг и XOR с неким ключом
3. считать обработанные данные в некий большой пул памяти.

Считаем. Данные поступают со скоростью 10Gbit в секунду, пускай это будет чистая скорость поступления данных, уже за вычетом накладных расходов.
Данные со скоростью 10Gbit вдвигаются в сдвиговый регистр длиной 64*8 = 512 бит.
Полное заполнение регистра происходит за 512*0.1 = 51ns. После заполнение на следующем такте все 512 байт улетают в копию регистра.

Дальше работа с копией, и у нас есть 51 ns на все про все.
Что же нужно сделать за это время.
1.Скопировать регистр 64 байта из копии сдвигового регистра в один из 1000 блоков распределенной памяти размером 64 байта
2. ВСЕ. Больше НИЧЕГО делать не нужно. 51ns на эту операцию это более чем достаточно раза в 4 наверное.

Так как у нас 1000 блоков, в каждый прилетает 64 байта или 512 бит, то обновление каждого блока памяти из 1000 происходит... происходит... происходит один раз в 50мкс.
За 50мкс каждый блок должен:
1. произвести сдвиг данных и операцию XOR (пункт 2 выше).
2. выставить флаг что блок данные подготовил.
Это даже не вагон времени, для 64 байт данных это вагон времени.

И наконец у нас есть третий игрок, арбитр внешней памяти, который шерстит все блоки по кругу и по флагу готовности пересылает 64 байта данных из блока во внешнюю памяти.
Арбитр должен перекачивать данные во внешнюю DDR3 памяти со скоростью 10Gb/s что является нормой для данного типа памяти.
Все.

Что в вышеописанном неверно.
И если верно, то справится с этим плисовод среднего уровня и
почему тогда столько грамотных людей морочат голову автору темы.

PS: Вот тут кстати спрашивали как это я "уложил своих". Ну вот, модераторы навесили предупреждение 10% репутации. Мелочь, но проблема в том, что они, модераторы
НИКОГДА не снимают эти предупреждения. И смотреть теперь на это до конца веков.
Чтобы этого не было, я в честь праздника никого вежливо посылать не буду. Но всем говорю прощайте. Ник будет деактивирован.
Это последнее сообщение.

ТС заморочил своим забором всем мозг.
А остальные не понимают как можно говорить о достаточности/недостаточности ресурсов, когда неизвестно все, начиная с поступления новых данных, ибо то у него 90% 10G потока ими заполнено, то может быть меньше. А может и будут не все 1000 блоков по 64 Байта, а может и не всегда придется обрабатывать с предыдущими 9*64 результатами? (это я от себя добавил, так сказать интуитивно). И есть у ТС стойкое нежелание понимать, что новый блок данных (со всех датчиков) требует времени приема и лишь затем обработки. И что ресурсы надо считать по интервалу между блоками, а не битами в скоростном канале.
Опять же, результат обработки выдаваться будет едва ли не 10Мбит/с или 100Мбит/с каналу(где-то в начале промелькнуло значение).
Но боюсь Вы окажетесь правы - вся новая хау сведется к подсчету контрольной суммы или просто среднему арифметическому.

Оказывается все предельно просто! Что два пальца об асфальт.
Надо всего-то 1000 параллельно работающих в течении "вагон времени 50мкс" алу
И где ТС писал про XOR?

А зачем для этого гнать данные это куда-то на сервер? Не проще ли на самих "1000" устройствах это сделать?

Ну я так глубоко в чужих мыслях ковыряться не умею.
А вообще ТС говорил что делает абсолютный обработчик, вот ему и надо принять данные и абсолютно обработать - ноу-хау же!

Ну в принципе ТС указал конкретные максимальные требования - 10Гбит, 1000 устройств. Т.е грубо говоря от каждого конкретного устройства данные будут приходить со скоростью 10000/1000=10Мбит. Также не забываем, что канал 10Гбит - последовательный. Т.е обрабатывать каждый бит не надо, а надо просто подождать приема полного пакета и передать его в обработку одному из обработчиков. Количество параллельных обработчиков в Плисине будет зависеть от нужного количества тактов на обработку пакета от одного устройства. Возможно, будет достаточно десятка, возможно, понадобится сотня или даже тысяча. В любом случае задача должна решаться на ПЛИСе, но нужно для начала знать алгоритм обработки и сколько тактов и ресурсов он будет занимать. Тогда можно будет подсчититать нужное окличество и размер ПЛИС

Мы это долго и упорно пытаемся объяснить ТС !

Шел четвертый год войны...
Беда в том, что ТС сказал что все описанное на предыдущих пяти страницах ему известно уж более 30 лет.
А все наши попытки детализирования - это происки завистников, желающих любой ценой выкрасть уникальный универсальный алгоритм вычисления абсолютного уравнения Вселенной. Но он нас раскусил и потому, никогда ни под каким соусом не расскажет что же он собирается делать с вновь поступившими 64 байтами, да еще с учетом предыдущих (9 или 10)*64 байт.
А именно от этой самой обработки будет зависеть сможет ли справиться одна плис или нет?

Ну я бы сказал, что по опыту решения аналогичных задач, вряд-ли у него там какой-то супер-пупер алгоритм, требующий всех ресурсов ПЛИС, раз даже обычный процессор может переварить такой поток, хоть и не на 10Гбит/с. Поэтому подозреваю, что этот алгоритм легко можно впихнуть в логику, только для этого, ессно, его надо из Си переделать в VHDL, что может в корне его видоизменить. Но это в принципе не страшно.
Поэтому я бы сказал, что одна ПЛИС справится, а для ответа на вопрос - какая - надо делать. В крайнем случае получите большую латентность, чем желаемую.

А по поводу памяти и дампов и пр. - похоже ТС описывает обычную двухпортовую память - базовый блок ПЛИС и да - она также может использоваться именно таким образом - сериализатор/десериализатор для гигабитных интерфейсов(точнее кластеризатор на пакеты)
ИМХО протокол у ТС похож на EtherCAT, только быстрый. Предыдущие пакеты - это, наверное для фильтрации.

Это все наши домыслы!
Одно дело фильтрация, другое БПФ, третье - сложные взаимные вычисления (иначе зачем тащить поток и делать обработку в одной плис?).
Ответ нам не получить и тема давно живет своей жизнью без участия ТС.

Скорость реакции без разницы какого количества потоков 1 МБ/с после передачи данных в обработчик и обратно будет как минимум вдвое меньше, т.е. 500 кБ/с, если время обработки ноль.

Вы не поняли. Я нуб в ПЛИС, но не устройстве АСУТП.
А некоторые начинают выяснять про детали устройства АСУТП, чтобы выявить "завязки по данным", "скорость работы устройств" и т.п., чтобы посоветовать мне решение как НЕ парсить поток 10Гб/с.

Господа! Повторяю в третий и последний раз: мне не нужны советы как ИЗБЕЖАТЬ парсинга 10Гб/с в 1000 потоков. Если бы мне нужны были такие советы - я бы и тему назвал по другому. Типа "есть задача парсить в 1000 потоков приходящие данные с 10 Гб/с. Как путем разных хаков свести его к потоку в 1 Мб/с и парсингу в 1 поток?"

Но я же так не назвал тему. Поэтому не надо.

Нужно парсить именно в 1000 потоков и данные поступающие со скоростью 10 Гб/с.

Единственно, что уточню (поскольку да. Из заголовка темы это не ясно): поток 10Гб/с идет постоянно. Без пауз. Т.е. предположения, что приняв 64 байта на скорости 10Гб/с езернетовский приемопередатчик выключается на полчаса НЕ ВЕРНЫ. Он колбасит ПОСТОЯННО. Т.е. данные от приемопередатчика поступают в ОЗУ постоянно


Т.е. ставить 1000 ПЛИСин?
А почему нельзя (я никак врубиться не могу) "1000 ПЛИСин" реализовать внутри одной ПЛИСины?
Меня учили, что ПЛИС как раз и предназначены для формирования внутри неё одинаковых схемных узлов, работающих ПАРАЛЛЕЛЬНО. Или это не так?


В памяти есть 1000 одинаковых дампов. Я хочу чтобы все они обрабатывались ПАРАЛЛЕЛЬНО, поскольку имеют одинаковый формат данных и одинаковый алгоритм обработки. В чем я не прав?


Да. Всё правильно.


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


С этим я и не спорил.


Ещё раз.
Как я представлю решению.
10G Приемопередатчик заполняет оперативную память данными, полученными по езернету.
При этом для него память не сегментируется. Она для него как единое целое.
Это память представляет собой единое "логическое пространство задачи" (как пишут в умных книжках по распределенным системам управления).
Такое же "логическое пространство задачи" находится на другой стороне эзернетовского кабеля.
Так вот задачей приемопередатчиков является создание "ЗЕРКАЛА". Т.е. точных копий "логического пространства задачи" на обоих сторонах.
Для этого используется 10G езернет

"Логическое пространство задачи" представляет собой 1000 дампов одинакового формата

И теперь наконец то, чем тема: можно ли эти 1000 дампов обрабатывать одной ПЛИСиной ПАРАЛЛЕЛЬНО?
Чтобы с каждым дампом был связан свой схемный узел ПЛИСины, работающий независимо от других узлов


Конгениально, коллега
Именно эту простую мысль я пытаюсь донести до коллег уже 7-ю страницу


Всё верно


Спасибо. Понял.


Тоже не понимаю. Почему меня пытаются постоянно увести куда-то в сторону от темы, предлагают решения НЕ МОЕЙ задачи и прочее...
Наверное просто издиваются

Потому что Вы в свою очередь не хотите понять простой истины, прием пакета требует времени и пока пакет не принят - обработка не начнется.
Весь Ваш обмен данными выродится в мультиплексор с одной стороны и демультиплексор с другой.
Время приема Ваших 1000 пакетов уже не представил лишь самый ленивый, т.е. Вы сами.
Уже шесть страниц Вам советуют посчитать интервал приема новых данных (со всеми накладными расходами в виде заголовков, контрольных сумм и т.п.), и затем смотреть, как Ваш алгоритм уложится в этот интервал. И если он укладывается в этот интервал, то остается выбрать плис в которой можно поместить ваши 1000 однотипных узлов. И уже дальше решать, искать готовую плату с этой плис или ее большими собратьями, или делать свою.
Так что большой вопрос, кто над кем издевается?

Скажите, только честно. Вы 30 лет назад закончили институт и больше по специальности не работали, а теперь решили вернуться в системотехники?

Почему "не хочу понять"? Я прекрасно это понимал еще до создания этой темы. Ещё лет 30 назад
Давайте очень грубо прикинем.
Допустим длина пакета (со всеми служебными полями) порядка 1600 байт
Прием такого пакета займет 1.6 мкс
Один такой пакет несёт в себе дампы 25 узлов.
Значит чтобы обновить всё "логическое пространство задачи" потребуется примерно 40 циклов шины или 64 мкс.
Т.е. получается что дамп (размером 64 байта) каждого из 1000 устройств в "логическом пространстве задачи" обновляется с периодом ПОРЯДКА 64 мкс.

Пока всё ясно? Или уже тут есть какие-то сомнения?
-----
Идём далее.
Схемные узлы в ПЛИСине обрабатывают каждый свой дамп ПОСТОЯННО.
Они не ждут какого-то специального сигнала "данные обновились"
Они (эти узлы) работают со своим собственным циклом и им ПЛЕВАТЬ с какой частотой обновляются данные в дампе 10G приемопередатчиком.
Тут понятно?

Алгоритм обработки для каждого из 1000 узлов одинаковый?

Абсолютно.
Потому что удаленные устройства относятся к одному и тому же типу.
Но хотя алгоритм одинаковый устройства могут находится в разных состояниях (автомат состояний)
Поэтому для одного узла может потребоваться сделать одно, а для другого - другое (потому что он находится в другом состоянии)

Хвала всевышнему. Читаем сообщение 65 (стр 5) и сравниваем, как далеко разошлись интервалы.


Вот тут Вы неправы!!!
Необходимо всегда указывать "Данные обновлены", реализация всегда вариативна - можно ставить сигнал по совпадению контрольной суммы принятого дампа, или отсчитывать байты, но конец сообщения по 10G каналу должен генерировать метку изменения данных.
А дальше, все стандартно - новые данные = новый расчет.
Если конечно Вам хочется - делайте непрерывно пересчет. Но как ни крутите, один обсчет в каждом из 1000 должен пройти за 64 мкс

1. Отлично, уже что-то. В любом случае будем считать, что можно написать такой алгоритм обработки, чтобы он мог обслужить любое из устройств, в любом из их внутренних состояний.
Итого мы получили некоторый обработчик (будем называть его так). Этот обработчик по своей сути - некоторая логическая схема, включающая в себя конечный автомат, буфер памяти, умножители и прочие функции, которые необходимы для обработки.

2. Итого, что мы имеем. Поток 10Gb разбирается (десериализируется) и раскидывается на N-ное количество обработчиков, далее, на выходе от обработчиков результат собирается обратно (сериализируется) в 10Gb. Теперь нам нужно понять сколько нужно таких обработчиков, чтобы канал не захлебнулся (когда новые данные поступают, а обработка старых не закончилась).
В идеальном варианте обработчик должен представлять из себя конвейер, который на каждом такте будет принимать новые данные, D - тактов обрабатывать и в конце выдавать на каждом такте результат. Другими словами у вас получится задержка на обработке в количестве D-тактов.

3. Теперь, чтобы эта мясорубка завелась, нужно прикинуть из чего состоит один обработчик, какие ему нужны ресурсы, сколько тактов уйдёт на обработку одного блока данных от одного устройства. Основные ресурсы для ОДНОГО обработчика:

-> количество памяти
-> количество FF и LUT (в терминалогии ПЛИС это регистры и логические функции)
-> количество DSP блоков, они нужны для математики, если она у вас есть (умножение/деление/корень и тд). Математику лучше делать на DSP иначе потратите много FF и LUT.

Ресурсы любой ПЛИС ограничены, как вы понимаете. Чем "легче" будет один обработчик, тем больше их можно будет впихнуть в параллельную обработку, чтобы справиться с 10Gb данных.
Если предположить, один обработчик работает с производительностью 100Мбит, то таких нужно будет 100 штук. Чтобы уместить 100 обработчиков + логику для разборки/сборки этого потока, нужно понимать сколько весит один обработчик, т.е. возвращаемся к пункту 3.



Я понимаю, что у вас не было опыта работы с ПЛИС, но если вы скажете, что обработчик должен, например:

1. иметь буфер памяти на 1КБ
2. Сделать 10-20 проверок (логических сравнений).
3. пару раз умножить числа разрядностью N x M с аккумуляцией результата где-то...
4. Взять квадратный корень из результата...
5. сложить результат с какой-нибудь фигнёй и таким образом сформировать итоговый результат.

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

Иначе - это всё разговоры ни о чём. Если ваш алгоритм требует 100.000 тактов сложной математики, то это ни в какую ПЛИС не влезет с такой пропускной способностью...

ИМХУется мне, что ТС вообще будет достаточно одного обработчика - нужно просто обьяснить, как в ПЛИС работает time division multiplexing.
Если у вас обработчик одинаков для всех 1000 устройств, то даже если он включает автоматы состояний с разными состояниями для каждого из них, его все равно очень просто переключать между разными потоками данных от разных устройств используя мультиплексор и демультиплексор.
Т.е на практике 1000 одинаковых обработчиков в ПЛИС никто не пихает, так как полный парралелизм обычно никому не нужен - даже в задаче ТС входные данные не приходят одновременно, а идут по последовательному каналу, один за другим, оставляя огромное время на обработку. Возможно это пытаются донести ТС тоже?

Зачем?
По хорошему бы надо.
Но можно и без него. Для универсальности
Главная проблема не в этом.
А в принципе. Можно ли реализовать такую архитектуру


Не обязательно.
Критичность скорости реакции зависит от текущего состояния удалённого устройства

Да и необязательно цикл обновления дампов будет фиксированным и равным 64мкс.
Частота передачи дампов удаленным контроллером может зависеть от текущего состояния устройства.
Поэтому какие-то дампы будут обновляться каждый 1,6 мкс, а какие-то раз в 320 мкс

P.S. Господа! И реагируйте поспокойней. Я понимаю, что у Вас "мозг взрывается" и с такими сложными задачами Вам, видимо, ещё не приходилось работать. Но что поделать.


Ну вот смотрите. Каждые 1.6мкс приходит новый пакет, содержащий 25 дампов состояния объёмом 64 байта каждый.
И какие дампы будут обновлены заранее неизвестно.
И скорость реакции заранее неизвестна. Она зависит от того, что пришло.
Т.е. от состояния устройства. Поэтому какие-то дампы требуют НЕМЕДЛЕННОЙ реакции, а для каких-то и задержка 320 мкс приемлима

с таким подходом - НЕТ.

дело в том что я был в подобной ситуации, и для того чтобы задача легла на архитектуру плис её пришлось переписывать трижды. Уточняя "мелочи" в ТЗ, которые превращались в жирные кляксы, перечеркивая уже проделанную работу.

2 ТС
умеете работать с x86 - берите DPDK в руки. это если нужен практический результат.
если практический результат пофиг и вы пишете кандидатскую, ничего не зная про предметную область плис - вас на защите как катком раскатают.


поясняю:
парсинг в плис - это не 1000 раз сравнить один байт с "чем-то".
для понимания в чем эффективность ПЛИС - нужно окунуться с головой в поиск по бинарному дереву, когда речь идёт не про сравнение строк, байтов ли чего ещё, а про сравнение СЛЕДУЮЩЕГО ПРИХОДЯЩЕГО БИТА. блин.
нового решения по поиску исходя из сравнения очередного бита.
за счет этого собственно производительность и достигается.

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


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

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



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

Что мне реально интересно?

Почему достаточно адекватные участники форума, так сказать, "ведутся" на такие темы и пытаются помогать ТС (даже диаграммы рисовать не лень ).
Просто тут всего 2 варианта:

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

Лично моё мнение, что и в 1-ом и во 2-ом случаях ни в коем разе нельзя помогать автору темы.

В первом случае, думаю, это очевидно.

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

100%


100% повторно!

Так Вы, насколько мне помниться, и не "помогали"?
Тогда чего так возбудились?

P.S. И сотрите своё хамство, флуд и "переходы на личности" пока я не обратился к модераторам

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

P.S. Обращайтесь.

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

Ну если Вам трудно мыслить абстрактно, то давайте к конкретике (пример вымышленный /но все же он передает то, чего в реале я хотел бы получить/, поэтому обсуждение "для чего оно нужно?" давайте оставим "за кадром").

Допустим каждый из тысячи узел ПЛИС просто каждые 10 мкс считывает байт за байтом инфу из своего дампа (64 байта) памяти 10G приемника, делает операцию XOR с некоей константой и записывает в память 10G передатчика.
Приемник и передатчик никак не синхронизируются между собой и с узлами. Узлы в ПЛИС также работают совершенно независимо от других узлов, 10G-приемника и 10G-передатчика
Каждый просто ТУПО делает свою работу не взирая на то, в каком состоянии находятся данные.

Теперь. Когда есть конкретика Вы можете оценить сложность реализации такого проекта?

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

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

Такая задача имеет решение. Но для её решения не нужно 1000 узлов. Ядро 10Gb ethernet выдаёт обычно 64 бита на частоте ~156Мгц. Далее XOR с константой, запись в промежуточный регистр и вывод на ядро передатчика в том же виде (64 бит ~156Мгц). Глубина конвейера - 1 такт, частота работы ~156Мгц.

Просто немного смешно. Это такая пушка по воробьям))

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


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

Удачи! Rob.

Вот опять "снова здорова".
Да плевать, что "из пушки по воробьям", плевать, что можно НЕ решать такую задачу.
Плевать что с помощью разных хаков можно свести задачу к меньшей размерности.
ПЛЕВАТЬ.
Мне нужно решить задачу именно так, как я указал в заголовке. Чтобы "обкатать" саму архитектуру

И потом, я же сказал, что пример с "ХОR" вымышленный.
В реальности же каждый узел ПЛИС будет целым микроконтроллером и обработка дампа будет описываться достаточно большой прогой на Си.

Но с точки зрения идеологии построения системы, с точки зрения архитектуры НЕ ВАЖНО, будет ли "программа обработки" просто XOR-ом или большой программой.

Это понятно?

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

Теперь понятно "откуда ноги растут"?

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