Honored Contributor
Honored ContributorI would delete the attribute, as it's not common practice to delay the clock. report_path -to clkout_name should get you the timing(although I'm not positive, as it might not since it's a clock and not data, but I think it should work). You can look in the fitter report at global usage too.
Since you're forwarding a clock, the big question is if you're accessing data on every clock cycle? If that's the case, you probably have somewhat tight timing requirements(depending on clock frequency). Most likely you're doing something more simple, like setting the address, data and control one one clock cycle, then turning on the enable the next cycle, then turning off the enable, and then changing the data/address, etc. If that's the case then you have multicycles to play with. Also, you need to no your board delays and SDRAM access timing. I/O timing is one of the more difficult things to do, but it should be since it's a complicated thing. Have you studied the I/O timing constraints set_input_delay and set_output_delay? Just put some in with a value of 0ns as a starting point. Also, on your outputs, you need to put a generated_clock on your output to use for your clock. Look at the source synchronous output examples at: http://www.altera.com/support/examples/timequest/exm-timequest.html
