Adjusting the operating frequency of a module in Verilog

Question

I am creating a fairly complicated module which involves timing analysis of 2 Modules each having their own algorithm, but take in 2 signed numbers as inputs and output a signed number.

I am designing this module for an FPGA in Verilog using Xilinx as my synthesis tool. Now I understand that Xilinx usually gives the worst case timing analysis for any module. This means that if I have a range of numbers which take 250 picoseconds, from input to output including the routing time, if there is even a single set of inputs that takes 400 picoseconds, the timing analysis shown by Xilinx would be 400 picoseconds.

My goal is to find:

1) If Module 1 is faster than Module 2 for any set of numbers.

1) Range of numbers for which Module 1 is faster than Module 2.

The only logical approach I can think of is, by increasing the operating frequency of the module. That is to force both the Modules to give their outputs after say 300 picoseconds rather than 400 picoseconds.

Obviously if I increase the operating frequency, some of the inputs in the testbench will give out erroneous outputs. My hypothesis is that the module that starts giving out erroneous answers first, has the algorithm.

So my doubts are:

1) Is it possible to increase the operating frequency of a Module in Verilog using Xilinx (some settings that I must enforce upon during synthesis or analysis). If not, is there a better tool that will be do my timing analysis?

2) Is this approach viable? Short of doing a gate level synthesis using Cadence, is there anyway, I can find out the actual time delay analysis for each set of signed numbers for each gate using Verilog?

Answer 1

You are right in assuming that Xilinx always reports worst-case timing for the whole design, where clock-rates are concerned, Don't take the synthesis results as being very accurate - they can vary by quite a lot once you've placed and routed the design.

I guess you could take the post-PAR Verilog netlist and simulate that with a variety of inputs using different simulated clock speeds - if there are slow paths which are not used for certain inputs, you should be able to run the simulated clock faster for those inputs.

Sounds like a very time consuming task, and I'm not sure what the point is. Where I come from (automotive) "worst-case" is the only number we can look at with any level of confidence!