Всем привет,

помогите еще раз пожалуйста, не могу разобраться упираюсь ли я в теоретический пик, или есть какое-то решение...

Есть оцифровщик, который валит по 8 лвдс на ужасной скорости данные. Надо их собрать и распараллелить, послав по 56 ногам, но, уже в 3.5 раза медленнее. Хочу потренироваться на кошках, то есть, например, на одной терасиковской борде DE2.

У оцифровщика есть два клока: фрейм и дата клоки, фрейм работает на частоте Х по двум фронтам, а дата клок - на скорости Х*3.5 по двум фронтам. В пике Х=125МГц, сейчас мои кошки тренируются на Х=800/7МГц, то есть около 114МГц при датаклоке 400МГц.

Пытаюсь скомпилить функцию, и не вписываюсь по Fast 1200mV Minimum Pulse Width со слаком в -0.4нс, в Slow все в порядке.
Понимаю, что если уронить частоту до 98МГц, то все получиться, но вдруг можно работать на большей частоте? У меня и так оцифровщик на 125МГц расчитан, и для меня падение с 125 до 98 МГц уже будет существенным. Вдруг я что-то не так делаю, не так с данными по двум фронтам работаю, и что-то не понимаю, посоветуйте, пожалуйтса!



Спасибо

ИИВ

А вы смотрели, что вам Кактус нагенерил из вашего платформенно-независимого кода?
Найдите в Кактусе аналог ксилинковского FPGAEditor и посмотрите - солидные люди, помнится, мне утверждали, что оно есть в Кактусе.

Я обычно, для достижения максимальной производительности хилых спартанов, вручную вставляю IDDR, ODDR примитивы в код.

1. С какого перепугу Вы решили, что будет работать на 400 МГц по двум фронтам? Вот где об этом написано в даташите? Если быть более точным, то там совсем другие данные приводятся. Например, о том, что DDR стандарты имеют порядка 200 МГц всего, см. страницу 1-3 книжки по C4.
2. Можно просто устроить ввод данных на высокой частоте, вдвое большей, чем частота линии данных. Тогда задачка будет тривиальной. Вводится поток в регистр сдвига, который потом раз в N тактов переписывается в параллельный регистр, а из него в такой же регистр, но уже тактируемый на уменьшенной частоте. Попробуйте так сделать, результат Вас удивит. Частота IO может быть поднята до 400 МГц запросто для I/O, а для true LVDS аж до 840 МГц, но я не уверен, что на 840 может что-то внутри кристалла дергаться. Но на 400 будет шевелиться все на любом спидгрейде.

Приём данных на такой частоте требует заведения клока через PLL/DLL с внутренним фидбэком в режиме компенсации задержки на clock tree.
Входные регистры обязательно надо описывать через специализированные DDR примитивы. И задать констрейны для setup/hold входных данных. Судя по тому, что Вы получили ошибку только на частоту клока, это сделано не было, иначе ошибок было бы гораздо больше.
Кстати, если на 4 циклоне, как на третьем, нет встроенных IO DDR регистров, то с вашей задачей он не справится. Из лоукостов на 400 DDR LVDS точно специфицированы Lattice ECP2 и ECP3.

Дорогие коллеги,

спасибо Вам большое, что отвечаете и не оставляете меня одного с этой незадачкой.



Я не нашел 200МГц в главе 1-3 по С4, но на странице 359 в таблице 1-24 для моего EP4CE115 со 7-мым спидгрейтом приводится внутренняя частота в 437МГц. Далее на странице 365 в таблице 1-34 частота чесного ЛВДСа для моего кристалла приведена как 402.5МГц. Из этого я сделал вывод, что вытащить параллельно по каждому фронту данные можно хотя бы по 402.5МГц овой частоте, а, если потом демуксить, пайплайнить, то получу то, что мне надо. Действительно, у меня не наблюдается слаков в Slow 0-85С на 402МГцовой частоте по двум фронтам, но есть слак по ШИМу в Fast 0С. Вот это-то мне и кажется странным, так как, как я понимаю, это характеризует что-то, что не проходит по внутренней частоте, но недостаток в знании и пользовании квартусом не позволяет мне определить где именно происходит затык. На частоте в ДДР 344МГц слаков нет вообше, но мне очень хочется работать на большей частоте именно на этом кристале и без привлечения какой бы то ни было дополнительной промежуточной электроники.


убедительно прошу Вас посмотреть внимательнее на то, что у меня в стартовом топике, там именно то, что Вы написали - демукс в 7 раз, передача на 57МГц всего в пайплайн, и вытаскивание данных из пайплайна по 114МГц по широкому каналу.

Переписал по совету VladimirB все через мегафункцию altddio_in, к сожалению, с частотой ничего не изменилось, правда уменьшилось использование лутов.

Чтоб быть не голословным, аттачу весь проект как есть, возможно, так будет проще показать мою проблему. Вдруг кто-то мне что-то сможет посоветовать, буду Вам премного благодарен!

Спасибо

ИИВ

PS: редактировал, так как забыл аттачмент

К вечеру честно не осилил прочитать такой объем слов...
Я так понимаю, что суть вопроса изначально в том, чтоб принять данные на 800МГц по lvds и дальше их прогнать через DDR по срезу/фронту тактовой 400, а потом каким-то образом дальше обработать? Если так, то я сейчас лопачу данные на 1000МГц и тактовой в 500Мгц правда на стратиксе 4. Для этих целей использую altlvds_in. Все работает вроде без проблем.
Единственное, для сериализации на два я не смог задать сдвиг клока относительно данных, чтоб тактовая попадала точно в окно данных (у меня там нет возможности подстройки) и пошел немного по другому пути. Советую убедиться, что Ваш клок сдвинут относительно данных на 90 градусов на gate моделировании и после компиляции в отчете фиттера не было игнорирования о сдвиге. Задайте в timequest входной клок и убедитесь, что сгенерированный клок от функции altlvds относительно исходного сдинут на 90 градусов...
PS Можно, кстати, и не заморачиваться с моделированем, а просто в timequest в report path проследить задержку от пина данных до ddio и от пина клока до pll а потом от pll до ddio. Чтоб правильно все работало требуется опять же убедиться, что тактовая сдвинута относительно данных на 90 градусов.

Сообщение отредактировал bogaev_roman - Jul 20 2011, 17:23

Спасибо Вам, Роман,
за Ваши советы и комментарии!



примерно да, но с ньюансами, а именно, на 3-ем стратиксе, 3-ем циклоне с 6-ым спидгрейтом - все ок, то есть можно работать на частоте данных 437МГц по обоим фронтам (мне это и надо), а на 4-ом циклоне с 7-мым спидгрейтом квартус ругается на любые частоты выше 344МГц...

Про идею со сдвигом - очень классно, что Вы напомнили, спасибо. Так как клок задается вместе с данными, и он уже сдвинут как надо, а мой внутренний PLL клок развязан с ним по FIFO, то проблем, как я понимаю, не должно быть.



простите, покорнейше, начинающего, вот попросил я timequest в report path показать задержку от всех пинов лвдса до выхода ddio и получил таблицу: Total, Incr, RF, Type, Fanout.... Скажите, пожалуйста, а где находится эта задержка и туда ли я смотрю?

Спасибо

ИИВ

total - суммарная задержка, соответственно можно проследить весь путь сигнала хоть по элементам (location), начинается все с определенного пина, затем проход через ioibuf, затем ddioincell. Ну и цифры там показывают сколько набегает задержек на каждом элементе и их связях. Если считаете, что у Вас изначально тактовая и данные смещены как надо, то задержка до элемента ddio данных и тактовой должна быть примерно одинаковой и так для каждого DDR регистра с погрешностью.

Добрый день, Роман,

благодарю Вас за, как всегда, исчерпывающие ответы!



посмотрел, примерно половина (0.7нс против 1.66) и все одинаково по всем ногам. С этим вроде разобрался, огромное Вам за это спасибо!

Остается вопрос, который у меня был изначально - что я делаю не так, что абсолютно одинаковый проект на EP4CE115F29C7 показывает только 344МГц по двум фронтам, в то время как тот же проект без слаков компилится для EP3C25F324C6 на частоте 437МГц. Уж больно большая разница в 25% при переходе с 3 циклона 6-ого спидгрейда на 4-тый циклон 7-мого спидгрейда, которую я нигде не смог подтвердить по документации...

Спасибо

ИИВ

не пойму вашего удивления, сыклоны 3/4 сделаны на одной архитектуре (лишние 5 нан не в счет) + у с4 меньше питания ядра (помните, что при разгоне процев повышают напряжение) и у альтеры чем меньше цифра, тем быстрее чип (в порядке убывания скорости, в пределах одного семейства c5 > c6 > c7 > c8)