[Студент заборстроительного 0]

Задача имеет решение только если известно как в потоке замешаны данные !

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

 

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

Ой как неуважитеоьно по отношению к собеседникам!

Просто достало слушать ликбез по устройству АСУТП. Коими я занимаюсь лет 30.

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

 

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

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

 

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

 

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

 

 

Изменено 30 декабря, 2017 пользователем Студент заборстроительного

[one_eight_seven 3]

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

Это та причина, по которой вас считают на этом форуме не специалистом по АСУТП, а недалеким болтуном.

[Flip-fl0p 4]

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

Решением задачи "в лоб" было предложено товарищем RobFPGA. Других разумных решений в рамках поставленой задачи быть не может из-за недостатка исходных данных.

Ваше описание 1000 параллельных процессов - есть результат ошибочного суждения.

У вас могут данные с датчиков собираться как угодно: параллельно, перпендикулярно - это значение не имеет !

Имеет значение что, данные с датчика как-то обрабатываются и упаковываются в ethernet кадры, которые передаются по линку 10gb/s.

FPGA ловит эти данные и начинает обработку по какому-то алгоритму. Результат обработки выдает по каналу 10gb/s.

Я нарисовал картинку как я представляю Вашу задачу:

 

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

Я до сих пор не могу понять откуда у вас взялось 1000 параллельных потоков !

Но при любом варианте у вас данные будут приниматься и отправляться последовательно.

[zombi 0]

Я уже несколько страниц пытаюсь добиться от господ ПЛИСоведов ответа на один простой вопрос: можно ли в ОДНОЙ (!!!) ПЛИС создать 1000 схемных узлов так, чтобы, они читал/писали данные из общей оперативной памяти ОДНОВРЕМЕННО/ПАРАЛЛЕЛЬНО?

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

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

 

[Александр77 1]

Я до сих пор не могу понять откуда у вас взялось 1000 параллельных потоков !

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

Остается ТС посчитать, сможет его алгоритм уложиться в 64 мкс или нет. Если сможет - надо искать плис у которой будет как минимум 1000 умножителей и 10G приемо-передатчик и пытаться передложить работу на нее.

А еще правильнее, приняв 10G данные, раскидать по блокам и отправить на обработку в графическую карту - та точно должна смочь обсчитать всего коня.

 

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

[jojo 0]

А еще правильнее, приняв 10G данные, раскидать по блокам и отправить на обработку в графическую карту - та точно должна смочь обсчитать всего коня.

 

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

Ну или нельзя, нужно больше конкретики.

[svedach 0]

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

ДА!

 

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

[zombi 0]

Отвечаем только ДА или НЕТ!

ДА!

50/50-использовали

звонок другу - не помог

осталась только помощь зала

НЕТ!

[Александр77 1]

Это несправедливо, требовать ответа только с вариантами "Да" и "Нет"!

Правильнее дополнить вариантами:

"Наверное Да";

"Наверное Нет";

"Скорее Да";

"Скорее Нет";

"Возможно при/если...";

"Невозможно при/если...". :bb-offtopic:

Ну а конкретнее, думаю если использовать Stratix V GS, то можно реализовать, но есть шанс лупануть из пушки по стае воробьёв. Ибо умножителей много, а что делать с 640 байтами в одном узле?

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

[vvvv 0]

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

 

Все же крайне очевидно. Прилетает из вселенной поток в 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% репутации. Мелочь, но проблема в том, что они, модераторы

НИКОГДА не снимают эти предупреждения. И смотреть теперь на это до конца веков.

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

Это последнее сообщение.

[Александр77 1]

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

ТС заморочил своим забором всем мозг.

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

Опять же, результат обработки выдаваться будет едва ли не 10Мбит/с или 100Мбит/с каналу(где-то в начале промелькнуло значение).

Но боюсь Вы окажетесь правы - вся новая хау сведется к подсчету контрольной суммы или просто среднему арифметическому.

[zombi 0]

...с этим плисовод среднего уровня

Оказывается все предельно просто! Что два пальца об асфальт.

Надо всего-то 1000 параллельно работающих в течении "вагон времени 50мкс" алу

И где ТС писал про XOR?

[blackfin 16]

Оказывается все предельно просто!

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

[zombi 0]

...вся новая хау сведется к подсчету контрольной суммы или просто среднему арифметическому.

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

[Александр77 1]

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

Ну я так глубоко в чужих мыслях ковыряться не умею. :smile3046:

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