[KWIer 0]

Привет.

Я пытаюсь описать временные ограничения для проекта с 8-разрядной шиной DDR. Я взял образец документа из вики и сопроводительную документацию, предоставленную пользователем Rysc (https://fpgawiki.intel.com/wiki/File:Source_Synchronous_Timing_Projects.zip). Пример № 2 - приемник, тактовые импульсы по центру данных, скомпилировал в Quartus v11 как есть - тайминги выполняются. Я заменил FPGA на Cyclone IV (speedgrade 7), увеличил частоту pll до 150 МГц, скорректировал sdc-файл - времянки все еще в порядке.

 

Затем я открываю тот же проект в новых версиях quartus 13.1, 16.1, 18.0 - обновляю мегафункции PLL/ALTDDIO_IN и перекомпилирую - тайминги терпят неудачу!

Что может быть причиной этого? Несколько вариантов:

1. В версиях выше 11, фиттер был переписан, и он не оптимизирует размещение так тщательно.

2. Добавлены дополнительные проверки по времени, которые просто не выполнялись в более ранних версиях.

3. Специально ухудшили ip-core / fitter, поэтому мы должны покупать более скоростные FPGA. Я не могу поверить, что Cyclone IV не может получать данные с частотой 150 МГц / 300 МBPs с помощью altddio_in.

 

Прикрепить архив с отредактированным проектом для тактовых импульсов 150 МГц не получилось. Ссылка на него https://cloud.mail.ru/public/ACnv/NpTj4rEGk

 

Всем заранее спасибо за идеи!

[wolfman 0]

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

Ну и почитать документацию на 4 циклон тоже стоит.

 

[KWIer 0]

12 hours ago, wolfman said:

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

Ну и почитать документацию на 4 циклон тоже стоит.

 

В том то и дело, по документации, LVDS должен работать на прием с частотой до 402.5 МГц

 

Файл с констрейнами подцепляется нормально, видно по отчетам в Timequest. Но всё в слаках по Hold

 

[ZwergNase 0]

Я вижу что в sdc у вас клок ssync_rx_clk от внешнего устройства сдвинут на 90 градусов, а latch clock в тайминг репорте другой, видимо от вашей pll на которую приходит  ssync_rx_clk . И на этом latch clock набегает задержка 2.676 нс и в этом наверно проблема. Если в pll добавить такой фазовый сдвиг, чтобы компенсировать slack 0.22 нс, то тайминг по hold должен сойтись. Конечно, если у вас есть достаточный slack по setup.

 

Ещё одно соображение по задержке 2.676 на latch clock. Возможно квартус разместил pll из которой выходит latch clock в другом месте, т.е. дальше чем было раньше и поэтому появилась дополнительная задержка. Чтобы это проверить, надо посмотреть задержку latch_clock которая была, когда тайминги выполнялись и проверить, где размещается pll в том и другом случае.

[KWIer 0]

Спасибо за интерес к данному вопросу! 

Подробности - пример взят из руководства Rysc - Source Syncronous Timing (Case 2: The FPGA is the receiver and does not phase-shift the clock). Pll в режиме Source-synchronous compensation, сдвига по фазе в pll нет. Непонятно почему в новых версиях Квартус не уладывается в тайминги, а в старых все хорошо?

Назначения выводов данных и тактов не определено, фиттеру развязаны руки.

Вот несколько репортов.150 МГц - Quartus 11 - Слаки положительные.  EP4CE6E22A7. Как в архиве в 1 посте.

Отчет по Hold:

 

Отчет по Setup:

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Тот же проект, в Quartus 16.1. Обновил ALTDDIO_IN,ALTPLL -перекомпилировал проект. Слаки отрицательные по Hold.

 

 

[KWIer 0]

2 hours ago, Zwerg_nase said:

Я вижу что в sdc у вас клок ssync_rx_clk от внешнего устройства сдвинут на 90 градусов, а latch clock в тайминг репорте другой, видимо от вашей pll на которую приходит  ssync_rx_clk . И на этом latch clock набегает задержка 2.676 нс и в этом наверно проблема. Если в pll добавить такой фазовый сдвиг, чтобы компенсировать slack 0.22 нс, то тайминг по hold должен сойтись. Конечно, если у вас есть достаточный slack по setup.

 

Ещё одно соображение по задержке 2.676 на latch clock. Возможно квартус разместил pll из которой выходит latch clock в другом месте, т.е. дальше чем было раньше и поэтому появилась дополнительная задержка. Чтобы это проверить, надо посмотреть задержку latch_clock которая была, когда тайминги выполнялись и проверить, где размещается pll в том и другом случае.

Сравнил по размещению PLL - используются одинаковые входные PINы в обоих случаях, теже IOBUF, PLL, CLKCTRL, а вот дальше Фиттер зачем-то развел на разные FF.

 

2) Запас по Setup был, сдвинул фазу на -500ps - тайминги в норме, по 300ps в запасе по Setup и Hold. Но вопрос почему фиттер в новых версиях не смог сделать то что делал без проблем в ранних версиях, остается открытый!

[KWIer 0]

Для интереса скомпилировал проект в Quartus 18.1 под Linux, менял корпуса на BGA (они по задержкам на выводах отличаются от QFP), уменьшил ширину шины данных до 1 разряда, жестко задавал pin placement, прогнал 15 итераций исходного проекта с разными сидами в Design Space Explorer II (18.0). Ни одна из итераций так и не уложилась в тайминги. 

[ZwergNase 0]

Я вижу, что принципиальное отличие в значении data_path при расчёте Data Arrival Path для hold: 1.667 (когда slack -0.222) и 2.286 (когда slack +0.398).

Это может быть, например, когда в первом случае в проекте задан более скоростной чип. 

[KWIer 0]

15 hours ago, Zwerg_nase said:

Я вижу, что принципиальное отличие в значении data_path при расчёте Data Arrival Path для hold: 1.667 (когда slack -0.222) и 2.286 (когда slack +0.398).

Это может быть, например, когда в первом случае в проекте задан более скоростной чип. 

Я тоже это заметил, но чип специально выбирал одинаковый в обоих случаях - EP4CE6E22A7. 

Подскажите, есть ли способ в ручную заставить quartus использовать LCCOMB_X1_Y18_N28 вместо LCCOMB_X1_Y18_N4? Где можно почитать как это сделать?

Хочу проверить, уложится ли в тайминги если вручную прописать путь. Никогда раньше этого не делал, полностью доверял фиттеру, видимо зря.

 

[KWIer 0]

Так, похоже всё дело в PLL. В новых версих при использовании Source Compensation Mode появляется Warning 

Warning (176441): The I/O pin RX_DATA[7] cannot meet the timing constraints due to conflicting requirements. The I/O pin is a PLL compensated I/O, but the setup/hold requirements are in conflict with the source PLL mode(source synchronous or ZDB).
Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[6] since it's a PLL compensated pin
Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[5] since it's a PLL compensated pin
Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[4] since it's a PLL compensated pin
Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[3] since it's a PLL compensated pin
Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[2] since it's a PLL compensated pin
Info (176440): Auto delay chain can't change the delay chain setting on I/O pin RX_DATA[1] since it's a PLL compensated pin
Warning (176441): The I/O pin RX_DATA[0] cannot meet the timing constraints due to conflicting requirements. The I/O pin is a PLL compensated I/O, but the setup/hold requirements are in conflict with the source PLL mode(source synchronous or ZDB).

1) Я всегда считал, PLL в этом режиме наоборот должен улучшать времянки, за счет подстройки по входной частоте.

2) Если PLL вообще исключить, то запас по слакам ~0,7 ns и по Setup и по Hold

[ZwergNase 0]

Я тоже не разводил клоковые пути вручную. Думаю, что делать это в четвёртом Циклоне как-то уже чересчур)

Я бы попробовал включить PLL в Normal Mode. Мне кажется, что Source Syncronous не подходит для center-aligned data.

[KWIer 0]

Intel рекомендовала добавить дополнительные назначения в проект. 

С ними всё ок по таймингам. Осталось только узнать как и откуда они взяли эти числа? И почему фиттер сам не может до этого догадаться?

[ZwergNase 0]

Наверно это задержки, чтобы компенсировать слишком маленький data path arival (1,7 нс), чтобы сделать его ближе к 2,3 нс. Скорее всего это какая-то проблема в квартусе. Возможно, они починят её в следующей версии.

Я думаю, что это вполне обычная ситуация. Фиттер, плэйсер и рутер в квартусе постоянно оптимизируются и могут значительно отличаться по используемым алгоритмам от версии к версии. Четвёртый циклон довольно давний чип, возможно интел уже не тестирует на нём свой софт начиная с каких-то версий.