[Quantum1 1]

Добрый день!

Прошу помощи у форумчан. 
Я сейчас занимаюсь первичным/компановочным дизайном системы терагерцового видения. Есть некая специальная матрица (разрабатывается другой организацией), с которой снимается и обрабатывается сигнал, матрица с помощью flip-chip крепиться к микросхеме. Это микросхема(по сути ROIC но с оцифровкой) переводит сигнал в цифру и отправляет на ПЛИС. Пока мы в общем компануем систему, постепенно находя понимание как должна выглядить ROIC. И будем ли мы ее сами проектировать или заказывать разработку.
Но к одной большой проблеме пока не понятно как подступиться - принимаемый сигнал сложной формы по этому для его обработки требуется хорошее временное и динамическое разрешение помноженное на кучу пикселей - по предварительным подсчетам каждую  миллисекунду ROIC должен генерировать ~60Мбайт. В ПЛИСе(вероятно потребуется больше одного, и он будут близко к ROIC несколько сантиметров) куча  небольших конвееров которые будут это все обрабатывать, благо алгоритм обработки по оценкам будет не сложен. Не очень понятно как это все в ПЛИС загонять, т.е. через интерфейс/шину. Поскольку сам ROIC еще пока на стадии проработки сможем гибко подойти к вопросу. В общем основной вопрос какой наиболее эффективный способ перегонять в реальном времени такие объемы?

Большое спасибо, все откликнувшимся!
 

[blackfin 14]

18 minutes ago, Quantum1 said:

... каждую  миллисекунду ROIC должен генерировать ~60Мбайт.

60 Мбайт/мс это 60 ГБайт/с или 480 Гбит/с.

По каждой паре LVDS XC7VX690T может передавать 1,2 Гбит/с.

Таких пар у него 480 шт.

Для передачи 480 Гбит/с вам достаточно иметь: 480/1,2 = 400 LVDS пар.

[RobFPGA 27]

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

2 minutes ago, blackfin said:

Для передачи 480 Гбит/с вам достаточно иметь: 480/1,2 = 400 LVDS пар.

Ну или 48+ трансиверов на 10Gbit. А для экзотики c 12.5/25/56 Gbit/s  и того меньше 

Удачи! Rob

[Quantum1 1]

Про LVDS уже прикинули... и усмехнулись*)

Но у нас чипы близко, не надо 10м прокачивать. Паралельная передача?

Just now, RobFPGA said:

48+ трансиверов на 10Gbit

 не совсем понял, оптические? А нас на одной ПП рядом стоят 2 кристалла.

Изменено 3 октября, 2019 пользователем Quantum1

[RobFPGA 27]

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

6 minutes ago, Quantum1 said:

не совсем понял, оптические?

Можно и оптические,  но если вам "недалеко" ехать то можно и по старинке - медью по backplane. 

Удачи! Rob

[yes 5]

24 minutes ago, RobFPGA said:

Можно и оптические,  но если вам "недалеко" ехать то можно и по старинке - медью по backplane.

понадобится свой трансивер сделать или купить (свой чип же) - подозреваю, что там не те технологии, чтобы 12Гб/с поднять, да и IP (физика прежде всего, да и вокруг тоже не просто) такое денег стоит очень много (я например ни разу не видел, так как по деньгам лежит вне тех категорий, с которыми довелось работать)

[RobFPGA 27]

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

1 minute ago, yes said:

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

Понятное дело что это будет далеко не дешево  - все же 60 Gbyte/s  поток вывести это не два пальца i2c  

Удачи! Rob.

[yes 5]

52 minutes ago, Quantum1 said:

Про LVDS уже прикинули... и усмехнулись*)

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

нужно же, чтобы и в ПЛИСине был такой стандарт...

и электричество в тепло будет превращаться, куды же ему еще деваться :) для такой конструкции это может быть основной проблемой (а LVDS он с электричеством как раз дружит лучше upd: но это если сделан хорошо LVDS выход - греться то ROIC будет, нам французы когда-то такой LVDS сделали для 45нм, что плата прожгла дырку в канцелярском столе :))

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

 

[Losik 1]

Был успешный проект 8 битный ADC 56GSps 28nm, данные из чипа выводили через 64 CML драйвера по стандарту JESD204B(с модификацией). Данные принимали в FPGA через 64 GTH transceivers(up to 13.1Gbps).

http://www.ti.com/lit/ml/slap161/slap161.pdf

вместо JESD204B можно использовать ESIstream.

[baumanets 12]

Ну так по ТЗ можно косвенно определить, с большой долей вероятности, что система для ракетной техники.

Для головок всяких самонаведения, типа "стингеров". На спутниках отслеживать пуски ракет и т.д.

Частоты такие что обработка должна быть в том же кристалле, что и матрица.

Но что-то мне подсказывает, что в том ИК А2В6 работает :-)

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

Либо аппаратную реализацию кодека делайте. Того же JPEGа.

[lexx 0]

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

[dinam 1]

Я думаю вам стоит позабыть про LVDS. Вот смотрю на сенсоры Luxima, которые передают данные по LVDS, например, 1,080Mbps per port для LUX330. Или LUX2100 частота пониже, но линий побольше. Все они жутко греются судя по отзывам на этом форуме. Sony же пошла по другому пути, применив SLVS-EC, хотя до этого применяла SLVS. SLVS совместим с LVDS, но с меньшей мощностью. Т.е., наверное, правильнее идти на уменьшение количества каналов, но с увеличением скорости передачи на одну диф. пару.

[Quantum1 1]

18 hours ago, baumanets said:

Ну так по ТЗ можно косвенно определить, с большой долей вероятности, что система для ракетной техники.

Для головок всяких самонаведения, типа "стингеров". На спутниках отслеживать пуски ракет и т.д.

Частоты такие что обработка должна быть в том же кристалле, что и матрица.

Но что-то мне подсказывает, что в том ИК А2В6 работает :-)

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

Либо аппаратную реализацию кодека делайте. Того же JPEGа.

не угадали) Терагерцовые диапазон это медицина и разные охранные системы, то что мы делаем это мед. сканер. Насколько мне известно в авиации терагерцы не используются

8 hours ago, lexx said:

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

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

Мы думаем над частичной обработкой уже в ROIC,  НО одно нас очень сильно останавливает  — если вдруг потребуется внести коррективы в алгоритм обработки(в том числе по ходу жизни прибора), это все труба — на новую ревизию средств уже не будет. Поэтому мы хотим максимально снять всю «голую»  информацию с матрицы, а дальше уже обрабатываем любыми софтовыми извратами. Перешить(да даже поменять допустим в будущих версиях) плисину/прошивки процов проще чем новую микруху выпустить))

22 hours ago, Losik said:

Был успешный проект 8 битный ADC 56GSps 28nm, данные из чипа выводили через 64 CML драйвера по стандарту JESD204B(с модификацией). Данные принимали в FPGA через 64 GTH transceivers(up to 13.1Gbps).

http://www.ti.com/lit/ml/slap161/slap161.pdf

вместо JESD204B можно использовать ESIstream.

к сожалению по бюджету мы точно не потянем 28нм) 130-180нм это потолок.  ну 90нм это если только повезет.

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

Лучшк пинов побольше вывести, чем нагрев. Пока расчитываем что получиться вывести 300-500 пинов, если конечно совсем засада постараемся больше.

 

 

Я кстати не совсем понял, в таблице вы подчеркнули числа 32, 44 это количество трансиверов на кристалл? т.е гипотетически в него можно загнать 16 * 44 Гб/с?

 

Изменено 4 октября, 2019 пользователем Quantum1

[Quantum1 1]

7 hours ago, dinam said:

Я думаю вам стоит позабыть про LVDS. Вот смотрю на сенсоры Luxima, которые передают данные по LVDS, например, 1,080Mbps per port для LUX330. Или LUX2100 частота пониже, но линий побольше. Все они жутко греются судя по отзывам на этом форуме. Sony же пошла по другому пути, применив SLVS-EC, хотя до этого применяла SLVS. SLVS совместим с LVDS, но с меньшей мощностью. Т.е., наверное, правильнее идти на уменьшение количества каналов, но с увеличением скорости передачи на одну диф. пару.

Да спасибо, про SLVS сейчас читаю

[RobFPGA 27]

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

52 minutes ago, Quantum1 said:

Я кстати не совсем понял, в таблице вы подчеркнули числа 32, 44 это количество трансиверов на кристалл? т.е гипотетически в него можно загнать 16 * 44 Гб/с?

Да  можно. - У других типов FPGA есть  еще больше  трансиверов - например у  Virtex 7 есть чипы с 96 MGT  (правда с макс. скорость ~12Gbit).  У Ultascale до 60 портов c 16Gbit. Останется еще чтобы результаты обработки вывести дальше. У Intel(Altera) есть чипы с 60  портами на 28Gbit , ... (сейчас слюной захлебнусь ) 

Удачи! Rob.