Добрый день,

возможно у меня философский вопрос, не пинайте меня, пожалуйста, за это.

Уже в трех проектах мне надобно было брать поток с оцифровщиков и, минимальными изменениями заводить на PC. Сам PC обычно перекидывал содержимое этого потока на графические карты, а там дикая производительность решала все мои вопросы. При попытке хоть часть алгоритма оставить в FPGA время разработки проекта становилось ужасно ненормально большим. Задачи о которых я горовю - это задачи линейной и мультилинейной алгебры. В FPGA я с 2009, в вычислительной математике с 1990. То есть я четко понимаю, что мне надо:

я хочу поток с одного или нескольких оцифровщиков (а иногда с других компьютеров), положить в пишущий порт памяти, примерно на 1-8ГБ, иметь возможность воткнуть эту память в обычную материнку, чтобы она разпозналась как обычная память, и читать с процессора ее как есть, синхронизацию можно организовать внутри самой памяти, помещая на каждый блок на 4К какую-то синхронизационную информацию.

Аналогично, хочу сделать в обратную сторону, но это не сильно актуально.

Вопросы, скажите, пожалуйста:

1. есть ли уже готовый такой модуль?
2. думаю, что такого модуля нет, правильно ли я понимаю, что такое можно разработать, если всем этим будет управлять какая-нибудь не дорогая плиска, а на входе будет около 60 LVDS пар, работающих на примерно 200-800МГц частоте. Конечно хотелось бы иметь возможность и сердексы подсатвлять, но, наверное это не сразу.
3. сам много писал для плисок, но ни разу не разводил, да и с памятью работал больше гоняя чужие примеры или примеры с мануалов. Скажите, пожалуйста, сколько при сильной мотивации мне надо положить времени на такую разработку и сколько денег на платы и железки, если сам буду стараться по максимуму?

Спасибо

PS: просто реально приспичило, так как оцениваю, что мне таких плат в следующем году может потребоваться около 100, а то, что мы сейчас делаем через Terasic TR4 просто невозможно дальше модернизировать из-за того, что наши заумные алгоритмы плохо ложатся на FPGAшную логику, а количество умножителей в плисках все также стремится к нулю при одинаковой цене с графической картой. Все-таки хочется цену разумную иметь, у нас все-таки не военка с резиновым бюджетом.

ИИВ

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

Для начала - каков входной поток с оцифровщика?

Если < 6 GByte/s то гораздо проще это все через PCIe заводить.
Потому как в противном случае начала надо будет как минимум найти multiport!!! DDR3/4 память чтобы можно было ее одним концом в слот PC а вторым в контроллер оцифровщика. А иначе овчинка по скорости смысла иметь не будет.

Успехов! Rob.

Приветствую Вас RobFPGA,

да, понимаю, PCIe, так тоже делали, как раз через тот же терасик, но вот как раз-то скорости-то и не хватает да и ужасно все криво получалось с софтвером и латентностью.

Хотелось бы 7-8ГБайт/с, то есть например, 16 каналов 250МГц по 14 бит, это то, что реально сейчас пользуется.

А вот если как-то плисовы ноги на порты DDR3, а к самой плиске и оцифровщик, и сами платы памяти воткнуть?

Тут еще хотелось бы, чтобы эта конструкция не сильно по габаритам от обычной DDR3 планки отличалась, то есть в 2 раза больше - еще устроит, а вот в 4 - уже нет, так как память может стоять в сервере с U1-U2 раке, и туда не полезть, а данные с оцифровщиков как раз по самтекоскому шлейфу туда бы и приходили бы.

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


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

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

Ну я и имел ввиду двух-портовая (тоже ведь мулти) попробуй такую DDR3/4 найди!
А имитировать память DDR3/4 на FPGA гиблое дело - кроме геморроя с реализацией толку никакого так как латентность на чтение будет дикая.

7-8 GByte/s втянуть можно - или Gen3 x16 (недавно на форуме была инфа про скорость DMA на плате Gen3 x16 - 12 GByte/s получали) ну или в параллель пару плат Gen3 x8.
Можно даже через стандартные 10G затянуть - 8 портов - 8 GByte/s Да к тому-же и удаленно ADC подключается - лепота! Все ж проще и надежнее будут решения чем геморой в слот памяти.

А что Вы так считаете если не секрет что нельзя пред-обработку хотя бы делать перед заливкой в комп для снижения потока?

Успехов! Rob.

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


я со счета сбился сколько уже проектов на эту тему было, два в геологии, один в астрономии, два в химии, а тут еще один наклевывается. К нам обращаются из-за правильной математики - так как обработку делаем в виде многомерного сингулярного разложения, но алгоритм плохо ложится в плиску, то есть можно что-то сделать на плиске, а что-то на процессоре. Вот отладка такого гемора меня тотально достала. Сложность алгоритма такова, что на одно принятое гигаслово данных надобно только около 100 гигафлоп, то есть часто хороший 8-миядерник может потянуть, ну а на графической карте - точно получается, даже на встроенной можно, только не понятно как туда данные засосать. А алгоритм часто меняется (зависит от числа и скорости оцифровищков и свойств задачи), а перекомпилить квартусом проект бывает на сутки все виснет, хоть в квартусе весь проект всегда меньше 1000 строк бывал (я тут несколько лет назад похожие примеры приводил). А иногда оцифровщиков бывает не 16, а 64, и их желательно сразу по 4/8/16 группировать на разные процессоры и графические карты. То есть то, что мне надо, оно просто выстрадано за последние 7 лет нашей активности в этой области. Да, на выходе нашего многомерного сингулярного разложения уже только мегабайты или даже килобайты в секунду полезной информации, но, как я говорил, из-за большого числа флопов, сильной ветвистости алгоритма и использования гигабайтов вспомогательной памяти, это все на плиску ну совершенно не лезет.

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

Если так то я бы на вашем месте все же задумался о варианте 10G - стандартно и масштабируемо - да и реализация на стороне FPGA 10G Ethernet сейчас не так сложна при соответствующей FPGA конечно.
У меня по такой схеме несколько систем широкополосной записи работает 4GByte/s через 4 10G линка. Собранных еще на древних Virtex5.

Успехов! Rob.

Да нет же все это шашечки, а мне ехать надо. Сейчас USB3.0 пользуем, была пока не успешная попытка пользовать SoC и пользовали PCIe.

У нас по алгоритму должна быть большая буферизация данных, то есть процессор схватывает пачками на сотню мегабайт, а иногда из такой пачки ему надо только маленький блок. Если пользовать без буфферизации, то USB3.0 да и 10G по скорости будет не хватать, а всяко потом окажется, что часть данных была не нужна, а данные на процессор зашли и трафик забили. Вы же понимаете, что в современных процессорах флопов раз тысячу больше, чем операций по доставке данных до самого процессора, и хочется с этим элегантно разобраться.

До этого буферизовали на планке памяти, которая сидит при плиске, но это достаточно геморно, особенно когда протокол буферизации часто меняется.

Короче хочу именно того, что говорил.

Есть следующие вопросы, скажите, пожалуйста:

1. есть ли принципиальная возможность отганизовать DDR3 протокол со стороны памяти силами плиски, или это не реально по таймингам? И на какую плиску стоит тогда закладываться?
2. есть ли какая-то водможность воткнуться безболезненно в порты DDR3, чтобы самому перенаправлять потоки память-плиска?
3. есть ли еще какой-то способ воткнуться вместо памяти АЦПшником?

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


Я как раз ехать и предлагаю да еще и с ветерком



Какая я то каша - У вас есть поток данных в 8 GByte/s например, вы хотите его отобразить на память в компе какая разница как это вы сделаете - воткнув в слот памяти неведомую зверюшку или загнав этот поток через стандартный интерфейс в стандартную же память ? Для процессора результат будет одинаковым - он сможет читать данные из памяти.



Главное чтобы вы сами поняли а чего же вы хотите!

1. Функционально возможность есть - но по таймингам будет отстой - судите сами надо принять и декодировать команду от CPU выполнить ее через свой контроллер DDR кодировать данный в формат DDR и выдать в сторонy CPU и все это за за десяток-другой ns - так что это нереально!
2. только вариант с 2-х портовой DDR3 - в один порт FPGA в другой CPU
3. см вариант N2

Удачи! Rob

в одном случае канал памяти (не процессор) будет забит так, что процессор не сможет обращаться к остальной памяти с адекватной скоростью, да и кеш процессора будет забит всякой ересью от этих интерфейсов, а в другом случае (с неведомой зверушкой) процессор сможет успешно разруливать сам эти запросы в зависимости от алгоритма. Это очень серьезная разница, как я говорил пропускная способность оперативной памяти у современных компов отстает в сотни раз от вычислительной способности процессоров. Попробуйте сами написать умножение двух больших (10к х 10к) матриц на современном многоядернике и достичь хотя бы пол-пика от производительности, сразу поймете о чем я. Имея поток в 8ГБайт/с с АЦПшника в память и не более этого с неведомой зверушки на процессор, есть надежда сидеть значительно ниже лимитов скорости доступа к памяти, а вот при трафике в 8ГБайт/с по PCIe в несколько линий или по 8 комплектам 10G комп больше ни о чем думать не сможет.


1. правильно ли я понимаю, что двухпортовую DDR3 не используют в обычных писишках?
2. можно ли как-то обманывать на уровне быстрого свича обычную DDR3, что если идет запрос с материнки, то он резолвится в память как есть, а если запроса нет, то в эту память валится то, что пришло с АЦПшника. При небольшой промежуточной буферизации потока с АЦП и правильно расставленных приоритетах (у АЦПшника он выше) наверное можно это малой кровью разрулить или я таки размечтался?

PS: поймите, меня пожалуйста, я не потрепаться открыл эту тему, а выстрадал годами реальную необходимость в этом!

Здравствуйте,

Достаточно давно делаю платки для "нестандартных" вычислений(где нужны гетерогенные ядра) и хочу сказать следующее:

1) Смотрели в сторону GPU кластеров?

2) Если я все правильно понял, вы упоминаете затею воткнуть некую платку с "разными камнями" в ддр3 слот - скажите, просчитывали ли вы то как:

- все остальное будет правильно распознавать это дело вплоть до уровня биоса?
- потребление всего этого дела?
- чисто механические ограничения ддр3 сокета(вес, размеры по отношению к несущей мазерборде)

Хитровыдуманные решения под сокеты памяти встречал, но их хитровыдуманность скажем так, для людей с достаточно крепкой психикой и очень специфическими задачами. Для указанных вами типов вычислений помнится разводил платки с Core i3, i5 + FPGA, сейчас более перспективным видится конструкция следующая:

- Tegra K1 + Atom + Kintex 7 - достаточно дешево и мощно, сертифицируется под индустриальное применение в т.ч под -40гр
- Tegra X1(от одного ядра) +Virtex Ultrascale (+) + Xeon - дикая мощь, дикая цена, везде ддр4 со скоростями от 2хххх, и много других плюшек

Возможно есть еще варианты на камнях от IBM, но я в них ничего не смыслю и соответственно ничего путного не могу сказать.

наша фирма с 2008 является официальным консультантом Nvidia в Германии по массивно-параллельным вычислениям

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

Не считаю, что тупой менеджер потоков (память-процессор, память-АЦП) должен занять много места на плате, поэтому считаю, что планка должна быть примерно в 2-3 раза больше обычной планки памяти, чтобы влезть в серверный U1. Не хотелось бы это делать в асике, ибо нет опыта.

В таком случай вопрос снимается Что касается остального:



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



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



Это бессмысленно- не тот тип задач. Максимум- SOC/MCP

Имхо, реально задача для платформы с гетерогенными камнями- чтобы там вся грязная работа делалась, а далее кидало на ваш сервер. Говоря о больших буферах можно вообще на том девайсе поднять что-то вроде рамдиска через PCIe, но это разумеется вариант для серьезных камней. Если не секрет, на каком железе сейчас решаете или решали задачу(вся цепочка кроме TR4)?

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


О как все запущенно - берем DDR3-1600 для 64 бит планки одно-канальный режим - 12.800 Gbyte/s для двухканального - ~ 25 GByte/s из этого 8GByte/s займет входной поток - 30% всего!
А если же в проце 2 контролера и память DDR3‑2400 ?
При этом данные попадают в память не через CPU и его кэш а через DMA непосредственно с периферийной карты.


Еще раз - есть рабочая система - принимает непрерывный трафик 4 GByte/s рапаралеленный по 4м 10G Ethernet - собирает его в памяти и пишет на raid. Все это удовольствие кушает ~20-40 % ОДНОГО ядра 8 ядерного проца. Остальные 7 ядер как и второй проц в системе бездельничают.
Есть система с картой Gen2 x8 передает непрерывно 2.7 GByte/s - ОДНО ядро в проце занято на 7 %.


Я о такой и не слышал вообще


Этот вариант может и возможен потому что есть вот такой чудо TS3DDR3812 но как синхронизировать переключение между портами без потери данных и возможно ли это вообще делать в рабочей системе?

PS: поймите, меня пожалуйста, я не потрепаться открыл эту тему, а выстрадал годами реальную необходимость в этом!

Это я понимаю у самого тоже похожие вопросы постоянно возникают. Но на таком уровне задачу на коленке не решит - попытка приделает звершку к стандартному интерфейсу тянет за собой необходимость соблюдать этот стандарт начиная от электрический параметров и кончая временными и функциональными. То есть куча проблем а что взамен? - с экономим 10-30% пропускной памяти и 10 % CPU ? Думаю тут надо внимательно на системном уровне для начала подумать - прикинуть + и - той или иной реализации с конкретными цифрами.

Успехов! Rob.

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


у меня количество в качество переходит, уже 7-ое приложение требует одного и того же dataflow, хотя алгоритмы у всех этих задач существенно отличаются. Из-за того, что алгоритмы проще параллелить и отлаживать на CPU и GPU, а на плиске оно еще может вдруг не вместиться или по таймингу не пройти, готов помучится и таки сделать что-то, чтобы оно стало так работать.


из самого маленького - вместо TR4 была DE3, а все крутилось на вначале на мелких псшках, потом на 5-ом эксиносе, был жуткий гемор по засовыванию алгоритма на DE3 (я тут как-то об этом несколько лет назад писал), так как писюк или эксинос не мог много засосать трафика и жутко тормозил при получении данных по етернету,

из самого большого - сервер с 8-ю бордами H8QG6-F, в каждой по PCIe заходил трафик из своей TR4, буфферизовался на терабайте внутренней памяти и перенаправлялся на АМДшную сдвоенную карту, на которой и проходил основной расчет. Трафик с PCIe от TR4 почти полностью убивал способность 64 наличевствующих обычных ядер хоть что-то посчитать (получалось около 10% от пика, в то время, как без PCIe трафика все разгонялось до 60% от пика). Трафик с GPU всегда можно сделать блочно, поэтому там все было классно, а в TR4 тогда буфферизация на внутренней памяти не была задействована, так как слотов не хватало.

Вот была бы у меня такая неведома зверушка, сидела бы она на одном из 32 слотов в H8QG6-F и не было бы у меня печали, и две ГПУшки бы засунул, и считался бы на раз, а может бы и все входы с АЦПшек смог бы на пару слотов в памяти в одну материнку запихнуть и было бы мне тогда счастье, что все в общей памяти крутится.


да процессоры будут не заняты, но контроллер памяти забъется, так как трафик будет не рыба не мясо, и после этого серьезные задачи, которые плотно работают с памятью на этой системе решить будет нельзя. Проверяли на PCIe, перед началом коммуникаций если все данные не лежат в кеше процессора, можно сразу сушить весла, так как все колом встает. А кеш-то только 16МБ, то есть много не запихнуть, а памяти бывает, что и 1ТБ есть, и хочется к ней всей обращаться.

EDIT: сразу не прочитал... Какой раид!!! У меня трафик 4ГБайта в секунду по 8 часов непрерывно валит! Это 100ТБайт, а наши алгоритмы на лету могут этот трафик (понятно от задачи к задаче отличный) его до нескольких гигабайт пожать. Да, на борту под терабайт оперативки можно найти, чтобы алгоритму хватало, но это все, больше нельзя, и ответ должен быть с адекватной задержкой, максимум в один день.

Не пробовали качать данные по PCIe непосредственно в память видеокарты? Так в процессоре окажется занят только коммутатор PCIe, но не каналы памяти.
У AMD это называется DirectGMA и поддерживается в линейке FirePro.



Какой процессор в системе? Есть ли кэширование на стороне FPGA карты? Не возникало ли ситуаций, когда внезапно исчерпывались кредиты и поток замирал?

Вам человек дело говорит, а вы его и слушать не желаете. Даже я понял, что рейд там ни при чем. Ключевое слово -

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



Тестировалось на 3.2 GHz core i5 c 16 GB памяти и в рабочей машине 2 х 2.8 GHz Xeona c 32 GB памяти.
В FPGA Kintex325 vfifo в 32 MB на DDR3 - был суточный прогон с доп нагрузкой на систему - сбоев не было.

Успехов! Rob.

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



Зион + пара гпу на плате + возможно псие свич на рамдиски для длинных буферов - наружу можно выводить через что угодно, от усб 3.0 с тандерболтом заканчивая оптикой. Выйдет дешевле и "дубовее" чем покупная серверная платка + отдельные видеокарты , к тому же легко масштабировать. На всякий случай подмечу, что современные корпуса гпу и цпу спроектированы таким образом чтобы использовать как можно меньшее количество слоев- в 1U запихнуть это добро можно без существенных проблем.

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


Вы что данные программно через CPU читали из PCIe 8-()!!! Как может PCIe Gen2 x4 жалкие 2 GB трафика забить суммарную пропускную памяти этой платы в 100 GByte/s.

Удачи! Rob.

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

Я бы не писал об это если бы этим не занимался 7 лет.

Я бы не писал бы об этом, если бы конкретно в этой ситуации с этой картой (H8QG6-F) не происходило бы следующее: трафик с PCIe был всего-то 1ГБайт/с, но вспомним, что на TR4 всего есть чуть меньше 2МБайт M9K и похожей памяти, реально, если работать двумя сегментами, можно писать только по пол мегабайта, то есть пол мегабайта со скоростью 2ГБайта в секунду напрочь забивают один из двух каналов в каждом процессорном блоке.

Память должна быть замаплена, иначе, по PCIe работать нельзя, чтобы ее притащить в общую, то есть надо копировать, то есть размаппим и копируем, итого, второй канал тоже серьезно забит, примерно на 30-40%, а в реальности серьезно больше, так как остальные процессоры к этой памяти хотят достучаться. Итого имеем напрочь забитые 16 ядер из 64, ну и примерно четверть от 100ГБайт,с трафика этой памяти тоже товось, то есть коту под хвост, а это суммарно со стоимостью TRки около 8 штук.

Итого, если мне в масспродакшене моя неведома зверюшка будет стоить дешевле восьми штук зелени и будет с меньшим гемором обходиться, я всеми конечностями за. Не так ли?

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

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


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


Вот этого я и не могу понять. К сожалению (а может и к счастью) с системами на AMD давно уже не работал.
Для систем с Intel я уже приводил примеры - буквально сегодня тестировали систему с Gen2 х8 на Kintex
Непрерывный поток с ADC - 2Gbyte/s, FPGA формируются кадры данных переменной длинны и добавляет заголовки. В худшем случае при малых размерах кадра суммарный поток увеличивается до 2.3 Gbyte/s - все это передается в память через scater/gater DMA. Поток который обслуживает DMA и дополнительно занимается выравниванием данных в памяти по заголовкам занимает %7-9 одного ядра!.
Еще один поток просматривает ВСЕ заголовки в памяти - строит хитрый индекс и пишет в отдельный файл. В худшем случае имеем как минимум чтение и обработку 1 GByte/s заголовков + запись результата ~1GByte/s. Поток который это делает занимает 40-60 % одного ядра. Полюс запись всего основного потока. Итого очень грубо как минимум 2*2.3 GB/s ввод/вывод, 2*1GB чтение/обработка ~6.4 GB/s из 25 GB/s 25% суммарной пропускной памяти одного проца. Параллельно остальные 6+8 ядер загружали различным мусором для прогрева помещения. И все работает - что я делаю не так?


Понятное дело - кстати данные в выше приведенной системе копируются с уровня драйвера в userspace, не знаю точно как это сделано в linux через маппинг или реально копирование.
Понятно что перемножение матриц не самый приятный алгоритм для памяти особенно DDR. Но чтобы такой малый поток так забивал пропускную памяти? Может алгоритм требовал копирование в невыгодном направление для DDR?


Не так - допустив такая приблуда есть и у вас в памяти ОДНОГО проца чудесным образом появляются новые данные. Другие процы тоже захотят поживится свежатинкой - то есть - копирование, занятие шины, ...упал, очнулся, гипс...
Ладно допустим воткнем каждому процу по собственной животинушке - упс. стомость в N раз (кстати 4 штуки 2x10G Ethernet стоят ~$4K ) и доп проблемы с синхронизацией. К тому же решение с DDR3 swich выигрыша почти не даст так как swich - это РАЗДЕЛЕНИЕ полосы памяти.
Поэтому только вариант зверушки с TRUE DUAL PORT DDR3 memory поможет выиграть при 8GB/s всего до %30 на один контроллер памяти DDR3-1600. И все это надо будет разместить на одной планке - и DDR и FPGA и обеспечить синхронизацию между парами планок 8-().


Ну USB я тоже за серьезный интерфейс не считаю (вернее не для таких применений). А вот PCIe это стандарт придуманный как раз раз для этого.
И кажется мне что нервов при разработке и отладке зверушки будет потрачено гораздо больше да еще и при негарантированном результате чем при работе с PCIe. При этом через пол-год новый тип памяти сделает зверушку ненужной а PCIe решение будет работать и там.

Естественно все это мое глубокое imho помноженное на жару от бесполезно работающих 6+8 ядер

Успехов! Rob.