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


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


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

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


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



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

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

Решением задачи "в лоб" было предложено товарищем 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" устройствах это сделать?

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