Deos the plls of a fpga exactly same?

If driving multiple PLLs with the same clock, you can't ever consider divided clocks as the same, as the PLLs may create them on different phases. (I can explain it if it doesn't make sense, and have a design to get around this issue.) Your cases are all multiplies(5x) so it won't be a problem.

So can you treat them as the same clock? The most exact answer I know is, not exactly. The PLLs are not perfect(what is?) and so they can have different affects on the clocks. For example, there will be some jitter. Now, for something like a hold analysis, jitter can be ignored within a single clock domain because the hold edge is the same. But when going between two different PLL outputs, this is no longer the case and they will have different jitter affects. So what can you do? The best thing is to add setup/hold uncertainty in TimeQuest between the clock domains(set_clock_uncertainty is the command), and try to minimize the number of paths going between them. A number I've seen thrown about is 300ps of uncertainty, which many argue is way to high, but under extreme conditions is probably possible. (Every configuration of the PLL, and design/board environment, behaves a little different, which makes this difficult to put an exact number on.)

Example:

set_clock_uncertainty -from PLL1_clk1 -to PLL2_clk1 -setup 0.3

set_clock_uncertainty -from PLL1_clk1 -to PLL2_clk1 -hold 0.3

set_clock_uncertainty -from PLL2_clk1 -to PLL1_clk1 -setup 0.3

set_clock_uncertainty -from PLL2_clk1 -to PLL1_clk1 -hold 0.3

If there are multiple clock crossings, do it for all of them, but again, I would try to minimize crossings.

Anyway, with two PLLs within a part, the setup will be rather straightforward(your paths going between the two domains will now have to make timing by 300ps), but they will also have a 300ps hold requirement, so they can't be too close. If you get hold violations, there are ways around it which can be discussed later.

Between two devices, the hold issue will probably never be a problem(hold issues come when your path is too short, and going between two devices is never short).

I've heard of users doing both of these(more often the first to get more taps out of the PLLs) and had them work without adding any uncertainty(at least as far as I know).