[_sda 0]

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

quest.doc

[andrew_b 14]

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

У меня 13, у des00 -- 14.

Предлагаете откатиться на 12?

[_sda 0]

У меня 13, у des00 -- 14.

Предлагаете откатиться на 12?

Ну я пока с 12.1 не соскакиваю...

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

 

вы используете сферического коня в вакууме (виртуальный клок).

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

[des00 25]

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

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

 

[_sda 0]

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

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

[des00 25]

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

 

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

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

[andrew_b 14]

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

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

 

Стоп,вспомнил - в новых версиях Квартуса поставили уточнённые задержки,поэтому времянки и валятся.

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

Так что ,похоже, синие слэки в Q12.1 ещё не факт что всё будет гут в железе...

У меня тоже есть эти сомнения. И таки шо делать?

[_sda 0]

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

You can create
input delay constraints relative to the input clock instead of the virtual clock, but
using a virtual clock makes the constraining of the interface easier and more accurate.
A virtual clock makes it easy to constrain inputs with the skew-based FPGA-centric
approach. You can use the positive and negative skew requirement values for the
input maximum and minimum delay constraints with no other calculations. Even if
the source or destination clock is shifted, the input maximum and minimum delay
values do not change.

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

 

И таки шо делать?

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

[des00 25]

У меня тоже есть эти сомнения. И таки шо делать?

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

 

[andrew_b 14]

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

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

 

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

 

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

 

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

[_sda 0]

Если PLL не переконфигурировать то допустимые частоты будут определяться коэффициентом перестройки частоты ГУН.

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

[alexadmin 0]

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

 

[andrew_b 14]

А в принципе вам удаётся подобрать такую фазу что слэки в регистрах уходят?

В принципе нет.

Вот какая штука получается.

Я экспериментировал с такой схемой: 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 -- это крайний случай, НЗ. Очень бы не хотелось его использовать.

[_sda 0]

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

Я правильно нарисовал ситуацию которую вы описали?

____||----|____|----|____
ххххххxxxxxххх<=>xxxxxxx
---|____|----|____||----|____

 

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

[_sda 0]

Меня сейчас растопчут ногами, но я давно уже махнул рукой на временной анализ I/O для взаимодействия с АЦП/ЦАП.

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