[SOLVED] How do I decide clock period constrain for Synthesis in DC?

I have a RTL to synthesize in DC. How do I chose the value of various constraints like clock period, input/ output delay and multi cycle paths etc?

clock period: depends on what the specs of the design are. do you have to meet a certain protocol speed or similar? do you want max performance? this is for you to decide.
input/output delay: this is more complicated as it models the outside environment as seen by your block. this could mean another block, or another component on a PCB.
MCP: this is more advanced stuff, I wouldn't recommend for you to play with unless you know what you are doing. essentially you are telling the tool that certain paths can take more than one cycle to compute which can yield a higher clock rate for the block. this is very design specific, you can't just pick any path and apply it. it has downstream consequences, obviously.

Thanks for the response. I have a quick follow ups

I have done RTL to GDS flow for a project, but SDC, run script and all was already provided by professor. Now Im taking a random Open source RTL of a processor and trying to implement it from scratch.

1] Clock Period: I dont have the specs. How should I come up with a reasonable clock rate? If I go ambitious say ~0.3 nsec, it gives me large negative slack beyond a clock cycle. If I go around 1 nsec there is large positive slack. So should I stay in between and be reasonable and fix setup violations if there are any? Is trial and error the correct approach? I am using Synopsys Educational Libs.

2] Input/ Output Delay: Got it. For now I dont have a strict requirement. I can use approximate value, right?

3] MCP: Thanks for the explanation. Does that mean if these paths were not defined as MCPs they could have largest setup violations? And since we dont have any other way to run them within one clock cycle, we put them in MCPs. Can I use MCP concept to fix large negative slack which goes beyond a clock cycle, as discussed in 1] ?

1) you can try for an ambitious target at first, see what the critical path looks like, and reduce accordingly. the process is not linear,as you push the frequency the tools will enable different optimization tricks. some trial and error is typically required.
2) don't use anything, for big designs only a tiny portion of the paths will have in/out delays.
3) don't use MCP to fix setup because it is convenient. first you should look at your code and see if there is some obvious optimization/pipelining that you overlooked. MCPs are like a last resort.