TimeQuest. Борьба со slack., Задержки межд Fast input register/DDR reg и регистром приёмником. Опции

[Flip-fl0p]

Работаю c чипом CYCLONE V - 5CSEMA5F31C6. САПР - Quartus 13.1.
Столкнулся с проблемой, что между Fast input register или выходами DDR регистра и регистром-приёмником данных набегает огромная задержка по данным. Из-за чего возникает нарушение по setup.
Для начала опишу кратко дизайн:
Имеем 3 приёмные LVDS линии c DDR регистрами. На вход CLK подается опорная частота, которая на PLL умножается на 10 5, для тактирования приёмников.



TimeQuest радостно сообщает о том, что у нас нарушение по setup и фиг вам, а не частота приёмников выше 200...230 MHZ.



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


Может Quartus расположил регистры приёмники в другом конце чипа ?
Да нет, ближе практически некуда:



На данный момент у меня есть 2 мысли как можно решить проблему:
1. На pll сформировать частоту со сдвигом, и от неё тактировать регистры-приёмники.
2. На LCELL сформировать цепь задержки тактового сигнала регистров приёмников(тупиковый вариант).

Хотелось бы услышать совета от более опытных коллег. Может есть какой-то другой способ решения проблемы ?
Пока мой SDC файл выглядит так:

Код

#**************************************************************
# Create Clock
#**************************************************************
set_time_format -unit ns -decimal_places 3
create_clock -name {CLK}  -period 80MHz [get_ports {CLK}]

#**************************************************************
# Create PLL Clock
#**************************************************************
derive_pll_clocks

set_false_path -from [get_clocks {MY_PLL_COMP|my_pll_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk}] -to [get_ports {RX0}]
set_false_path -from [get_clocks {MY_PLL_COMP|my_pll_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk}] -to [get_ports {RX1}]
set_false_path -from [get_clocks {MY_PLL_COMP|my_pll_inst|altera_pll_i|general[0].gpll~PLL_OUTPUT_COUNTER|divclk}] -to [get_ports {RX2}]

Прикрепляю тестовый проект:

Сообщение отредактировал Flip-fl0p - Aug 9 2017, 07:32

Прикрепленные файлы

 LVDS_RX_3CHANNEL.7z ( 368.83 килобайт ) Кол-во скачиваний: 18

 

[Flip-fl0p]

Остался ещё один нерешённый вопрос. Почему Quartus удалил частоты С1 и С2 созданные на PLL.... И оставил только С0. Он их не будет "оптимизировать" только если я каждой частоте назначу разные сдвиги фаз.
Да и почему железка то работает как положено и самое главное стабильно, имея такое нарушение по Setup ?

Сообщение отредактировал Flip-fl0p - Aug 9 2017, 15:35

[Magnum]

и почему железка то работает как положено и самое главное стабильно, имея такое нарушение по Setup ?

А что удивительного? если задержка ровно на такт у вас, то всё и работает как надо, другое дело, если вы начнете её в температуре гонять, от нулей до +70С, там могут начаться чудеса. Ну и при массовом производстве могут на разных экземплярах разные результаты получаться.

[_Anatoliy]

Упаду на хвост по теме. Не удаётся выполнить выходные времянки для ЦАП(Fclk = 100MHz,SDR,Cyclon III).

Код

set_output_delay 5 -max -clock {clk_dac} [get_ports {dac_*}]
set_output_delay -3 -min -clock {clk_dac} [get_ports {dac_*}]

Клок в плис приходит от ЦАП -> PLL -> формирование данных, fast_output_register задействован.
Вращение фазы PLL нужного эффекта не приносит. Почему-то на io_obuf задержка 5,3нс и разница на двух битах достигает 5,3 - 2,3 = 3нс.
Что посоветуете,коллеги?

Эскизы прикрепленных изображений

 

[bogaev_roman]

Что посоветуете,коллеги?

Эти ограничения из даташита (просто максимальное окно на работу при них получается всего 10-5-3=2нс)? clk_dac - это выход pll (из приведенных ограничений не видно)? Для подробного анализа можете привести схему чипланнера, на которой показаны расположения io-буферов и pll (может они по всему периметру раскиданы, так непонятно)?

[_Anatoliy]

Эти ограничения из даташита (просто максимальное окно на работу при них получается всего 10-5-3=2нс)? clk_dac - это выход pll (из приведенных ограничений не видно)? Для подробного анализа можете привести схему чипланнера, на которой показаны расположения io-буферов и pll (может они по всему периметру раскиданы, так непонятно)?

Да, из даташита. Окно действительно очень маленькое.
clk_dac - это выход pll
С чиппланером я не очень дружу. io-буфер видно, а как ещё и PLL показать?

Эскизы прикрепленных изображений

 

[bogaev_roman]

С чиппланером я не очень дружу. io-буфер видно, а как ещё и PLL показать?

Я сигналы сначала в timequest нахожу, потом правой кнопкой locate->chip planner, в окне chipplanner в show physical routing выделяю появившийся объект, слева (типа окна инструментов) можно подключить к этому объекту fan in/fan out, общее масштабирование - ctrl+колесо мыши. Таким образом можно посмотреть необходимые объекты на всей площади fpga.

[_Anatoliy]

Я сигналы сначала в timequest нахожу, потом правой кнопкой locate->chip planner, в окне chipplanner в show physical routing выделяю появившийся объект, слева (типа окна инструментов) можно подключить к этому объекту fan in/fan out, общее масштабирование - ctrl+колесо мыши. Таким образом можно посмотреть необходимые объекты на всей площади fpga.

Спасибо! Длинная линия внизу это путь клока от PLL до io_obuf. Это для dac_im[0].

Эскизы прикрепленных изображений

 

[bogaev_roman]

Это для dac_im[0].

Можно сразу все dac_im* вытащить со всеми fan-in. Чтобы понять откуда разбег в 3нс получается приведите еще и путь для другого выхода (скорее всего пины находятся между банками памяти или dsp-блоками).

[_Anatoliy]

Можно сразу все dac_im* вытащить со всеми fan-in. Чтобы понять откуда разбег в 3нс получается приведите еще и путь для другого выхода (скорее всего пины находятся между банками памяти или dsp-блоками).

А как эту * поставить?

Здесь можно выбрать только один бит из списка.
Не выходит у меня вывести всю шину. На снимке справа внизу подсвеченные синим - это мои io_obuf. Внизу по центру - PLL. Показан клок для dac_im[10]. Вроде не через весь кристалл связи идут.

Разбежка в задержках клока в пределах шины = 1,641 - 1,582 = 0,059нс. Думаю что дело не в клоке, а разбежка задержек данных в пределах шины как раз и даёт те клятые 3,0 нс...

Но ведь в лапах стоят триггеры, они ведь должны устранить этот разбег данных

Эскизы прикрепленных изображений