[alexPec 3]

Всем доброго дня.

Есть полностью синхронный код, работает все от одного клока.

При симуляции в RTL  все работает как надо. При симуляции в моделсиме в gate-level тоже все работает как надо до определенной частоты (в моем случае до периода клока 14нс). Делаю 12нс - выход блока неправильный. Оно вроде как и понятно. На какой-то частоте все же блок должен загнуться.

Непонятно вот что: почему при констрейне входного клока 10 нс и, как мне кажется, верных констрейнах входных сигналов, квартус не ругается на то, что времянки при периоде клока 10нс не соблюдаются (хотя в симуляции, повторюсь, уже при клоке 12нс все ломается). Отсюда и непонятно куда копать, чтобы повысить частоту блока.

Констрейны заданы только такие:

create_clock -name clk -period 10.00 [get_ports {clk}]
set_input_delay -clock { clk } -min 0.5 [get_ports {pixelin[0] pixelin[1] pixelin[2] pixelin[3] pixelin[4] pixelin[5] pixelin[6] pixelin[7] pixelin_wen}]
set_input_delay -clock { clk } -max 7 [get_ports {pixelin[0] pixelin[1] pixelin[2] pixelin[3] pixelin[4] pixelin[5] pixelin[6] pixelin[7] pixelin_wen}]

В скриншоте видно, что квартус уверен, что все с времянками в порядке:

[RobFPGA 27]

Приветствую!
 

27 minutes ago, alexPec said:

Непонятно вот что: почему при констрейне входного клока 10 нс и, как мне кажется, верных констрейнах входных сигналов, квартус не ругается на то, что времянки при периоде клока 10нс не соблюдаются (хотя в симуляции, повторюсь, уже при клоке 12нс все ломается). Отсюда и непонятно куда копать, чтобы повысить частоту блока.

Вопрос останется без ответа пока не будет ясно что именно ломается в симе. Только тогда можно будет разобраться что и как менять.  Сим или сам дизайн.

 

Удачи! Rob.

 

[alexPec 3]

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

[RobFPGA 27]

Приветствую!

1 hour ago, alexPec said:

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

Еще  раз - пока  вы не убедитесь что  ваша модель  адекватная и  действительно работает как  требуется говорить что Qu  что то видит или нет IMHO бессмысленно.
Сравнивая  с функциональной симуляцией надо вычленить тот модуль/сигнал где происходит  ошибка. Убедится что ошибка действительно происходит, а глюки некорректной модели/сима  приводящих например к UB при  gate-level симе. Ну и тогда сравнить задержки для этих сигналов  с отчетами TimeQuest  в Qu.  Тогда  можно будет обсуждать что не так.

 

Удачи! Rob.   

[des00 25]

1 hour ago, alexPec said:

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

и проверьте что coner case в симе и в отчете одинаковый. И то что sdf нужный :)

[alexPec 3]

10 часов назад, des00 сказал:

и проверьте что coner case в симе и в отчете одинаковый. И то что sdf нужный :)

Имелось ввиду .sdo (а-ля ХХХ_7_1200mv_100c_v_slow.sdo)? Этот точно правильный, проверял уже.

А первое как проверить? Никогда не приходилось этим заморачиваться...

 

10 часов назад, RobFPGA сказал:

Приветствую!

Еще  раз - пока  вы не убедитесь что  ваша модель  адекватная и  действительно работает как  требуется говорить что Qu  что то видит или нет IMHO бессмысленно.
Сравнивая  с функциональной симуляцией надо вычленить тот модуль/сигнал где происходит  ошибка. Убедится что ошибка действительно происходит, а глюки некорректной модели/сима  приводящих например к UB при  gate-level симе. Ну и тогда сравнить задержки для этих сигналов  с отчетами TimeQuest  в Qu.  Тогда  можно будет обсуждать что не так.

 

Удачи! Rob.   

Сейчас конечно покопаю детальнее, где ломается. Но как-то это неправильно. Файл задержек .sdo в моделсим генерит квартус, на основании этих же данных он и проверяет дизайн таймквестом. И если что-то где-то не успевает - он же обязан сказать. Тем более что клок один, никаких аснхронных вещей нет. Даже сброс синхронный. Тогда вообще какой смысл в таймквесте, если он не говорит что времянки не пролазят при конкретной частоте. Получается что надо собрать проект, для соблюдения формальностей запустить таймквест, но это не гарантирует что времянки в норме - надо провести gate-level моделирование, и вот если в нем все совпадет - значит модель, приближенная к реализации в чипе, рабочая?

До сих пор если времянки в таймквесте в норме - в реальности проект работал. Но это было с более ранними версиями Quartus, с Q17 не пробовал еще, первый раз столкнулся.

 

[des00 25]

23 hours ago, alexPec said:

Имелось ввиду .sdo (а-ля ХХХ_7_1200mv_100c_v_slow.sdo)? Этот точно правильный, проверял уже.

А первое как проверить? Никогда не приходилось этим заморачиваться...

Да в отсчете у вас написано что модели одинаковые 1.2В, 100градусов, медленная модель. 

 

23 hours ago, alexPec said:

До сих пор если времянки в таймквесте в норме - в реальности проект работал. Но это было с более ранними версиями Quartus, с Q17 не пробовал еще, первый раз столкнулся.

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