Перейти к содержанию

    

false_path и multicycle_path между регистрами

Есть модуль, который формирует 32 разрядный регистр reg32 и одноразрядный сигнал valid для него. Тактируется это частотой clk, сигнал valid выставляется на один такт, между валидами гарантированно достаточно большие паузы (ну скажем 100 тактов).

Я передаю эти два сигнала в другой модуль, тактируется он тоже частотой clk.

Во втором модуле можно по простому написать:

always @(posedge clk)
  begin
    if (valid == 1'b1)
      reg32_r  <= reg32;
  end

Но тогда квартус будет думать, что reg32_r меняется на каждом такте, предъявляет жесткие требования по частоте, подтягивает модуль 2 поближе к модулю 1.

Я пользовался следующей техникой. Задерживал валид на несколько тактов, защелкивание reg32_r делал через два такта от валида и прописывал false path между reg32 и reg32_r :

reg valid_z0;
reg valid_z1;

always @(posedge clk)
  begin
    valid_z0  <= valid;
    valid_z1  <= valid_z0;
    if (valid_z1 == 1'b1)
      reg32_r  <= reg32;
  end

Логика у меня была такая, что квартус разводит reg32_r и reg32 не зависимо друг от друга, как ему удобно, во втором модуле reg32 появляется через скажем 1.5 такта клока, и когда я к нему обращаюсь во втором модуле в момент времени valid_z1, то эти данные стабильные.

Но сегодня призадумался, а что если квартус так разведет проект по очень большому кристаллу, что reg32 появляется через скажем 3.5 такта клока, и тогда моя схема не работает корректно.

Вроде можно попробовать прописать мультицикл на путь между этими двумя регистрами.

set_multicycle_path -from {reg32} -to {reg32_r}  -setup -end 2
set_multicycle_path -from {reg32} -to {reg32_r}  -hold -end 1

То есть я рассчитываю, что квартус разведет с небольшим расслабоном, но если не уложится в два такта, то репортнет.

Никогда не использовал констрейном мультицикл. Верный подход?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Можно оставить только  "to". Других сигналов там нет.

Но главное, а зачем это все? Регистры не так и много занимают, это ничего не меняет.  Сетап и холд все равно равны одному таковому сигналу. Я не вижу причин ломать рабочую схему и прописывать кривые тайминги. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
9 hours ago, Yuri124 said:

set_max_delay

тоже вариант,  встретил фразу, что это больше для входных пинов и надо в паре с set_min_delay

4 hours ago, lexx said:

Но главное, а зачем это все? Регистры не так и много занимают, это ничего не меняет.  Сетап и холд все равно равны одному таковому сигналу. Я не вижу причин ломать рабочую схему и прописывать кривые тайминги. 

я вижу причины)

Схема рабочая, но не оптимальная, а когда появляются отрицательные слаки, то уже и не рабочая.

Да и фальш пэс и мультицикл - это не кривые тайминги, а одни из рекомендуемых вендром способы описания временных ограничений.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

False path & multycycle path две очень сильные и сильные конструкции и использовать их лучше там,  где он  действительно нужны. В вашем случае необходимость их неявна, изначально рабочая конструкция меняется на "непонятно что".

Работайте с кодом, поставьте делитель частоты.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
19 hours ago, novartis said:

Никогда не использовал констрейном мультицикл. Верный подход?

Верный. Часто делаю также.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
10 hours ago, novartis said:

надо в паре с set_min_delay

В данном случае - не нужно, раз у Вас сигнал валидности появляется на несколько тактов позже, чем данные готовы, а данные будут валидны еще сотню  тактов после него. Т.е. они гарантированно не исчезнут к моменту передачи их в следующий регистр.

Изменено пользователем Yuri124

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
1 hour ago, Yuri124 said:

В данном случае - не нужно, раз у Вас сигнал валидности появляется на несколько тактов позже, чем данные готовы, а данные будут валидны еще сотню  тактов после него. Т.е. они гарантированно не исчезнут к моменту передачи их в следующий регистр.

Правильно, в данном случае set_max_delay использовать дОлжно) но вообще есть еще команда set_net_delay, раньше не применялась она к сборке, была чисто информативной. Как сейчас незнаю.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти