[syoma 1]

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

[Flip-fl0p 4]

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

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

 

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

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

Шел четвертый год войны...

Беда в том, что ТС сказал что все описанное на предыдущих пяти страницах ему известно уж более 30 лет.

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

А именно от этой самой обработки будет зависеть сможет ли справиться одна плис или нет?

[syoma 1]

Шел четвертый год войны...

Беда в том, что ТС сказал что все описанное на предыдущих пяти страницах ему известно уж более 30 лет.

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

А именно от этой самой обработки будет зависеть сможет ли справиться одна плис или нет?

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

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

 

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

ИМХО протокол у ТС похож на EtherCAT, только быстрый. Предыдущие пакеты - это, наверное для фильтрации.

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

Это все наши домыслы!

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

Ответ нам не получить и тема давно живет своей жизнью без участия ТС.

[Plain 168]

Пруфит? Увеличение скорости реакции в

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

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

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

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

Вы не поняли. Я нуб в ПЛИС, но не устройстве АСУТП.

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

 

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

 

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

 

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

 

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

 

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

Т.е. ставить 1000 ПЛИСин?

А почему нельзя (я никак врубиться не могу) "1000 ПЛИСин" реализовать внутри одной ПЛИСины?

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

 

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

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

 

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

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

 

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

Это важно. Но это уже детали реализации.

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

 

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

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

 

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

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

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

 

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

Ещё раз.

Как я представлю решению.

10G Приемопередатчик заполняет оперативную память данными, полученными по езернету.

При этом для него память не сегментируется. Она для него как единое целое.

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

Такое же "логическое пространство задачи" находится на другой стороне эзернетовского кабеля.

Так вот задачей приемопередатчиков является создание "ЗЕРКАЛА". Т.е. точных копий "логического пространства задачи" на обоих сторонах.

Для этого используется 10G езернет

 

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

 

И теперь наконец то, чем тема: можно ли эти 1000 дампов обрабатывать одной ПЛИСиной ПАРАЛЛЕЛЬНО?

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

 

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

 

Все же крайне очевидно. Прилетает из вселенной поток в 10Gb/s. 10 гигабит в секунду.

Его надо:

1. распотрошить на блоки по 64 байта

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

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

Конгениально, коллега :beer:

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

 

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

 

Все же крайне очевидно. Прилетает из вселенной поток в 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 что является нормой для данного типа памяти.

Все.

 

Что в вышеописанном неверно.

Всё верно :beer:

 

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

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

 

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

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

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

Наверное просто издиваются

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

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

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

Наверное просто издиваются

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

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

Время приема Ваших 1000 пакетов уже не представил лишь самый ленивый, т.е. Вы сами.

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

Так что большой вопрос, кто над кем издевается?

Вы не поняли. Я нуб в ПЛИС, но не устройстве АСУТП.

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

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

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

Почему "не хочу понять"? Я прекрасно это понимал еще до создания этой темы. Ещё лет 30 назад

Давайте очень грубо прикинем.

Допустим длина пакета (со всеми служебными полями) порядка 1600 байт

Прием такого пакета займет 1.6 мкс

Один такой пакет несёт в себе дампы 25 узлов.

Значит чтобы обновить всё "логическое пространство задачи" потребуется примерно 40 циклов шины или 64 мкс.

Т.е. получается что дамп (размером 64 байта) каждого из 1000 устройств в "логическом пространстве задачи" обновляется с периодом ПОРЯДКА 64 мкс.

 

Пока всё ясно? Или уже тут есть какие-то сомнения?

-----

Идём далее.

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

Они не ждут какого-то специального сигнала "данные обновились"

Они (эти узлы) работают со своим собственным циклом и им ПЛЕВАТЬ с какой частотой обновляются данные в дампе 10G приемопередатчиком.

Тут понятно?

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

[Inanity 1]

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

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

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

Абсолютно.

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

Но хотя алгоритм одинаковый устройства могут находится в разных состояниях (автомат состояний)

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

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

Почему "не хочу понять"? Я прекрасно это понимал еще до создания этой темы. Ещё лет 30 назад

Давайте очень грубо прикинем.

...

Т.е. получается что дамп (размером 64 байта) каждого из 1000 устройств в "логическом пространстве задачи" обновляется с периодом ПОРЯДКА 64 мкс.

 

Пока всё ясно? Или уже тут есть какие-то сомнения?

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

 

Идём далее.

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

Они не ждут какого-то специального сигнала "данные обновились"

Они (эти узлы) работают со своим собственным циклом и им ПЛЕВАТЬ с какой частотой обновляются данные в дампе 10G приемопередатчиком.

Тут понятно?

Вот тут Вы неправы!!!

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

А дальше, все стандартно - новые данные = новый расчет.

Если конечно Вам хочется - делайте непрерывно пересчет. Но как ни крутите, один обсчет в каждом из 1000 должен пройти за 64 мкс

[Inanity 1]

Абсолютно.

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

Но хотя алгоритм одинаковый устройства могут находится в разных состояниях (автомат состояний)

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

 

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 тактов сложной математики, то это ни в какую ПЛИС не влезет с такой пропускной способностью...

 

 

Изменено 2 января, 2018 пользователем Inanity

[syoma 1]

ИМХУется мне, что ТС вообще будет достаточно одного обработчика - нужно просто обьяснить, как в ПЛИС работает time division multiplexing.

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

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

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

Вот тут Вы неправы!!!

Необходимо всегда указывать "Данные обновлены"

Зачем?

По хорошему бы надо.

Но можно и без него. Для универсальности

Главная проблема не в этом.

А в принципе. Можно ли реализовать такую архитектуру

 

Но как ни крутите, один обсчет в каждом из 1000 должен пройти за 64 мкс

Не обязательно.

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

 

Да и необязательно цикл обновления дампов будет фиксированным и равным 64мкс.

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

Поэтому какие-то дампы будут обновляться каждый 1,6 мкс, а какие-то раз в 320 мкс

 

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

 

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

Ну вот смотрите. Каждые 1.6мкс приходит новый пакет, содержащий 25 дампов состояния объёмом 64 байта каждый.

И какие дампы будут обновлены заранее неизвестно.

И скорость реакции заранее неизвестна. Она зависит от того, что пришло.

Т.е. от состояния устройства. Поэтому какие-то дампы требуют НЕМЕДЛЕННОЙ реакции, а для каких-то и задержка 320 мкс приемлима

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