First off, I admire your sense of optimism.
Okay, so if my design has different clocks, one being a generated clock with respect to another, can XST time such paths without clock constraints?
Can? Sure, it will happily do so. Will it do it's thing precisely such that it magically guesses your timing requirement? Not very likely.
Would it use a single cycle timing on these paths and generate a max freq?
It will most certainly generate a
max freq number. FYI: it will
always generate a max freq number, no matter what shit you feed it. Translation: max freq is a nice distraction to give you a false sense of "gee, this is a useful metric" while in fact you are better off forgetting that number even exists. That
max freq is a very VERY rough indicator, period. Nothing more, possibly less. That number is so useless I never even look at it, because who cares? I only care how a design meets timing on the constraints
I specifically specified, because that is really the only way to properly tell the tools (ISE) your design intent. Using no constraints and just hoping for the best is highly optimistic at best, and silly at worst.
More generally, if there is transfer of data from one clock domain to another, how would XST understand and time such paths?
It would make stuff up, and fsck up your design. Free of charge.
I realize that if you just started with fpga's this may be a
"Noooo, not more manuals" moment, but you really should give the
Timing Closure User Guide a quick look. For older versions of ISE that document was called "Timing Constraints User Guide", and it's always been UG612 document number AFAIK. And you really also want to read a bit in the regular
Constraints Guide, even if only to get a rough idea.
I promise, you will waste more time guessing
"WTF is ISE doing" when you choose the "no constraints" way of working. Reading those two documents and actually using some constraints will be cheaper in terms of time spent and definitely be cheaper in terms of sanity/hair loss.