Timing Violations workaround strategy

First, thank you for feedback Ryan.

My case seems to be quite simple ... instantiation of one Qsys module.

The Qsys module consists of (please have a look at Qsys screenshot below):

1. CPU

2. PLL, that generates 2 clocks (1st – for all internal blocks, including CPU, 2nd – for external SDRAM)

3. SDRAM controller, connected to external SDRAM

4. GPIOs (buttons, switches, LEDs, 7-segment LEDs)

5. 2 timers

https://www.alteraforum.com/forum/attachment.php?attachmentid=13584 https://www.alteraforum.com/forum/attachment.php?attachmentid=13584

And here is Qsys instantiation:

module nios_led2_top (input clk, 
	input  sw,
	input  key,
	output  led,
	output  hex3, hex2 , hex1, hex0,
	
	output  sdram_addr,
	inout  sdram_dq,
	output  sdram_bank, 
	output sdram_cas_n, sdram_ras_n, sdram_cke, sdram_cs_n, sdram_clk,
	output sdram_dqmh, sdram_dqml, sdram_we_n);
	
	wire  sseg;
	assign hex3 = sseg;
	assign hex2 = sseg;
	assign hex1 = sseg;
	assign hex0 = sseg;
	
   nios_led2_sdram_10leds u0 (
		  .btn_export       (key),
		  .clk_clk          (clk),
		  .led_export     (led),
		  .reset_reset_n    (1'b1),
		  .sdram_wire_addr  (sdram_addr),
		  .sdram_wire_ba    (sdram_bank),
		  .sdram_wire_cas_n (sdram_cas_n),
		  .sdram_wire_cke   (sdram_cke),
		  .sdram_wire_cs_n  (sdram_cs_n),
		  .sdram_wire_dq    (sdram_dq),
		  .sdram_wire_dqm   ({sdram_dqmh, sdram_dqml}),
		  .sdram_wire_ras_n (sdram_ras_n),
		  .sdram_wire_we_n  (sdram_we_n),
		  .sseg_export      (sseg),
		  .switch_export    (sw),
		  .clk_sdram_clk    (sdram_clk)
    );
endmodule

The frequency of two PLL-generated clocks is 3 times input frequency (which is 50MHz). One of the clocks (that which clocks external SDRAM) is shifted -3.5ns in regard to another. I'm not sure if it's the optimal solution … this configuration I've adopted from a reference design of my board.

Here is the content of the .sdc file:

create_clock -name clk -period 20 
create_clock -name {altera_reserved_tck} -period 40 {altera_reserved_tck}
derive_pll_clocks
derive_clock_uncertainty
set_input_delay -clock altera_reserved_tck -clock_fall 3 
set_input_delay -clock altera_reserved_tck -clock_fall 3 
set_output_delay -clock altera_reserved_tck 3 
create_generated_clock -name clk_ext_sdram -source .gpll~PLL_OUTPUT_COUNTER|divclk}] 
set_false_path -to 
#  Constraint SDRAM DATA for input
set_input_delay -clock clk_ext_sdram -max 0 ]
set_input_delay -clock clk_ext_sdram -min 0 ]
#  Constraint SDRAM DATA for output
set_output_delay -clock clk_ext_sdram -max 0 ]
set_output_delay -clock clk_ext_sdram -min 0 ]
#  Constraint DRAM ADDRESS for output
set_output_delay -clock clk_ext_sdram -max 0 ]
set_output_delay -clock clk_ext_sdram -min 0 ]
#  Constraint SDRAM Controlss for output
set_output_delay -clock clk_ext_sdram -max 0  sdram_dqm* sdram_cas_n sdram_ras_n sdram_cke sdram_cs_n sdram_we_n}]
set_output_delay -clock clk_ext_sdram -min 0  sdram_dqm* sdram_cas_n sdram_ras_n sdram_cke sdram_cs_n sdram_we_n}]
set_multicycle_path -setup -to }] 2
set_multicycle_path -hold -to }] 1
set_false_path -from 
set_false_path -from 
set_false_path -from * -to 
set_false_path -from * -to 

In this constraint file I derived PLL clocks and used one of them to constraint SDRAM data, address and control signals (e.g. cs_n, cke, etc.). Doubtless, the constraints I imposed are erroneous … as Timing Analysis reported a lot of violations. These violations I've tried to repair with help of multicycles (again, perhaps, it's not the best solution for such issues). Anyway these multicycles constraints were ignored.

Is it possible, just looking at the constraint file (and taking into count the information from Qsys) do the first estimation what is wrong with constraints ? Perhaps, correcting some basic errors can avoid the majority of timing violations. And then (after repairing big blunders) pass to timing analysis using TimeQuest reports?