Hyperlynx DDR batch simulation, Помогите обработать результаты Опции

[uriy]

Развел плату с несколькими процами.
TMS320 + DDR3 и OMAP L138 + DDR2.
Моделирование DDR3 прошло на ура. Вот картинки



DDR2 все плохо

форма сигнала:


Что в нем плохого? Мне он кажется вполне приемлемым. И что делать с платой? Или я что-то неверно задаю в hyperlynx?

[Uree]

Нет, в ИБИСе непосредственных данных о pin delay нет.

А по поводу speed grade могу ошибаться, но там скорее речь о внутренних скоростных возможностях чипа идет(FPGA, памяти). Но на модель буфера(драйвера) оно не влияет. Да и нет в списке моделей поделенных на разные скорости, только тип буфера/драйвера, напряжение, токовые возможности, сопротивления... Еще slew rate есть, но там без вариантов - для DDR3 только fast может быть.

[yes]

Нет, в ИБИСе непосредственных данных о pin delay нет.

А по поводу speed grade могу ошибаться, но там скорее речь о внутренних скоростных возможностях чипа идет(FPGA, памяти).

ну а разве это не является pin delay-ем? то есть имеем три задержки fast, typ, slow (если они не в модели, то значит их знает сам гиперлинкс - вариантов не много и они стандартизированы) в зависимости от условий (угла) берем нужную задержку и вычитаем из бюджета - я так понимаю, что смысл этого ddr batch mode в том и состоит, что результаты симуляции сравниваются с бюджетом, учитывающим задержки в микросхемах, автоматически, а не пользователем вручную на калькуляторе

знать задержки может для микросхем памяти, а контроллер ПЛИС/процессор - видимо нужно как-то добавлять, тут я еще не разобрался

[Uree]

ну а разве это не является pin delay-ем? то есть имеем три задержки fast, typ, slow (если они не в модели, то значит их знает сам гиперлинкс - вариантов не много и они стандартизированы) в зависимости от условий (угла) берем нужную задержку и вычитаем из бюджета - я так понимаю, что смысл этого ddr batch mode в том и состоит, что результаты симуляции сравниваются с бюджетом, учитывающим задержки в микросхемах, автоматически, а не пользователем вручную на калькуляторе

Нет, это именно slew rate, т.е. скоростные возможности драйвера, время нарастания/спада сигнала. К доп. задержке на конкретном пине отношения не имеющие.

fill
1. Идею с DDR3Delays_autogenerated.txt я понял, но разбираться нет смысла - идея была попробовать этот автомат "как есть". Если нужно "допиливать", то обойдемся, на это в скедуле время не предусмотрено.
2. Да, по правильному IBIS должен генериться Quartus-ом(в данном конкретном случае) как результат проекта. Но проект этот делается не нами, а самим клиентом(мы как hardware ODM в данном случае выступаем), поэтому целевого IBIS-a у меня нет. Я его вручную составил, прописав таблицу пинов и собрав драйвера к ним. Поэтому же нет RLC-параметров для каждого пина, а есть только typical для этого корпуса. Но Pin Delay прописаны в проекте PCB, и у меня такое впечатление, что они не видны в HL, но учитываются в зависимости от используемого симулятора - при просмотре сигналов простым скопом видна отчетливая разница между данными на приемнике(т.е. просчитывается только задержка на трассе), а вот в EZwave сигналы собраны как и положено, с расбросом менее 10пс (т.е. просчитана сумма трасса + Pin Delay). Ну и в EZwave я смотрю сигналы на die, чего нет в скопе(да, в нем тоже можно выбирать тип симулятора, но специально этого не делал используя настройки по умолчанию).
3. Согласен, можно много чего помоделить, и даже пощупал такую возможность, но времени на это уходит порядочно, по крайней мере поначалу.

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

да, эта задержка вычисляется как корень квадратный из С*L.

В общем случае из этих параметров можно посчитать импеданс линии, а вот длину не получится - не хватает данных.

[fill]

В общем случае из этих параметров можно посчитать импеданс линии, а вот длину не получится - не хватает данных.

Так длину учитывать это вообще бессмысленно. Посмотрите на пример
длина одинаковая, но задержка то разная. Причем если по трассам платы задержку можно посчитать в анализаторе, то во что превращается длина внутри корпуса с точки зрения задержки знает только производитель. Ну добавили вы 10мм как длину пина и что? Как это отразится сточки зрения конкретного времени прихода сигнала на приемник?