Parallel adder timing issues

There are three different things:

1) Tco -> This is the clock to out. Again, I'm assuming you're going to put more logic around the adder, and so this path should be ignored since your adder output won't go directly out. (Minimally, you will want to add another set of registers so they can be put into the IO cell and get better timing. You would also have to use a PLL). But the Tco isn't equatable to an Fmax as it's only part of the path. If it takes 6.5ns from a clock entering the device to data going out, that data will have to be clocked in by some other device. So you'll have board delay and setup time of the other device, making the path even slower. You'll also have clock skew across the board, which can hurt or help. But until you factor all of these things in, there is no way to equate Tco to an Fmax.

2) Internal paths. These are register to register, and since Classic Tan knows the clock feeding both, it can give you a full calculation and will report an Fmax. (There are cases where Fmax doesn't make sense, like when going between clock domains, so it's recommend not to always think in terms of Fmax, but for a single clock domain it's generally all right).

3) Finally, there is latency, which is the number of registers to get through the device. If you put down IP with multiple registers along the data path, then it would take three clock cycles. If you're doing RTL, you can look at the code and know exactly how many clock cycles it takes to get through. Of course, if you're looking at a timing simulation, that 6.5ns Tco tacked onto the end may span multiple clock cycles, even if the data "got out" a few cycles before.