Another SDC question I'm having trouble with : I have a clock that's generated internally, divided by 2 from the main clock with a FF. I create it using :

create_generated_clock -divide_by 2 -source $::env(CLOCK_PORT) -name clk_scan_out [get_ports scan_clk_out]

I have some data accompanying that clock but those are generated in the main clock domain, but in such a way that they they only change once every two cycles and also that they change aligned with the falling edge of the generated clock. And I'd like to use STA to check that output delays :

set_output_delay -min -1.5 -clock [get_clocks clk_scan_out] [get_ports {data_out}]
set_output_delay -max  1.5 -clock [get_clocks clk_scan_out] [get_ports {data_out}]

But of course I somehow need to tell it that

data_out

, despite being produced on the main clock, only changes once every two cycles, and only at the same time as the falling edge of

scan_clk_out

... And I'm not sure how to do that. I tried some variations of

set_multicycle_path

but couldn't find something that does what I want (from looking at the results in the reports)

@Tom Spyrou would you comment

@Andrew Wright: If this is the right way to handle divided-down clocks generated from a state machine, then we need this SDC setup for the Caravel GPIO serial loader clock (which is the core clock divided by 2). Assuming the

set_multicycle_path

statement is the correct usage, that's what we need for analyzing the serial loader clock for MPW-seven (where I added the re-clocking on the falling clock edge at the end of every GPIO control block) (and which also applies to my metal2 mask fix for the same issue).

For reference, this is what is used inside the scan blocks :

# Create a clock for the scan chain @ 200 MHz
create_clock -name clk_scan_in -period 5 [get_ports {clk_in}]
create_generated_clock -name clk_scan_out -source clk_in -combinational [get_ports {clk_out}]

# Scan chain input  0.5 ns setup time, 0.5 ns hold time
set_input_delay  -min  0.5 -clock [get_clocks clk_scan_in]  [get_ports {data_in}]
set_input_delay  -max  0.5 -clock [get_clocks clk_scan_in]  [get_ports {data_in}]

# Scan chain output 1.5 ns setup time, 1.5 ns hold time
set_output_delay -min -1.5 -clock [get_clocks clk_scan_out] [get_ports {data_out}]
set_output_delay -max  1.5 -clock [get_clocks clk_scan_out] [get_ports {data_out}]

and the corresponding bits in the timing report : https://pastebin.com/2hbycY8g And this is what is used in the scan controller :

# Create our generated clock
create_generated_clock -edges {3 5 7} -source $::env(CLOCK_PORT) -name clk_scan_out [get_ports scan_clk_out]
set_multicycle_path -start -hold -from [get_clocks $::env(CLOCK_PORT)] -to [get_clocks clk_scan_out] 1

# IO delays
        # Scan chain input  0.5 ns setup time, 0.5 ns hold time
set_input_delay  -min  0.5 -clock [get_clocks clk_scan_in]  [get_ports {scan_data_in}]
set_input_delay  -max  0.5 -clock [get_clocks clk_scan_in]  [get_ports {scan_data_in}]

        # Scan chain output 1.5 ns setup time, 1.5 ns hold time
set_output_delay -min -1.5 -clock [get_clocks clk_scan_out] [get_ports {scan_data_out}]
set_output_delay -max  1.5 -clock [get_clocks clk_scan_out] [get_ports {scan_data_out}]

        # Limit the max output delay on other outputs
set_output_delay -max  1.5 -clock [get_clocks $::env(CLOCK_PORT)] [get_ports {scan_select scan_latch_en}]

And the corresponding timing report (that I think shows it's analyzed properly ) : https://pastebin.com/QD5LzABW

This SDC looks like it relative to the top level. If this design being done hierarchically? It is small enough from what I understand that it would be better to do it flat. The final parasitic extraction and STA will only work flat. We don't support doing that hierarchically.

@tnt You could check for single period timing. 5ns are roughly 20 logic levels. If it makes it, you are safe, right?.

Have you tried the waveform option on creating the clock to align the edges the way you want to? That might work better than a multicycle exception.