Поясню.
По езернету принимаем данные об состоянии 1000 ОДИНАКОВЫХ распределенных устройств на скорости 10 Гбит/с по оптоволокну, обрабатываем и формируем "ответку". Которую тоже передаем по оптоволоку на 10Гбит/с
Т.к. устройства одинаковые, то алгоритм работы и логика обработки дампа от каждого устройства одинакова.

Отсюда возникает желание обрабатывать все дампы ПАРАЛЛЕЛЬНО.

Отсюда в голове появляется слово "ПЛИС".

Но возникает вопрос "Как?"

Я вижу это так. Есть память. Допустим 1 Мегабайт.
В эту память пишем принятые дампы из принятых пакетов, из неё же грузим данные в пакеты.
Тут пока ничего не обычного.

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

Пруфит? Увеличение скорости реакции в 1000 раз по сравнению с последовательной обработкой на MCU


Я объяснил несколько шероховато, поскольку не специалист по ПЛИС.

Меня интересует это реализуемо на ПЛИС.
И есть ли такая память, которая позволяет использовать её одновременно как единый блок и как совокупность дампов с независимым доступом к каждому дампу?

Т.е. при сериализации/десериализации память используется как неделимый блок.
А при обработке данных в памяти она должна использоваться ПЛИСиной как набор из 1000 независимых дампов с независимым доступом.

Такое есть в природе?

Или описанные мной задачи решаются как-то иначе?

Просто обычный MCU даже i7 не успеет обработать поток 10Гбит/сек (а есть мысли сделать даже 100Гб/с).
Нужно как-то распараллеливать обработку

А как?

https://www.amazon.com/Computer-Architectur...y/dp/012383872X

Скажите своими словами: на какой элементной базе решают такие задачи: сериазизация/десериализация потока 10Гбит/с из памяти и чтение/запись из памяти в 1000 потоков параллельно

Берёте ПЛИС Xilinx у которой количество BRAM > 1000 (Kintex7, Vertex7...) и организовываете на ней двухпортовую память.


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

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


Не знаю. Я нуб в ПЛИС.
А если память не нужна, то где будет формироваться пакет для отправки по 10G эзернету?
И как будет выполняться сериализация/десереализация?

Нет.
Своими словами: "Эта задача не для вас. Пойдите и получите немного образования".

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


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

Неужели, Студент_ и Arjun, это одно и то же лицо?

Какая печаль!..

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

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

Отлично.


Я слышал об этом. Поэтому и пришло в голову "ПЛИС" когда размышлял о реализации задачи


Вот "память" у меня больше всего сомнений вызывает.
Про двухпортовую память я слышал. А про N-портовую - нет.
Вы мне скажите. Это реально?
Чтобы 1000 схемных узлов ОДНОВРЕМЕННО (ПАРАЛЛЕЛЬНО) считывали данные из памяти. Причем из РАЗНЫХ дампов
Я просто хочу понять, как это выглядит ФИЗИЧЕСКИ: из одной микросхемы памяти торчат 1000 штук 20 битных шин адреса? Ведь получается 20000 контактов?



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

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

У товарища реально раздвоение личности. Строчит под разными никами.
А может где и спорит сам с собой?

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

Как любят все ставить диагнозы. У меня параллельно не менее 3 ников, и вы не поверите сколько ников я тут уложил на форуме в борьбе
за свободу ежиков. Не менее двух десятков точно. И большая часть из них "свои".


Если объем памяти небольшой, то делается "в лоб" на внутренней памяти ПЛИС.
В Вашем случае это 1000 блоков двухпортовой памяти.

Если объем памяти большой, то создается куча FIFO и блок обмена с внешней DDR3,4 памятью.
Ну да 1000 блоков FIFO будут иметь "тысячи проводов" к блоку обмена с внешней памятью.

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

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

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

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

для максимальной производительности, пакет в ПЛИС формируется не в памяти, а "на лету".
например. с АЦП есть поток данных.
он нарезается по 1024 байта, перекладывается на 32-битную шину данных, т.е. пакет "длится" 256 тактов. это блок формирования данных.
далее данные с этого блока потоком поступают на блок "дописывания к пакету заголовка".
Блок "дописывания к пакету заголовка" формирует в свою выходную шину N штук тактов с данными заголовка, после чего прозрачно передает данные со своего входа на выход (данные АЦП).
далее этот поток передается в блок ethernet MAC
ethernet MAC потоком передает данные наружу, дописывая впереди перед пакетом start sequence, выдавая биты пакета в линию наружу, вычисляя "на лету" FCS, и выдавая биты FCS в конце кадра ethernet.
и заметьте, ничего нигде специально в некоей "памяти" не хранится.
а как же дописываемый заголовок UDP/IP? так он на половину из констант, которые интегрируются в конечный автомат, а вторая половина хранится в регистрах, которые настраиваются при запуске системы.

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

Во блин
Как я отстал от прогрессу.
Я думал что поток 10Гбит/с не сможет даже i7 в реалтайме "переварить".
И что это вообще очень сложная задача. Возможно не решаема так как я описал.
А оказывается сейчас с ней любой студент справится и даже DPDK (правда не знаю, что значит эта аббревиатура).
Ну если парсить 10Гигабитный поток в реалтайме в 1000 потоков - это рядовая задача, с которой даже студент справится, то смело буду закладывать такое решение в ТЗ



Я уже говорил. Что есть 1000 ОДИНАКОВЫХ удаленных девайсов.
Поэтом алгоритм обработки данных, поступающих от них один и тот же.

krux
А по поводу всего остального .... Отвечу позже.
Мне нужно время, что "переварить" и осмыслить все что вы сказали.
Спасибо за большой и развёрнутый ответ.

производительность DPDK на специфических задачах:
http://fast.dpdk.org/doc/perf/DPDK_16_11_I...ance_report.pdf

"На лету" обрабатывать - это значит за наносекунды закончить всю обработку?
Не. Не получится. На обработку где-то несколько тысяч тактов уйдет.


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

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


Да такое сделаеть что забор покрасить - берете 1000 FPGA к каждой цепляете свою DDR4/QDRII, 10G/100G роутите на каждую FPGA и вперед - считайте все в паралель. Делов то ...


Удачи! Rob.

Воблин

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

И кому мне верить?

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


Никому, (мне можно ...) -=
Где я написал что задачу решить нельзя ? Как раз вполне ПРАКТИЧНОЕ и реализуемое решение в полном соответствии поставленной задаче! Да к тому же и легко масштабируемое - вдруг Вам 10000 устройств надо будет обслуживать?

Удачи! Rob.

Мне говорили, что можно обойтись одной (ОДНОЙ, Карл) ПЛИСиной.
Просто прошить её так, чтобы внутри неё было 1000 узлов

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


Ааа... Ну если так то тогда Вам все ж придется как студенту, засесть за расчеты как выше советовал уважаемы krux. А может даже как прилежному студенту еще и доки по FPGA почитать . Тогда не придется беспокоится заранее о 1000 головой гидр.. RAM. Скукота...

Эх! а можно было такое ТЗ сваять - домашний аналог Amazon F1 !

Удачи! Rob.

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

Ваш сарказм означает, что насчёт "любой студент сможет" и "можно обойтись одной ПЛИСиной" меня тупо обманули?
Вы мне просто скажите одно: можно ли на ПЛИС реализовать такую память, к которой можно было с одной стороны обращаться как к единому целому, а с другой как к 1000 независимых дампов памяти в 1000 потоков одновременно?

Если нет, то как на серверах обрабатываются потоки даже не 10Гбит/с, а в терабиты и более?
Как там паралеллят обработку принятых данных?

Приветствую!
Я бы сказал что тонко пошутили
Можно!

Вы сами уже ответили "... паралеллят обработку принятых данных ..." и обычно сервер для "любого студента" выглядит как на картинке внизу - на таком запросто(тонкая шутка!) можно обрабатывать поток 4 x 10G Ethernet.
Успехов! Rob.

Я на всякий случай добавлю, вдруг поможет - если одинаковые пакеты приходят и на них формируются "ответки" по одному алгоритму, то может можно и не параллелить - можно отвечать на фреймы, используя очередь, это если вдруг формирование "ответок" реализовано не в процессорном стеке а в железе. Я делал нечто похожее. Все зависит от сложности формирования этих самых "ответок"(точнее throughput этого алгоритма). А, ну собственно примерно это уже и советовал krux

Не успеет.
Данные поступают со скоростью 10 Гбит/с, а обрабатываются (если обрабатывать в один поток) со скоростью 10 Мбит/сек

Я чего-то не понимаю, но откуда Вы взяли 1000 потоков ? Данные то приходят последовательно.... Не думаю, что одновременно данные приходят сразу от 1000 устройств. А раз данные приходят последовательно, то почему бы их так-же последовательно не обрабатывать ?
Расписали бы примерную блок схему проекта. И как замешаны данные в потоке.
Да и отдавать данные Вы сможете так-же последовательно....

Я же уже объяснял. Что "последовательно обрабатывать" даже i7 не успеет.
Что поток данных гораздо больше, чем успевает "перемалывать" даже самый крутой интеловский процессор

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

OFF
Вас банили или что значит уложил?

Да что ж до Вас доходит-то всё как до жирафа!
Гигабитный приемопередатчик работает в сотни раз быстрей обработчика данных.
Так понятно.
Поэтому ОЗУ обновляется приемопередатчиком в сотни раз быстрей, чем обработчик успевает их обработать


А что?
Разве в природе существуют люди, которых СОТНИ раз не банили на форумах рунета?

Хотелось бы посмотреть на таких экземпляров

Студент заборстроительного...
1. Что значит 10Gb? Если это просто скорость линка, то можно на 10Gb 1 килобайт принять, 3 часа обрабатывать и снова на тех же 10Gb передать. Т.е. линк получается 10Gb, а эффективная пропускная способность 1килобайт в 3 часа. Чувствуете разницу? Если нет, то проконсультируйтесь с человеком из вашей команды, который понимает, что происходит.

2. Предположим, что вы определили, что на линке 10Gb к вам приходит поток данных в 500Мбайт/сек (для примера). Для решения задачи нужно понимать суть алгоритма обработки. А именно, каковы требования по памяти, какова глубина конвейера. Исходя из этих данных уже более-менее можно будет прикинуть по ресурсам можно ли это сделать на ПЛИС, какие потребуются ресурсы, чтобы обработка на ПЛИС не стала "горлышком от бутылки" в потоке данных.

Уже третья страница пошла, а вы никак не можете толком сформулировать задачу.

Ещё раз.
Допустим данные вы нарезаете блоками по 46 байт в кадры.
Эти кадры передаёте по линку 10Gb/s.
И скорость поступления кадров будет 10Gb/"размер кадра" (разделить).

Приведу простейший пример.
Допустим у вас классический UART со классической скоростью 9600 без паритета и чётности - 8N1.
Вы передаете данные.
Данные нарезаны блоками по 8 бит, которые вы обрабатываете.
Данные окружены стартовым и стоповым бит. Т.е ваш кадр данных - 10 бит.
Итого реальная скорость поступления данных для обработки 9600/10 = 960 кадров в секунду.

С вашей задачей ситуация аналогичная.
Скорость 10Gb/s - это скорость бит в линии.
Но общаетесь то вы кадрами. И обрабатывать должны кадры.

Откуда у вас 1000 потоков взялось ?

Вы думаете я совсем дурак?
Вы думаете, что я просто так написал, что даже i7 захлебнётся от такого потока?


А почему 46, а не 1500?
Так что "КПД" канала у меня более 90%
А про 1000 потоков уже объяснял, что данные представляют собой данные 1000 ОДИНАКОВЫХ устройств, которые нужно обрабатывать ОДИНАКОВО

Потому-что я не знаю как у Вас формируются кадры.
А Вы, уважаемый, игнорируете просьбы предоставить более подробное описание ! Хотя это нужно было делать в первую очередь ! И это нужно Вам, а не нам...

Без разницы какой длины кадр.
Вы принимаете 1GB в секунду, нужно его обработать и отправить обратно.
На работу с одним байтом можно выделить не более 1нс, с пакетом - N*1нс

ничего личного, но начинает складываться такое мнение, да.

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


Только при минимальной длине пакета "КПД" канал 4%, а при максимальной - 90%.
А Вы говорите "какая разница"


Ну по самым грубым прикидками где-то так.
А я прикидывал так.
Каждое удаленное устройство описывается дампом в 64 байта.
Всего устройств - 1000.
Значит данные всех устройств занимают 64 000 байт
Скорость порядка 1 000 000 000 байт/сек
Значит скорость обновления инфы 64 000/1 000 000 000 = 64 мкс

Т.е. в дампы каждого из 1000 устройств каждые 64 мкс поступает очередная порция инфы объемом 64 байта
При обработке инфы полученной от устройства нужно анализировать не только последний 64-х байтный блок, но и 9 предыдущих.

Таким образом ты за 64 мкс должен обработать блок длиной 640 байт.
Казалось бы не много.
Но если обработку вести последовательно для всех 1000 устройств, то ты должен тратить на обработку 640-ка байтного блока: 64мкс/1000=64нс

Таким образом в среднем на обработку 1 байта нужно тратить не более 0,1 нс, а не 1 нс, как Вы посчитали.

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

Таким образом за 64 мкс ты будешь должен для каждого устройства перелопатить не 640 байт, а, как примеру 64 кбайта. Тогда чтобы успеть обработать данные всех 1000 устройств получается, что 1 байт ты должен обрабатывать за 0,001нс
А если сеть будет расти и будет не 1000 устройств, а 10000?
И сеть будет не 10G, а 100G?

Тогда я байт ты должен обрабатывать за 0,0001 нс

Даже при тактовой 5ГГц получается, что за 1/2000 такта нужно обработать 64 кбайта.
А даже при ширине шины 256 бит только чтобы прочесть 64 кбайт данных из ОЗУ потребуется минимум 2000 тактов

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

У вас на входе поток данных, каждые 6.4нс вы принимаете 8 байт данных по 10G.
Вы говорите, что блок обработчик данных имеет пропускную способность 10Мбит/c.
Посмотрите на зависимость данных в вашем алгоритме, можно ли обработку разложить
на N стадий последовательно идущих друг за другом. Если это так, то можно сделать
pipeline который будет работать на частоте потока данных 156Мгц.
Преимущество pipeline в том, что на каждом такте потребляется одна порция данных и
воспроизводиться одна порция данных. Работа идет на максимальной пропускной способности сети.
В таком случае, не надо ни чего параллелить, один инстанс ядра.

Да, конечно, для pipeliene нужно будет правильно формировать сигналы управления.

Mad_max
Можно конечно поизвращаться с оптимизацией данного конкретного алгоритма.
А если придется изменить алгоритм - мне заново перепроектировать систему?
Это никуда не годиться
Я хотел бы получить УНИВЕРСАЛЬНУЮ "зубодробилку", работающую в 1000 потоков параллельно

немного про оптимизацию...
До сих пор не сказано о том, как работают датчики.
Если имеется в виду большой физический объект, то обычно в разных ветвях алгоритма информация от датчиков имеет разное значение. Например выпущены ли шасси имеет смысл проверять только при взлете... Поэтому сомнительно, что все 1000 датчиков имеют равное значение по требуемому быстродествию... А это значит, что датчики можно разделить по группам и опрашивать с разной периодичностью...
Далее. Не сказано о взаимосвязи датчиков. Не бывает, чтобы алгоритм в одной какой-то ветви требовал полностью информацию обо всех 1000 датчиков. А это значит, что физически схему контроля датчиков можно разнести по разным физическим устройствам обработки. Ну, естественно, что часть датчиков будет обмолачиваться разными устройствами....
Ну и наконец, при таком большом количестве датчиков и большой "завязке" между ними в алгоритме, наверняка потребуется все разделить на две части. Одна будет только снимать информацию с объекта, а другая - ее обрабатывать...

Вот опять.
Мне в очередной раз предлагают подумать над тем как НЕ обрабатывать поток 10G в 1000 потоков..
Как используя разные грязные хаки, привязанные к данному конкретному случаю уменьшить объём вычислений в разы или даже на порядки.
А у меня задача сделать УНИВЕРСАЛЬНУЮ "числодробилку" без привязки как какому-то конкретному случаю. Без разных хаков, работающих только при определенных условиях.
Мне нужно, чтобы "числодробилка" могла использоваться в ЛЮБЫХ случаях, а не только в каких-то конкретных


Ну вот Вам картинка, как примерно должно всё выглядеть:

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

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

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

В таком виде Ваша задача НЕ имеет ИНЖЕНЕРНОГО решения. Можно только фантазировать на тему ".. какой универсально длинный забор можно зафигачить чтобы огородить все ...".У Вас к сожалению полного понимания задачи пока не видно отсюда и метания от "кольцевой сетки микроконтроллеров" до "1000 устройств на 10G".
Обрабатывать realtime потоки >1 GByte/s сейчас не сложно ЕСЛИ четко ставить задачу что и как. Я делал несколько систем с потоковой обработкой 4-9 GByte/s и в каждом случае выбор железа делался только после анализа и оптимизации КОНКРЕТНЫХ алгоритмов.
А у Вас то
А через некоторое время уже другое
И если Вы не понимаете ОГРОМНУЮ разницу между двумя этими вариантами то реальной системы Вы так и не построите.
Поэтому начните с одной дощечки забора - опишите алгоритм обработки данных одного устройства с учетом всех требований и подумайте как и на чем можно его реализовать.

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

Удачи! Rob.

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

А в таком?




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

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

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

Всё.