tse ip core communicate with pc

I see. If possible I would suggest to use a standard design first, with a Nios CPU and a software template such as the simple socket server. The big advantage is that the driver will ensure the TSE is initialized and configured properly. Once this works, you know the TSE is functioning properly and you can mode you your own hardware design.

Solving your problem directly is difficult because it is hard to figure out if it is coming from your logic that controls the TSE, or something else. If you are using a development kit there is probably an example design with everything already there, including the timing constraints. Start by running this design, and once it works, remove the Nios CPU, the DMAs, and everything you don't require, and put your own logic instead.

Now to answer your question, IIRC the TSE takes quite some time to reset itself. You should read back the reset bit continously, until you can get a reset done status. In my opinion a bad timing in the project will cause other kind of problems, but not a reset failure.

The .sdc file generated with the TSE will only constrain some internal timing requirements inside the TSE. Timequest currently doesn't know anything about the frequencies you want to achieve on ff_tx_clk and ff_rx_clk. To define those you need to constrain yourself all the signals on the RGMII interface. Again if you have a development kit with example designs, you should be able to get the correct constraints from there.