Скомпилировал исходный проект в двух квартусах, результат во вложении. Верхняя картинка Q12.1, нижняя картинка Q15.0.2. Вы в каких квартусах пробовали?.

У меня 13, у des00 -- 14.
Предлагаете откатиться на 12?

Ну я пока с 12.1 не соскакиваю...
Стоп,вспомнил - в новых версиях Квартуса поставили уточнённые задержки,поэтому времянки и валятся. Так что ,похоже, синие слэки в Q12.1 ещё не факт что всё будет гут в железе...


А вы читали альтеровский документ "Implementing a Source Synchronous Interface between Altera FPGAs"? Они для подобного интерфейса совсем не брезгуют виртуальным клоком.

Читал, физику и логику этого решения тоже не понял, потому и прошу объяснить. Мой вариант основан на физике процесса и логике здравого смысла.

Эта картинка вам понятна?

а так вообще последние квартусы глюкодромы у меня тут ни с того ни с сего ква стал складываться через 5 секунд после начала сборки. Причина оказалась в том, что сигнал таповский файл стал больше 4 гиг (как я понимаю это банальное описание какие сигналы зырить). не понимаю такого.


картинка да, но сразу идет логическая цепочка : производитель чипа гарантирует выравнивание clk_out и data_out во всех режимах эксплуатации чипа -> зачем создавать виртуальный клок и вписывать кучу параметров, если все можно сделать проще?

Из неё непонятно, зачем использовать какой-то виртуальный клок, если есть вполне реальный clock_out.

Ну так в логе и пишется: временные характеристики чипа предварительные.
У меня тоже есть эти сомнения. И таки шо делать?

Думаю что нельзя сказать что один метод хорош,другой плох. Тут видимо дело вкуса(физический смысл от метода не зависит). А сама Альтера говорит так:

Вобщем, я тоже глубоко не копал.


А подвигать фазу клока не пробовали?

пропустить DCO через PLL, на ней сформировать 2 клока: для IO регистров и для регистров на чипе.

Если делать так, то немедленно появляются hold slack'и непосредственно в IOCELL. И мне не удалось подобрать сдвиг, чтобы их не было. Это в дополнение в setup slack'ам на прежних местах. То есть всё становится ещё хуже.

Если DCO заводить на IO, а выход PLL в ALM, то получаем то же самое, что и начальная ситуация. И тоже не удаётся компенсировать все slack'и сдвигом тактовой.

В общем, ситуация такая: сдвиги тактовой (одной или обеих) лечат одни slack'и, но дают другие. При некоторых сдвигах в дополнение к setup slack'ам появляются hold slack'и.

Минус в использовании PLL я вижу в том, что DCO может быть разной. Как PLL на это будет реагировать?

Если PLL не переконфигурировать то допустимые частоты будут определяться коэффициентом перестройки частоты ГУН.
С IOCELL отдельная песня,не пытайтесь сразу решить две проблемы. А в принципе вам удаётся подобрать такую фазу что слэки в регистрах уходят? Вместо ФАПЧ ещё можно попробовать цепочку LCELL нужной длины, но тут есть риск и он должен быть осознанным.

Меня сейчас растопчут ногами, но я давно уже махнул рукой на временной анализ I/O для взаимодействия с АЦП/ЦАП. Ибо гарантированной работоспособности так толком добиться и не смог. Где-то тут на форуме были мои страдания на эту тему. Вместо этого делаю регулируемую задержку в пине и выбираю оптимальное значение задержки путем натурных испытаний (или кручу фазу клока PLL как альтернативный вариант.

В принципе нет.
Вот какая штука получается.
Я экспериментировал с такой схемой: IO тактируются напрямую DCO, регистры -- клоком с выхода PLL, фазу которого я подбирал. PLL работает в режиме source synchronous.
При фазе 0 слаки лежат в диапазоне -2.056...-1..771 нс. Этих слаков 18 из 24.
Далее начинаем двигать фазу клока с шагом 15 градусов (1/24 периода или 4/24 ~ 0.17 нс).
При сдвиге +15 градусов в слаках оказываются все 28 триггеров, диапазон слаков -5.890...-3.417 нс. Ну, оно и понятно: -5.890 = -2.056 - 4 * 23/24.
Дальнейшие сдвиги приводят к уменьшению слаков пропорционально величине сдвига, но в пределе получаем те же изначальные -2.056...-1..771.

Если приглядеться к диапазону -5.890...-3.417 нс, то можно увидеть, что часть слаков меньше периода клока, а часть больше. То есть задержки по данным таковы, что часть шины таксть "лежит" в одном периоде, а часть в другом. И тут как клок ни двигай, ничего не получится.

Втыкание LCELL -- это крайний случай, НЗ. Очень бы не хотелось его использовать.

[attachment=95765:sms2.png]
Я правильно нарисовал ситуацию которую вы описали?


Здесь || - фронт-источник и фронт-приёмник. Может просто ввести мультициклы? Это не ваша ситуация?На картинке задержки превышают период тактовой,это не страшно, здесь главное чтобы разброс задержек в шине был меньше тактового периода,а подбором фазы уже обеспечить надёжный приём.

Раз уважаемая общественность молчит то есть повод думать что втихаря все понемногу делают это.