Цитата(Cordroy @ Apr 13 2014, 09:25)
Это первое же над чем думали. Проблема автоматически, в существующем большом коде, найти "нужное место".
В начале поста я показал картинку для примера: один и тот же флоп может принимать данные и по multicycle контуру, и по обычному, без задержек (предположите что внутри облака просто mux).
Я так понял, что вы писали в предположении, что есть те кто писал этот код и добавлял констрейны multicycle.
А если код пришел как есть, то в принципе по самому констрейну, если его перепроверить тоже можно добавить такие задержки руками.
Скриптом - не пройдет, тк он не проверит какой путь и где удобней вставить задержку.
Как минимум вижу два варианта, даже для случая, который вы описали
1. Внутри есть mux (если он описан не через assign, а через always * - то также можно вставить задержку перед нужным присваиванием в пути (подобно как в регистре). * assign при это надо будет переписать через always *
2. По констрейну multicycle - видно что есть инициирующий триггер.
И если он имеет только одно подключение через mux к нужному триггеру - то можно задержку присваивания перенести на инициирующий триггер, как задержку выдачи.
Это конечно, не сделать с помощью скрипта, но эти два варианта при ручной проверки частично реализуют задачу проверки multicycle уже на уровне RTL.
Симуляция multicycle на стадии RTL верификации, вопрос
Apr 13 2014, 05:48
