[novartis 0]

Есть модуль, который формирует 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

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

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

 

[Yuri124 1]

set_max_delay

[lexx 0]

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

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

[novartis 0]

9 hours ago, Yuri124 said:

set_max_delay

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

4 hours ago, lexx said:

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

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

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

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

[lexx 0]

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

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

[des00 25]

19 hours ago, novartis said:

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

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

[Yuri124 1]

10 hours ago, novartis said:

надо в паре с set_min_delay

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

Изменено 6 февраля, 2019 пользователем Yuri124

[des00 25]

1 hour ago, Yuri124 said:

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

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