TimeQuest RGMII Problem

[Altera_Forum]

I have an Arria V design with two RGMII ethernet channels instantiated. I've been working on the TimeQuest constraints and have been following Altera's example at this link: 

 http://www.altera.com/support/examples/interfaces-peripherals/exm-tse-rgmii-phy.html?gsa_pos=3&wt.oss_r=1&wt.oss=rgmii  One of my receive clocks is not meeting hold time (-0.020 ns slack). The PHY I'm using can shift the receive clock in 0.2 ns increments, so I modified my sdc file to shift the receive clock by 0.2 ns in the direction that would provide more hold time. When I re-run TimeQuest, the hold time violation gets worse (-0.186 ns slack). In comparing the timing reports for the two cases, I discovered the Incr delays through the FPGA elements are different. I'm not sure why this would be the case, since I did not recompile the design, but only changed the sdc file? When I compare the TimeQuest generated Datasheet Reports, the setup and hold times change between the two cases. Again, I'm not sure why the FPGA's setup and hold time values would change when I didn't recompile the design?  I am not a TimeQuest expert. Can anyone here on the forum, tell me why the paths through the FPGA change when I modify my sdc file? Any assistance or insight is greatly appreciated.  kstolp

[Altera_Forum]

Without re-running place-and-route, the delays should never change. Do you have more details? Perhaps run the following on both designs and attach. 

report_timing -hold -detail full_path -from [get_ports INSERT_PORT_NAME_HERE] -npaths 20 -panel_name "./TQ/Hold_path_1.txt"  Note that the setup relationship and iExt values in the timing analysis are based on .sdc constraints, so those can change when you change the .sdc, but the other stuff should not. The other thing is you might be looking at different timing models? Just a guess.

[Altera_Forum]

I found the problem, but without running your test I probably wouldn't have. As I mentioned in my original post, I am not a TimeQuest expert. I rarely ever use the TimeQuest UI. I generally edit the sdc file then rerun the full TimeQuest analysis from quartus using the TimeQuest play button on the quartus toolbar. Then using the compilation report, I browse to the timing violation, then right click and choose "Report Timing ... (In TimeQuest UI)". I don't think there is anything technically wrong with this procedure, but the delays internal to the FPGA change when I follow this procedure. If I switch to the TimeQuest UI and reset the design then run Report All Summaries then right click Report Timing, the internal FPGA delays don't change (or in other words this generates the correct results). 

 BTW after I ran your command, I couldn't figure out where the "./TQ/Hold_path_1.txt" file was saved (if it was saved)?  Many thanks for your assistance.  kstolp

[Altera_Forum]

The text file should be saved in a directory called TQ, inside the project directory.  

Running "Report timing in TQ UI" should be the same as opening TimeQuest and manually doing it. The one difference I can think of is if the right-click might be within a folder for a different timing model, and so it creates a different timing model in TimeQuest. Not sure though.

[Altera_Forum]

That's what I thought, so I don't think when I ran the command that the file got created. I ran the command from inside the TimeQuest UI. Is this the correct place to run the command, or should I be running it from a command shell? I'm even less of a command shell user than I am a TimeQuest UI user. The real truth is that outside of Altera's tools, I am not a tcl user. I only ever learn enough to get through my current project. 

 I retraced my steps, and I think you're thought that I right-clicked a different timing model is correct. So I was thinking apples and apples, but it was apples and oranges. So quartus is not broken, just a user error on my part.  Thanks again, kstolp

[Altera_Forum]

That would definitely cause it. 

I run that command from the TimeQuest GUI. Launch TimeQuest and then double-click on the task Report All Summaries. I recommend this as a good getting started because it runs all the major analysis for a design(once you know you only care about setup, for example, then just run Report Setup Summaries). If you want to change the timing model, go to Netlists -> Operating Conditions and change it, then re-click on Report All Summaries. For anything failing, you then right-click on the domain and do Report Timing. It will bring up the report timing dialogue box, with the clock you selected in the To Clock selection. You can modify other parameters here, which will look like the report_timing command I sent you. You can also access this command directly from the pull-down Reports -> Custom Reports -> Report Timing. This is the most important command in TimeQuest for analyzing your design, and I would recommend studying it a bit and playing with it. It's not too difficult, but worth knowing the main options. If you do -file "./tq/timing_report.txt" it should write out a text report in the /TQ directory. Feel free to get rid of the leading ./TQ/ but I find it helps organize the reports. You're past this so may not matter, but I use it all the time. Good luck.

[Altera_Forum]

Rysc, 

I have a related question you may be able to help me with. As I mentioned in my original post, I have two RGMII channels. One channel pretty much meets timing, but the other channel fails it's TX interface (the output from the FPGA to the PHY). In comparing the two channels, the one that passes has pretty low pin-to-pin skew for it's output data (.200 ns), where as the failing channel has much larger pin-to-pin skew (.575 ns). Also the skew between the clock and data on the passing channel is pretty tight where as on the failing channel it is not. These are all altddio outputs, including the clock, which I thought would give me very low skew between all of the output data pins and the output clock. Is there any way to tell quartus to make the skew between these output pins as low as possible (preferably the same)? It seems to me that low skew is more important in a source synchronous design than the actual delay. I think this is particularly true in my case, because the PHY can be programmed to skew the clock.

[Altera_Forum]

You're right that skew is significantly more important than actual delay.  

Your timing constraints tell it to get low skew. I'm really not sure why one of your I/O is so far off. Is there anything different about it?