I wonder what are the guidelines for porting ASIC RTL to FPGA for emulation.

1. Memory blocks need be adjusted for FPGA device specific features.

2. DSP Elements need be adjusted for FPGA device specific features

3. Gated Clock : FPGA supports it but with special features. Normally not. How to port efficiently gated clock.

4. Is Clock tree defined at RTL? How to port the balanced Clock Tree to FPGA. I mean how to replicated similar skews for clock tree that exist in ASICs?

5. How to balance delays for the Reset signal in FPGA 

Any other guidelines required for proper porting of ASIC code to FPGA for ASIC emulation on FPGA, please share.

(Disclaimer - never designed an ASIC, or ported one to FPGA)

If you want to port for emulation then you don't want to adjust anything in your RTL surely?  Aren't there tools that can do this for you?

Or are you more looking to prototype your ASIC in FPGA?

If you are going to do it yourself then almost everything needs to be changed.

Raw logic and flipflops will re-synthesize directly (even using DSP blocks if the tools support the inference style you have already used)

But any hard blocks that have been instantiated are very unlikely to port.  You've picked on a couple of obvious ones (memory and DSP), but also, clock-management (eg PLLs), IOs, hard memory controllers (or at least the PHY parts), gigabit transceivers.  

The number of clock domains may also cause you aggravation too - ASICs are often designed with many more than FPGAs can provide.  I don't know if this is because they need to or just because they can!

I can't help on the reset line - I have no idea what an ASIC reset distribution looks like...

I assume you have designed ASIC.

1. Memory blocks - In ASIC behavioral models have to be replaced by blocks created using Memory compiler. Decide upon Block/Distributed RAM and modify the surrounding logic. Simulate and verify proper functioning.

2. DSP - May have to be totally redesigned, depending on the application, very vast scope.

3. Gated clock - RTL may have to change in a certain way to infer Flops with Enables.

4. Clock Tree - In FPGAs clock tree is predefined, look at the PLL/DLL/Clock source to ASIC and redesign the clocking block using Xilinx/Altera prescribed methodology. Simulate and implement the FPGA, analyze timing report to make sure no violations.

5. Reset Tree - In ASIC RESET and CLOCK are the highest FANOUT signals and planned and implemented separately. Later in STA recovery and removal checks are done. Similarly clock tree synthesis (CTS) will insert the clock tree in the design. Timing analysis would reveal violations, effect of violation is verifiable by Gate level simulation. In FPGA the sequential element starts from a known state after power on meaning sequential elements are properly reset. Check in ASIC RTL if synch/asynch reset was used. In general synch reset method works well in FPGAs - helps in better routing and relieve congestion. This topic is also vast. 

Emulation - Emulation methodology has to be finalized before porting ASIC code. It depends on how well ASIC code is partitioned. Consider repartition, multiple FPGAs etc. Again a vast area.

Conclusion - No straight forward approach, much depends on application. If the ASIC has more computing elements/video/data path Logic, etc..

You do not port asic code to an FPGA. Design is a two step process, you first enter and test the logic that you want and then you target it to the technology that you need. You maintain your source as generic code and automate the retargeting to all of your different technologies.

Place all code that you know will change in its own submodule and the asic/fpga engineer will replace that module with the correct one for their technology. This includes rams,dsps,clock,pads, phys etc. 

Design for the lowest common denominator. If you design your product around a special feature that only one silicon vendor can provide then you are locked in to that vendor.

Automate flows like clock/reset tree synthesys and pad muxing. That way when your design changes its a lot easier to recreate your target(s). Do not use an asynchronous tree for reset. Google Cliff Cummings Sunburst and read his snug papers on synchronous reset trees. That is how you distribute your reset.

Put a clock enable on all flip flops. If the targeting engineer doesn't need it then they will tie it off and it is synthesized away. 

This makes it a lot easier to reuse your code for future asics or different fpga vendors.

John Eaton