Здравствуйте.

Смотрю как выглядит PAD в редакторе "Resource Property Editor".
Вижу элемент "Input Pin To Logic Array Delay" на входе, и элемент "Output Pin Delay" на выходе.
Если сделать правый клик мышкой по этим элементам, то появляется выпадающий список
с вариантами значений задержки. Активный вариант - 0ps.
Можно ли как-то управлять этими задержками?
Как мне явно объяснить квартусу, что нужен другой вариант отличный от нуля?
Подозреваю что скрипты для TimeQuest могут повлиять,
но если существует вариант явного задания задержки без TimeQuest, то хочется о нем узнать.

История вопроса.
Использую контролер HPC2 для DDR2.
Иногда сбивается один и тот же разряд данных.
Хочу его принудительно подвинуть.

Теоретически квартус сам должен устанавливать оптимальные задержки исходя из констрэйнов. Чтобы его насильно сподвигнуть - есть специальные констрэйна, типа Input Delay, Output delay, Dx Delay - зависит от типа кристалла. Назначается через Assignment Editor для конкретного пина или группы пинов.

Для Cyclon3.
Действительно, в Assignment Editor есть опции
Delay from Output Register to Output Pin. Можно задать варианты [0..1].
Input Delay from Pin to Internal Cells. Можно задать варианты [0..6].

можно в .qsf файле вручную прописать, например

если есть возможность и знаете что хотите.

HPC2 на этапа инициализации пишет/читает разные последовательности ноликов и единичек и на основе полученных задержек сам выставляет оптимальные. То есть если local_init_done поднимается в '1' после включения питания стабильно - то задержки подобраны и проблем быть не должно. Смотрите "железные" проблемы - питание, перекрестные помехи ....
Попробуйте снизить частоту DDR2 до 125 МГц - вдруг все всплывет

Да, я слона и не увидел В этом случае все задержки определяются оптимально на этапе инициализации и ручное размещение все только испортит. Тогда тут либо проблема в физике, либо неправильно подключен сам контроллер.
to nmurzin таймквест о временных сбоях ничего не пишет? У меня с DDR3 контроллером на stratixiv проблемы были - ошибки по холдам и приходилось вручную регистры двигать. Кстати, до исправления в железе иногда работало - иногда нет, но начальная инициализация всегда проходила.

Интересно, а частота у Вас на краю возможного была? И какие исправления в железе?
Я до DDR3 еще не добрался, но Cyclone-V светит, да и Artix/Spartan-6 - так что заранее побиваюсь

Опорная 100, рабочая 300МГц, т.е. не предельная. Точное место сейчас не скажу, суть - частота *clk_div2* приходила на триггер позже данных. Я вручную регистры отодвигал от входных DDR регистров на несколько позиций, чтобы задержать данные. Если интерсно, завтра посмотрю схему подробнее и отпишусь.

Если не трудно

Тип ошибки вроде был uniphy core (setup), посмотреть сейчас не могу т.к. надо перекомпилировать все, а это процесс долгий.
Вход частоты - получен на обычном триггере из dqs, т.е. в два раза меньшая и идущая по обычной линии(*mc_phy|uniphy|p0|umemphy|uread_datapath|read_capture_clk_div2[8]|q).
Данные - выход DDR, конкретно low (*mc_phy|uniphy|p0|umemphy|uio_pads|dq_ddio[8].ubidir_dq_dqs|altdq_dqs2_inst|rea
d_data_out[4]).
И, соответственно, ошибка на триггере (*mc_phy|uniphy|p0|umemphy|uread_datapath|read_buffering[8].read_subgroup[0].ure
ad_fifo_neg|data_stored[0][4]) из-за того, что данные приходили с большой задержкой.
Изначально прижимал регистр к пинам, чтобы уменьшить время по данным , но вылазили ошибки в других местах. Было принято решение отодвинуть размещение триггера, на котором формируется частота подальше от входов dq. Это сработало.
Сам квартус это растащить не смог и при различных настройках, проблема как мне кажется в том, что в конкретном критсталле и проекте все входы-выходы размещены по вертикали и через два/четыре (в зависимости от стороны) лаба по вертикали идут банки M9K. Ну и вся логика контроллера получается довольно плотно размещена из-за памятей.