Требуется сделать трассировку DDR3, для чего необходимо учесть задержки распространения сигналов внутри корпуса микросхемы - FPGA.
Для FPGA имеется IBIS модель и модель корпуса (package IBIS).

Может ли PCB Editor расчитывать задержку используя для этого package IBIS модель, или нужно задавать PIN_DELAY? И нужно ли ставить галку в Constrain manager, если используется IBIS модель?

Доки читал, но внятного ответа не нашел...

Нажмите для просмотра прикрепленного файла

Вписывайте PIN_DELAY, эта галочка как раз их и включает в проверку длин.

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

Еще смущает вот что, Virtex 6 UG406 p.125:

Не мешайте все в кучу - IBIS используется при моделировании, с учетом pin_delay, емкости/индуктивности пинов и т.д. В констрейны параметры из IBIS не входят. Либо вписывайте отдельно, либо добавляйте на уровне библиотеки, это без разницы.

Тогда мне совершенно непонятно - зачем PCB editor при каждом касании проводника (add, slide, tune) лезет к библиотеке моделей devices.dml, в которую включены модели IBIS?

Потому что XNet определены с помощью моделей, а они могут входить в состав констрейнов. Вот и проверяет постоянно.
А в хэлпе правильно написано - временная задержка при моделировании определяется с помощью L/C, но констрейны, как правило, описаны через длины.
И да, в наших дизайнах с DDR3 PIN_DELAY для процов описан, а для чипов памяти нет. Почему - непонятно, но так есть. Возможно действительно эти длины выравнены на уровне чипа памяти, особенно учитывая его мелкий размер. А вот в проце макс. разница доходит до 12мм(это в группе, в целом еще больше), при том что в констрейнах задано выравнивание в 8мм.

Похоже что действительно придется добавлять PIN_DELAY Повозился с моделями: добавлял-удалял корпуса, заставил пересчитать buffer delay для pin - в constrain manager ничего не изменяется.

Ant_m

По-моему, Вы не там блох ловите. Задержка распространения сигнала по порядку величины 5-6 пс/мм, то есть даже при разбросе в 12 мм (в процессоре) - это всего 60-70 пс. На основной частоте порядка 500 МГц, период тактовой частоты - 2000 пс. то есть это 3% всего. Вы вот на какую частоту тактирования FPGA рассчитываете? Что-то я не видал пока, чтобы FPGA дотягивали до скоростей памяти, как правило они заметно тормознее памяти.

Hoodwin
В DDR3 некоторые группы сигналов требуют выравнивания между собой с точностью 5-20ps.
Если нужны подробности, то читайте например app note micron TN-41-08. В этом документе, в конце, есть подробно расписанные временные бюджеты.

1) так это для каких частот то?
2) нужно иметь ввиду, что общие рекомендации везде и всегда идут на грани со здравым смыслом. ну а дальше каждый сам себе злобный буратино.

Да в том и беда, что когда говорим о DDR3, то речь идет о 1866 или 2133 МГц. Низшие значения не так интересны. И тут реально начинается ловля блох...

1) Ну, не надо путать data rate и тактовую частоту. Я говорил про частоту, а она вдвое меньше.
2) Так это верно для связи DDR3 - <какой-нибудь новый чипсет от Intel> или DDR3 - <какой-нибудь новый процессор>.
А автор начал тему, упомянув DDR3 в контексте FPGA. А там таких частот сроду не было!
Вот, например, общие сведения для Альтеры по всем семействам.
Как раз что-то порядка 500 МГц на сегодня и есть. Обещают ближе к 1ГГц для новых стратиксов 5, но это когда будет то...

Я вот подключал DDR2 к Cyclone III, для скорости порядка 200/400. Работает, хотя я не заморачивался с выравниваниями длин. Специально их не портил, конечно, но разброс где-то в 10-15 мм там есть.

На ДДР2 мы тоже не заморачивались выравниваниями. И так все жилО. А вот на ДДР3 все куда хуже.
Кстати, Virtex-7 например DDR3-1866 тянет, вдруг у автора как раз она.

Так вроде 7 семейство у Xilinx не вышло еще. Я вот жду Kintex-7 или Artix-7, а то пока не к чему Hyperlink от TI цеплять. А TI-то вообще разошлись - 4 пары по 12.5 Gbps каждая, в сумме один линк на 50 Gbps. Альтеры отпали сами собой... Но Kintex существует пока только в видеороликах и общих проспектах... Во всяком случае заказать девборду с ним что-то не получилось...

Свежие новости с полей: Virtex-7 начали отгружать

По теме: У меня в проекте память 1333МТ.
В документе от micron обсчитывается память меньшей частоты(1066) если точность выравнивания трасс 15пс, то запас получается равным 33пс. (20 стр.) У виртекса длинна большей части соединений колеблется от 4 до 10мм. А 33пс это примерно 5мм. Если не учитывать соединения от кристалла до корпуса, то все выравнивания на плате идут лесом...

Соблюдать эти рекомендации или нет, это ваше дело. Но тогда не нужно удивляться что "что-то работает не так".

А у Вас, если не секрет DIMM или чипы отдельные?

Не секрет. Отдельные чипы - 3шт. причем на каждый свой контроллер, т.е они не связаны в шину.
И что еще хуже приходится это все делать без write leveling, т.к микросхемы близко к ПЛИС стоят.
С DIMM даже проще наверное, чем с отдельными микросхемами - большинство app. note и примеров трассировок даны именно для DIMM.

Не, совсем как раз наоборот! Без DIMM трассы гораздо короче, в связи с чем не нужен весь этот огород с терминаторами и выравниванием. И это не шутка. Вон у TI стоят 5 корпусов DDR3 800/1600, и все работает без всяких терминаторов (см. картинку: зеленоватый цвет - это слой top, голубоватый - внутренний). И вообще, скорость 1333MT- это 666 МГц, что соответствует длине волны на текстолите около 23 см. На картинке длина линии данных получается порядка 925 мил, то есть 23 мм - в 10 раз меньше! То есть, это еще далеко не длинная линия, для которой верны рассуждения о волновом сопротивлении, скорости распространения волны и т.п. Не говоря уже о том, что у нее вообще есть какие-нибудь однородные параметры вроде распределенной индуктивности и емкости. На самом деле все определяется емкостью этой линии, которая в основном состоит из емкости с общим слоем нуля, и еще кучей паразитных емкостей со всеми соседними трассами, которые местами идут так же близко как и слой нуля.

Нет терминаторов на адресах в ДДР3? Оригинально...
А рассуждения о воновом сопротивлении, скорости распространения и т.п. верны всегда, независимо от длины линии.

Длина волны здорово, только учитывать-то надо фронт. А это в грубом приближении 1/4 волны.
Не готов спорить по оценочному расчёту, но у меня почему то впечатление, что есть ошибка. Буду посмотреть.
Если неправ - так и напишу.

+42
Нужно учитывать что форма сигнала не синус! А что-то близкое к прямоугольнику, сглаженному синусом. А такой сигнал имеет гармоники, которые определяют скорость нарастания фронта и среза. Навскидку: 3 и 5 гармоники имеют значительное влияние на форму сигнала. Значит они должны безболезненно проходить по линии. А пятая гармоника от 533МГц это 2,7Ггц...

Коллеги, я нигде не писал, что не надо учитывать фронт. Ясно, что фронт короче, чем вся волна, оценка была лишь для того дана, чтобы показать, что это еще не длинная линия. Вот возьмите камешек и киньте в воду, в появившиеся круги оформятся в волну только где-то после пары длин этой волны. А вблизи источника это по другому выглядит. Понятно, что формализм длинной линии удобен, потому что позволяет перейти от расчету емкостей проводников к простому расчету длин линий, но это идеализация, и об этом не стоит забывать.

Я не хочу, чтобы дискуссия сильно ушла от исходной темы. К сожалению, пока нет времени более подробно расписать по поводу терминаторов. Поэтому постараюсь более кратко и по существу. Вот смотрите. Для 1333МТ половина периода тактовой частоты - это 750 пс. Предположим, что окно данных - это всего треть этого интервала (на самом деле, я думаю, при боле высоких гармониках и больше), то есть окно данных - 250..400 пс. Автор начал тему с того, что хочет учитывать задержки в проводниках корпусов, разброс которых пока оценил в 30 пс. То есть, это примерно на порядок меньше, чем окно данных. При этом автор не озвучил, на что он "разбазарил" остальные 90% бюджета окна данных. Вот поэтому я считаю, что если нет четкого понимания, на что потрачены 90% бюджета, то экономия на 10% - это ловля блох.

Да что Вы длинные линии сюда мешаете... на платах ими и не пахнет. Но вопросы согласования от этого никуда не деваются.

Вы, видимо, упорно не хотите даже пролистать TN-41-08: Design Guide for Two DDR3-1066 UDIMM Systems, на который я ссылался несколько постов назад... Ну раз так, то привожу страничку с примером "разбазаривания" времени.
Нажмите для просмотра прикрепленного файла

Так это, там ключевое слово - UDIMM - в названии. Это не то же самое, что и отдельные корпуса борт в борт с ПЛИС.

Добавление:
Кстати, если Вы заметили, в этой табличке понятие total skew состоит из трех слагаемых, два из которых составляют 80% от суммы, и называются memory controller skew, то есть взяты в расчет с некоего потолка, описывают некоторый среднестатистический контроллер, а вовсе не тот конкретный, что стоит у Вас в ПЛИС. И в итоге в общем бюджете все согласования длин как таковые составляют 15 пс из 450, то есть 3%. А если еще вернуться к собственно обозначенной теме - задержке от кристалла до вывода микросхемы, то из 15 пс придется вычесть те 10, которые относятся к трассам на плате. И в итоге останется та самая блоха - 1%, о котором я говорю. Все учебники по оптимизации гласят, что если берешься что-то оптимизировать, то ищи сначала те факторы, которые дают наибольший вклад в явление.

Да я собственно, не уговариваю делать так как написано. Каждый трактует информацию как ему угодно. Не хотите делать как рекомендует Micron, TI, Altera, Xilinx - Ваше право!
ИМХО топик скатился в оффтопик. Предлагаю эту тему дальше не развивать.

Подскажите, чем обусловлено требование на максимальную длину трассы?
В рекомендациях на любой чип или контроллер оно есть, но как его получить?

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

А в каком месте хранится PIN_DELAY у компонента? В уго, футпринте или отдельно?

В редакторе плат: File-Import-Pin Delay. Можно другой магией но это самый простой путь.

Хороший вопрос... Не знаю точно есть ли в Capture возможность их задать, но в Authoring точно была непосредственно на уровне схемныой библиотеки. А реально как правило уже на уровне BRD-файла они участвуют, непосредственно туда и импортировал такие данные, либо из референсов, либо сам писал файлы с инфой о Pin Delay, ничего сложного в них нет.

Задача - раздобыть задержки из дизайна или библиотеки для конкретного корпуса.
В библиотеке уго не нашел. Где копать дальше?

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

Спасибо!