How to set multicycle for this design?

Thanks very much, I got it finally!

I have a question about how to set different multicycle in an easy way.

In my case, the reg2 actually has 384 bits.

And reg2 (95 downto 0) is enabled when clock_enable_counter = 0,

Reg2 (191 downto 96) is enabled when clock_enable_counter =1,

Reg2(287 downto 192) is enabled when clock_enable_counter =2,

Reg2(383 downto 288) is enabled when clock_enable_counter =3,

It is not possible to set bit by bit. I’m thinking about something like this:

set_multicycle_path 2 -to [get_fanouts [get_pins enable_reg|q*] \

-through [get_pins -hierarchical *|*ena*]] -end -setup

But in my case, every bit of reg2 is enabled by clock_enable_counter, so this may not work for my case.

Does anybody have any sugguestion?

Suggestion 1: Use keepers.

Create a combinatory signal for each of the enable cases; mark is as a "keeper"; write your logic based on it and write your SDC based on it's fanouts.

signal enable_0 : std_logic;
attribute keep : boolean;
atrribute keep of signal enable_0 is true;
...
enable_0 <= '1' when clock_enable_counter = "00" else '0';
...
-- if clock_enable_counter = "00" then
if enable_0 = '1' then
...

Then you should be able to get the fanouts of it.

Suggestion 2: Set it bit by bit, using loops.

The SDC file is a TCL script, you can do whatever you need.

for{set n 0}{$n <= 95}{incr n}{
set_multicycle_path -from reg2 -to reg3 ....

Thanks very much again for the information. It is very helpful for me.

Now I'm going to use the second solution, from bit to bit.

When I do this

for {set n 192} {$n <= 287} {incr n}{

set_multicycle_path -from {spu:i_spu|data_processing_chain:i_data_processing_chain|tp1_data_receiver:i_tp1_data_receiver|rx_tapering:i_rx_tapering|rx_tapering_core:i_rx_tapering_core|data_out_tmp[$n]} -to {spu:i_spu|data_processing_chain:i_data_processing_chain|tp1_data_receiver:i_tp1_data_receiver|rx_tapering:i_rx_tapering|rx_tapering_core:i_rx_tapering_core|data_out[$n]} -setup 3

}

It complain no variable n exasits. I believe this is because the bracket of the path. After I removed bracket, like this:

for {set n 192} {$n <= 287} {incr n}{

set_multicycle_path -from spu:i_spu|data_processing_chain:i_data_processing_chain|tp1_data_receiver:i_tp1_data_receiver|rx_tapering:i_rx_tapering|rx_tapering_core:i_rx_tapering_core|data_out_tmp[$n] -to spu:i_spu|data_processing_chain:i_data_processing_chain|tp1_data_receiver:i_tp1_data_receiver|rx_tapering:i_rx_tapering|rx_tapering_core:i_rx_tapering_core|data_out[$n] -setup 3

}

It complains extra characters after close-brace, I do not understand why, how can I set this?

HI rbugalho,

I still have questions about multicycle setting from reg1 (100 MHz) to reg2(enabled to 25MHz).

I have read many documentations, which say that from high frequency to low frequency, the path can be set to multicycle. Here is an example: http://www.altera.com/support/examples/timequest/exm-tq-clock-enable.html#figure1 (http://www.altera.com/support/examples/timequest/exm-tq-clock-enable.html#figure1)

But you said it can not be set to multicycle path, can you explain the conflictions between your reason and the example?

Try to put your signal names between "".

TCL syntax is often annoying.

That's a somewhat complicated example, where they have a multiplier (with register) operating at full-speed being shared by two half-speed paths.

But again, it comes down to the same: the logic in that examples guarantees that the multiplier register launches data 2 clock cycles before an output register latches it.

Note that ab_out latches when div_by_two is '0', while xy_out latches when div_by_two is '1'.

It also, somewhat, assumes that the same is true for the inputs latched by the input registers.

Hi rbugalho, Thanks a lot for the detailed and patient explaination. I got it finally.

When data goes from reg1 (no enable clock) to reg2 (enabled clock), only when launch register launches data several clocks before an output register latches it, a multicycle can be set to reg2.

Thanks a lot again!