regarding clocks

Depending upon the netlist the tool by default provides clock to all flops.

After doing cts, check the physical view of the design, you can see the clock routing.

Hope you are working with SoC-encounter.

This is really sort of two questions. First, are all the flops getting a clock? This can be answered before the clock tree is built. Run check_timing and look for "clock_expected" warnings. These will show places where a clock was expected but not found.

Second, I think you're asking if after CTS, can you tell if a tree was built to each flop? That's a bit harder to answer, but you could check the log file for any problems, or check the clock pins of the flops to see if there is CTS buffering (meaning, the flop is not still connected to the clock root). Try the clock tree browser or clock tree analyst.

The sdc file is the right place for your set_clock_uncertainty statement. To be sure it's getting used, look for it at the top of the timing reports.

The uncertainty will make it harder to meet timing, but that's the purpose - to build in extra margin.

Latency depends how you're using it - can you be more specific?

There are different methodologies that people follow for this, so I can only speak in general terms without knowing your flow specifically. In general, uncertainty may be bigger during preCTS, to model the skew you will get after CTS. Then, once you have clock trees, you can take the skew-modeling part out of the uncertainty to lower it a bit. But some flows leave the uncertainty the same throughout.

For latency, once you have clock trees in, the real latency is always computed for the tree, so you don't have to do anything unless you're trying to model some source latency coming from off-chip or something. But you may use latency for I/O timing at the block level, if you're doing a hierarchical design. If that's the case, let me know, and I can provide some more details.