Large interconnect delays on clock

[Altera_Forum]

Hello, 

 I'm trying to do a test implementation of a design in StratixIII using Quartus. Since this module is only a part of a bigger project, I have set it as a partition and locked its location to an area on the FPGA. Also, I have set all of it's ports to virtual pins except for the clocks. I have also specified constraints through the SDC file. After synthesis, I used the generated netlist and SDF file to run a functional post-synthesis simulation to check for the behavior.  I checked a path timing using Timequest Timing Analyzer, and noticed that there is a large interconnect delay from the clock to the module, around 3ns total delay (I'm running at 7ns, so it's almost half the clock period).  We have also tried to implement the module together with the whole project and I checked the timing on the same path. This time the inteconnect delays are small, around 0.3ns. I noticed on the netlist that the clocks have "GLOBAL" on them, maybe an indication that they are assigned to the global clock resource. I don't see this on the "module only" netlist, and maybe this is the reason why I'm getting large interconnect delays on the clocks.  Is there something that I failed to do when I synthesized the module alone? How do I make sure that the clocks are on a global resource?  regards, Edzel 

[Altera_Forum]

--- Quote Start ---  Hello,  I'm trying to do a test implementation of a design in StratixIII using Quartus. Since this module is only a part of a bigger project, I have set it as a partition and locked its location to an area on the FPGA. Also, I have set all of it's ports to virtual pins except for the clocks. I have also specified constraints through the SDC file. After synthesis, I used the generated netlist and SDF file to run a functional post-synthesis simulation to check for the behavior.  I checked a path timing using Timequest Timing Analyzer, and noticed that there is a large interconnect delay from the clock to the module, around 3ns total delay (I'm running at 7ns, so it's almost half the clock period).  We have also tried to implement the module together with the whole project and I checked the timing on the same path. This time the inteconnect delays are small, around 0.3ns. I noticed on the netlist that the clocks have "GLOBAL" on them, maybe an indication that they are assigned to the global clock resource. I don't see this on the "module only" netlist, and maybe this is the reason why I'm getting large interconnect delays on the clocks.  Is there something that I failed to do when I synthesized the module alone? How do I make sure that the clocks are on a global resource?  regards, Edzel   --- Quote End ---    Hi Edzel,  you can use the Assignment Editor to set a signal to global. Have a look to the attached picture.

[Altera_Forum]

No large-fanout net could have a delay of 0.3ns. It depends on device and speed grade, but a 3ns global delay sounds about right(some are larger, some are smaller). My guess is that in the full design it is driven by a PLL, so you still have your 3ns delay, but the PLL also compensates for that by shifting back approximately 3ns. In your sub-design you just have the global delay. 

With the exception of I/O interfaces, this shouldn't matter much, since any clock transfers in that domain will have both the source and destination clocks delayed by ~3ns, so the net sum is that they cancel each other out.

[Altera_Forum]

You can check that nothing funny is going on by doing a list paths in timequest and selecting the 'full path' option. This will show the breakdown of the clock network delay, so you can check if it is being routed how you expect.

[Altera_Forum]

Hello, 

 For now, I instantiated a PLL (but that is not supposedly included in the subdesign) just to get the correct resource assignment of the clocks and get a more realistic delay.    This works, for now, but I am very interested in knowing how to do a functional simulation using the postsynthesis netlist if the delays on the clock signals of the said netlist are not "realistic" because it was compiled bottom-up.   regards, edzel

[Altera_Forum]

Stepping back, it's not common to do a functional "post-synthesis" simulation. The most common approach is to do a functional simulation with the RTL and static timing analysis to make sure the timing is right. If done correctly, that should be enough. On top of that users often do post-fit timing simulations. They're slow, and they really aren't as robust at catching things as most users think, but it used to be a common practice(especially for ASICs, where the cost of a mistake was too high and there wasn't any way to just run the hardware and see if anything went wrong.)  

Anyway, you state you're doing a functional simulation(which implies no timing) but are including the .sdf(which is the timing file). So I'm a little confused. Just a suggestion, but you might want to just do a post-fit timing simulation on the full design(or not at all). Naturally, if you're just simulating a sub-component, then the delays outside of that sub-component(like clock delays) may not be realistic unless you go through the hurdles to make them realistic(like adding the PLL).