Spartan-6 скоростная двухпортовая память на DDR3 Опции

[Fourier]

Здравствуйте!
Стоит задача спроектировать устройство сбора данных: на борту двухканальный 8-разрядный АЦП с максимальной частотой семплирования 1ГГц, данные должны сохраняться в ОЗУ и с определенной задержкой выдаваться на ЦАПы. АЦП, ЦАПы подобрал, с ПЛИС тоже определился вопрос встал в сохранении данных . Необходима двухпортовая память объемом не менее 8 Мбайт, чистая скорость записи и чтения данных (без учета времени на передачу управляющих команды и т.д.) не менее 2 Гбайт/с.
Есть идея организовать такую память на Spartan-6 XC6SLX75T и памяти DDR3 (например MT41J64M16JT-125). С DDR3 раньше не работал. По документации на MCB у Xilinx фигурирует скорость 800 Mb/s (это я так понимаю максимальная скорость дергания пинами данных), при 16-битной шине пиковая скорость – 12.8 Gb/s. Скорости хорошие, но я так понимаю эффективная скорость значительно ниже. Я планировал взять 4 микросхемы MT41J64M16JT-125 и использовать все 4 MCB XC6SLX75T, при этом одновременно 2 микросхемы работают на запись данных, 2 – на чтение, потом переключаются.
Ряд вопросов к разработчикам с практическими навыками проектирования устройств с DDR3:
- прокомментируйте мои мысли));
- возможно ли на Spartan-6 в реальном времени получить скорость записи/чтения чистых данных 2 Гбайт/с;
- что можете посоветовать для решения моей проблемы.

Заранее спасибо.

Сообщение отредактировал Fourier - May 7 2013, 08:09

[AJIEKCEu]

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

У меня возник еще один вопрос)) Есть такой заманчивый АЦП HMCAD1511, дешевый, четырехканальный, с 8-разрядной LVDS шиной. В двухканальном режиме с частотой оцифровки 500 MSps нужно гонять по линиям данных сигнал с частотой 1 ГГц. По описанию "Up to 1050Mbps data transfer rate per differential I/O", т.е. вроде бы Spartan-6 должен обеспечивать такую скорость. Подскажите, пожалуйста, реально ли это сделать? Тогда можно было бы уменьшить число выводов АЦП и упростить трассировку

Насчет первого - в зависимости от "несложности" ЦОС будьте морально готовы к нескольких отсчетов за такт. 250МГц для Spartana - это уже граница (если верить http://www.xilinx.com/support/documentatio...ides/ug389.pdf). А фактически - её наверное тяжко будет достичь - так что 4/8 отсчетов за такт для 500/1000 Мегасемплов - это более реальные вещи. А 8 отсчетов за такт обрабатывать - не всегда сладко. Короче аккуратнее с закладываемой сложностью. И опять же, наверное Kintex уже имеет шансы потянуть 250МГц.

Насчет второго - мне кажется будет очень непросто. Сам такого не делал. Разбирался в аппликухе по приему на Virtex-6 1200 Мбит/с по паре. В общем-то чтобы получилось - должно быть ещё очень хорошее качество входных данных. У Спартана-6 есть xapp1064 - видимо надо курить его. Пробежавшись, не до конца понял за счет чего обеспечивают такой прием. Вроде там IODELAY сильно ущербнее, но они берут разницу между разными TAP-ами. Хотя по их расчетам на странице 23 - у них все неплохо. Не попробовав - не стал бы закладываться на максимум. Прежде чем пробовать - в любом случае надо посчитать с учетом всяких разных разбросов. Опять же, сэкономив слегка на АЦП и "якобы" на трассировке - добавите себе лишней головной боли по реализации приема в ПЛИС и трассировке тех самых восьми пар (частота-то в 4 раза возросла!).
Короче решение хоть и красивое, на то, что оно заработает с первого раза я бы не рассчитывал (особенно в серии).

Если не надо SFP, то можно использовать обычный PHY и трансиверов (Т) не надо.

Даже если надо SFP - есть 88e1111 который умеет SGMII из RGMII делать (хотя - это лишняя микросхема).

А вообще задача непростая. У S6 контроллер памяти выведен на фиксированные пины, причем у нас инженер матерился когда разводил один 16-битный чип.

Вот и у меня такое ощущение.

Так же учтите что MCB независимые, и если использовать 2 на запись - работать они будут каждый по своему.
Я бы проверил также предсказуемость работы МСВ - а то вдруг вам надо данные с оцифровки писать, а он надумал калибрацию погонять (только предположение).

чтобы посадить все ДДР на один контроллер с шиной 32 или 64 бита - иначе потеря синхронности каналов памяти.

А вот это в легкую решается за счет относительно небольших буферов. Синхронность работы именно контроллеров в данном проекте не нужна. Нужна синхронность выдачи в ЦАП. Сделать по буферу на контроллер и вычитывать все буфера по самому медленному - ИМХО не проблема совсем (запас по средней скорости должен получиться достаточный). А вот делать один контроллер на 64 бита - тогда уж ставить SODIMM. Иначе - лишние проблемы с разведением управления/адреса - fly-by, несколько микросхем на шине и т.д. (а частота-то не маленькая).

В общем и целом - возможно задача имеет право решаться на Spartan-6, если обойдется двумя микросхемами памяти. При большем количестве - возможно имеет смысл смотреть в сторону Kintex-а все таки.

Экономия 500$ на ПЛИС ИМХО имеет смысл только при серии >100шт.

Соглашусь. Только в данном случае на ПЛИС-то в общем столько и не экономится. А вот QDRII+ - тут да, она как раз 500 баксов добавит. Впрочем, повторюсь, у Кинтекса - свои заморочки.

[Fourier]

Даже если надо SFP - есть 88e1111 который умеет SGMII из RGMII делать (хотя - это лишняя микросхема).

Спасибо большое за ответ.

SFP не надо, наверное. Скорее всего буду использовать PHY Marvell 88e1111. Поэтому можно применить XC6SLX75 вместо XC6SLX75T, там действительно пользовательских выводов значительно больше (408 vs 348).

Насчет первого - в зависимости от "несложности" ЦОС будьте морально готовы к нескольких отсчетов за такт. 250МГц для Spartana - это уже граница (если верить http://www.xilinx.com/support/documentatio...ides/ug389.pdf). А фактически - её наверное тяжко будет достичь - так что 4/8 отсчетов за такт для 500/1000 Мегасемплов - это более реальные вещи. А 8 отсчетов за такт обрабатывать - не всегда сладко. Короче аккуратнее с закладываемой сложностью. И опять же, наверное Kintex уже имеет шансы потянуть 250МГц.

Скорее всего в режиме работы, когда нужна обоаботка допустимо понизить частоту дискретизаци до 80-100 MSPS. Вообще в данном изделии два кртических к быстродействию режима работы:
1) Оцифровать сигнал с частотой до 1 GSPS (500 MSPS, Пока не определились), сохранить в ОЗУ и потом не очень спешно перекачать по Ethernet на комп для обработки.
2) Оцифровывать в реалтайме сигнал с частотой до 300 MSPS и сохранять его в памяти, потом через определенное время считывать и выдавать на ЦАП. В этом режиме нужна минимальная обработка: типа детектирования сигнала нужного уровня (это я так понимаю можно сделать прорежая входные отсчеты)

Мое резюме:
В первом приближении достаточно 2 микросхем DDR3:
- для режима ретрансляции в ЦАП будет достаточно частоты оцифровки 300 MSPS на канал, а для режима сбора буфера (с частотой до 1 GSPS на канал) и передачи по Ethernet можно задействовать обе микросхемы - сначала на запись, а потом на чтение, что должно обеспечить сохранение данных со скоростью до 2 ГБайт/с.

Всем спасибо за ответы и советы! Буду курить мануалы и даташиты