Hopefully, these answers will be a starting point for ur questions.
1. What are the considerations while designing testbench.
To ensure that functionality for which the RTL is coded is checked properly and to ensure that all parts of the RTL are checked. This is done by means of writing "functional coverage points" and by ensuring that code coverage is 100%
2. How to check the internal signals of a design
In some designs, the internal signals are not checked at all. This is called black box method of verification. Incase if its necessary to check the internal signals, the best possible way to do is to access it using hierarchical method in verilog.
e.g : if instance of a module is u_add, and if there is an signal called x, which is passed on to some other module, its possible to either display it in the TB or assign it to a signal in the top level module this way.
assign x = (u_add.x)
3. How to check the full functionality of a RTL design, if it has multiple functionalities.
either write directed testcases catering to one functionality at a time or write a random testcase by providing constraints such that only the functionalities to be checked will be hit.
4. What is timing simulation. How come it ispossible to check timing at RTL design level. I think timing can be verifed once the gate netlist is generated.
timing simulation is done with the help of netlist only. also called gate level simulation, it takes into account the delay associated with the particular gates that are there in the netlist and drives the stimulus to the DUT as before. This is an exhaustive method of checking for timing. Inplace of this, static timing analysis is used these days, where stimulus is not provided, but timing is checked by means of timing arcs.
Comments and corrections are welcome.