[Flip-fl0p 4]

Вот эти вот длинные прямоугольники, к которым у Вас подключаются датчики - это что такое ?

Как этот прямоугольник работает ?

Что он делает ?

[toshas 0]

Предложу такой вариант: раз пакет 64 байта, делаете 10 блоков (глубина запомненных значений) памяти на 64КБ каждый.

При получении каждого нового пакета, определяете номер устройства - по сути адрес для всех блоков, в один пишете, с других читаете, когда в какой писать и читать определяете по отдельной карте адресов также хранящихся на блочной памяти. Затем этот блок остается ждать следующий пакет, а следующий блок берется за расчет в конвейерном режиме. Если получится обеспечить работу алгоритма создания ответной части конвейерно и на частоте 156МГц, Ваша задача решена.

[RobFPGA 27]

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

 

Вот опять.

...

А у меня задача сделать УНИВЕРСАЛЬНУЮ "числодробилку" без привязки как какому-то конкретному случаю. Без разных хаков, работающих только при определенных условиях.

Мне нужно, чтобы "числодробилка" могла использоваться в ЛЮБЫХ случаях, а не только в каких-то конкретных

...

В таком виде Ваша задача НЕ имеет ИНЖЕНЕРНОГО решения. Можно только фантазировать на тему ".. какой универсально длинный забор можно зафигачить чтобы огородить все ...".У Вас к сожалению полного понимания задачи пока не видно отсюда и метания от "кольцевой сетки микроконтроллеров" до "1000 устройств на 10G".

Обрабатывать realtime потоки >1 GByte/s сейчас не сложно ЕСЛИ четко ставить задачу что и как. Я делал несколько систем с потоковой обработкой 4-9 GByte/s и в каждом случае выбор железа делался только после анализа и оптимизации КОНКРЕТНЫХ алгоритмов.

А у Вас то

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

А через некоторое время уже другое

А реально для улучшения точности и адекватности результатов нужно КАЖДЫЙ РАЗ анализировать не 10, а 100 последних блоков, плюс сравнить результаты с результатами других устройств.

И если Вы не понимаете ОГРОМНУЮ разницу между двумя этими вариантами то реальной системы Вы так и не построите.

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

 

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

 

Удачи! Rob.

 

[iosifk 3]

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

Поддерживаю...

Но все же, вот хочется человеку сделать именно "автомобиль", а вовсе не "автобус" и не "грузовик" и даже не "трейлер". Но только такой хочется универсальный "автомобиль", чтобы его не надо было перенастраивать после 100 пассажиров, на прием 100 Тонн груза. А мы тут все пристаем с вопросами... Мешаем человеку устроить тут развлекуху на академическую тему...

 

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

В таком виде Ваша задача НЕ имеет ИНЖЕНЕРНОГО решения.

А в таком?

 

 

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

Зачем?

Вы хотите взяться его реализовать?

Зачем Вы постоянно хотите увести тему в несущественные детали?

 

Тут ведь решается более общий вопрос. Вопрос выбора архитектуры системы. А Вы все пытаетесь "закопать" темы в каких-то частных случаях и не существенных деталях..

 

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

 

Всё.

[RobFPGA 27]

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

А в таком?

О... , даааа! Красный забор^2! Это конечно все радикально меняет ... (толстая шутка !)

Зачем?

Вы хотите взяться его реализовать?

Я никогда не возьмусь за разработку системы с такой постановкой задачи.

...

Зачем Вы постоянно хотите увести тему в несущественные детали?

Тут ведь решается более общий вопрос. Вопрос выбора архитектуры системы. А Вы все пытаетесь "закопать" темы в каких-то частных случаях и не существенных деталях..

...

Я пытаюсь Вам донести мысль что НЕЛЬЗЯ выбирать архитектуру системы не зная КОНКРЕТНЫХ требований алгоритмов ее работы. Вот ведь предложенная мной УНИВЕРСАЛЬНАЯ архитектура с 1000 FPGA Вам ведь почему то не понравилась. :laughing:

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

Вам уже отвечали что в общем случае МОЖНО! Ну а "частные случаи" - тип памяти, объем, диаграмма доступа, суммарный throughput, тип/расположение, и будет ли это достаточно для Вашей обшей задачи это ведь НEВАЖНО!

...

Всё.

Ой не говорите ....

 

Удачи! Rob.

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

Зачем?

...

Зачем Вы постоянно хотите увести тему в несущественные детали?

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

 

Тут ведь решается более общий вопрос. Вопрос выбора архитектуры системы. А Вы все пытаетесь "закопать" темы в каких-то частных случаях и не существенных деталях..

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

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

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

 

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

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

Почему "по одному каналу"?

Мне тут что-то говорили про многопортовую память

[iosifk 3]

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

...

 

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

Мне кажется, что прикол вообще не в этом.

представим себе физический объект с 1000 датчиков. Объект может быть 2-х типов.

1. Что-то вроде стенда для испытаний чего-то быстро-меняющегося, например плазмы... Тогда надо просто достаточно быстро записать данные по 1000 каналам в 1000 компьютеров и только потом их обрабатывать...

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

3. А если это быстрое устройство, облепленное умными датчиками? А кто будет проводить согласование временных меток от датчиков? Ведь как не подстраивай часы в датчиках за "нс" они расползутся...

4. Теперь вопрос о сети... 1000 датчиков они где расположены? В прямой видимости? Или через свитчи? А свитчи тоже исказят время, если временной метки нет в пакете... Ну и так далее.

 

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

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

Почему "по одному каналу"?

Мне тут что-то говорили про многопортовую память

Прошу прощения, понимал как доступ к внешней оперативной памяти.

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

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

 

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

:bb-offtopic:

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

И как всегда, никакой конкретики.

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

Мне кажется, что прикол вообще не в этом.

представим себе физический объект с 1000 датчиков. Объект может быть 2-х типов.

1. Что-то вроде стенда для испытаний чего-то быстро-меняющегося, например плазмы... Тогда надо просто достаточно быстро записать данные по 1000 каналам в 1000 компьютеров и только потом их обрабатывать...

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

3. А если это быстрое устройство, облепленное умными датчиками? А кто будет проводить согласование временных меток от датчиков? Ведь как не подстраивай часы в датчиках за "нс" они расползутся...

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

 

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

Я про эти способы прекрасно в курсе.

 

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

 

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

Если Вам скучно - сходите на фишки.нет и петросян.ком.

А тут серьёзный технический форум

[Flip-fl0p 4]

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

 

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

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

Какой применяется алгоритм для обработки данных ?

Очень странно, что такой профессионал, как Вы, этого не понимаете !

Пока можно сказать что:

В некоторых FPGA есть трансиверы для приема/передачи потока 10Гбит/с, при имеющейся постановки задачи большего сказать нельзя.

Допустим Вы приняли поток 10Гбит/с. Распарсили его паралельно, обработали вашим супер-алгоритмом. Как вы данные будете обратно отдавать ?

Изменено 30 декабря, 2017 пользователем Flip-fl0p

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

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

Потому, что:

1) в голове есть архиважный алгоритм с запредельными характеристиками;

2) кто-то из окружения бросил фразу "делай на плис - она всё может";

3) дальше расчетов на бумаге\в матлабе ничего не сделано. И все уперлось в те самые детали, о которых ТС не желает ничего говорить.

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

[vvvv 0]

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

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

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

 

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

 

[RobFPGA 27]

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

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

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

...

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

А зачем ? Ведь Вы же уже все знаете:

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

Я про эти способы прекрасно в курсе.

...

А тут серьёзный технический форум

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

 

Удачи! Rob.