Disabling STDOUT in timequest

[Altera_Forum]

Hey Altera people, 

 Im writing some tcl scripts to get some low level delay information from quartus. Every time I do a report_path command I get a bunch of output printed on the timequest console that I dont need.  e.g. Info: Report Path: Found 1 paths. Longest delay is 10.065  Info: -from [get_keepers {r.fm_SystemControlReg[1]}]  Info: -to [get_keepers {fm_Gpio_D_Output[3]}]  Info: -npaths 1 Info: Path# 1: Delay is 10.065  Does anyone know how to disable such output?   Its probably slowing down my code quite a bit because it's printing thousands of lines every time I run my code.  Thanks

[Altera_Forum]

How come you're using report_timing? That's more of a high-level function that is meant to provide all the information(and therefore not meant to be called thousands of times). More specifically, how are you getting low-level delay information out of it? Are you dumping everything to a text file and then parsing that?  

My thought is that you'd probably want to use get_path and get_path_info, or something like that. (At a prompt type "quartus_sh --qhelp" and then click on STA on the top-left window, and you'll find get_path on the right, as well as a ton of other functions.) Out of curiosity, what information are you trying to pull out, and what are you doing with that information? Just curious if it's something others would find beneficial.

[Altera_Forum]

Thanks Rysc,  

 Yea I thought maybe I should switch to using get_path. I'm using the "report_path" command which prints a bunch of stuff about a specified or partially specified path as well as returning a list containing the delay of the path. So I dont need to parse any files.  Overall I'm trying to find the propagation delays of input and output ports on the fpga and save them to a file. Then im trying to get this information into a timing diagram tool we use so that I can see if our fpga bitstream is conforming to the interface requirements of the external peripherals on the board.  So for an output port for example, I use report_path to calculate the following paths:  output_port -> its sourcing register, sourcing register clock to out (Tco), sourcing register -> its clock source  And then add them all up to get the total propagation delay for an output pin. Do you think this is a valid method?

[Altera_Forum]

It sounds like all you need to know is the overall tco from the clock input device pin to the data output device pin. If you constrain the output timing with set_output_delay (usually preferred) or set_max_delay, you can use the normal report_timing method to see whether the tco requirement was met.

[Altera_Forum]

Yes constraining the FPGA design using these methods is a good option however I have to account for the possibility that we will have an existing FPGA bitstream applied to modified hardware.  

 In this case we do not want to constrain the FPGA design any more, but would like to know if it conforms to the new hardware. In effect it would close the loop. Maybe.

[Altera_Forum]

How does one go about using the report_timing command to report input and output delays? 

 This would be useful to me for checking that I have done my calculations correctly.  Thanks

[Altera_Forum]

When I/O paths are constrained with set_input_delay, set_output_delay, or set_max_delay/set_min_delay, report_timing works on I/O paths the same as on internal paths except that for a device pin in the -to or -from field you use get_ports instead of get_registers. You can use get_keepers for either device pins or registers (a keeper is either a port or a register), so there's no difference in I/O-path reporting and internal-path reporting if you use that collection. You can report between I/O and internal clock domains if you use a virtual clock for the set_input/output_delay -clock field (the recommended practice except for source-synchronous outputs). For example, an input path could be reported with -from_clock my_virtual_clock_for_the_port -to_clock my_real_clock_for_internal_register. 

 If you use set_max_delay/set_min_delay without set_input_delay or set_output_delay, then the port (device pin) will have a clock called "na" (or maybe it's "n/a"). This is a special case where you don't have to have an user-created clock for the thing being reported with report_timing.

[Altera_Forum]

Excellent thanks very much