Tau Contest 2018
Frequently Asked Questions
This page will contain commonly asked questions that the contest organizers have received (questions may be paraphrased). We will update the contest documents as necessary. All submitters will remain anonymous.
Question: Do we have to support wildcard characters (*) for the -from/-to/through options?
Answer: No, full name match is good enough.
Question: Will there be sample input/outputs for the testcases in testcases_v1.0.tar.gz?
Answer: Yes, we expect to have them by the first week in January 2018.
Question: What should be used as the tie-breaking algorithm if two timing paths have the same slack?
Answer: The paths should then be sorted by worst arrival time. If the arrival times are also the same, then the order doesn't matter and any path can be reported first.
Question: Do we have to support Tcl in our program?
Answer: No, Tcl support is not required. Support is needed only for the report_timing command syntax as indicated.
Question: Can we have an example of a path report from one of the testcases, to confirm the format?
Answer: For the vga_lcd testcase, the command
report_timing -rise_through inst_74393/CK -rise_through inst_50794/ZN -fall_through inst_57311/A -rise_through inst_87961/ZN -to inst_71644/Dgives the result:
Path 1: inst_71644/CK -> inst_71644/D (Slack: -464.910)Required Time 205.790Arrival Time 670.700Slack Time -464.910 Clock Rise Edge 0.000 + Clock Network Latency (Prop) 650.000 = Beginpoint Arrival Time 650.000 -------------------------------------- Delay Arrival Edge Pin Time -------------------------------------- - 650.000 ^ inst_74393/CK 1.000 651.000 v inst_74393/QN 0.100 651.100 v inst_50794/A2 1.100 652.200 ^ inst_50794/ZN 0.800 653.000 ^ inst_57327/A 1.100 654.100 v inst_57327/ZN 6.400 660.500 v inst_57311/A 1.200 661.700 ^ inst_57311/ZN 3.800 665.500 ^ inst_87961/A2 0.900 666.400 ^ inst_87961/ZN 1.000 667.400 ^ inst_57266/A 1.200 668.600 v inst_57266/ZN 1.000 669.600 v inst_8570/B1 1.000 670.600 ^ inst_8570/ZN 0.100 670.700 ^ inst_71644/D --------------------------------------Note that minor modifications of the format is allowed, as long as the beginpoint/endpoint/slac and data path report is clearly shown.
Question: Do we need to implement other commands as shown in the $testcase_run.tcl file?
Answer: No, it isn't necessary. Actually, the file $testcase_run.tcl file is a mistake and not needed. It has been removed from the testcases archive. An new archive testcases_v1.3 is now available. (Furthermore, the $testcase_cmd.tcl file has been renamed $testcase.ops file, and its internal format modified so that no redirection to output file is expected on the command lines.)
Just implement the report_timing command, per the main instructions.
Question: What are the allowed combinations of -rise_from, -fall_from, -rise_to, -fall_to, -from, -to options?
Answer:
- A command line can contain at most one of the -rise_to, -fall_to or -to options.
- A command line can contain at most one of the -rise_from, -fall_from, or -from options.
- A command line can contain multiple -rise_through, -fall_through, or -through options.
Note that for this contest purpose, we will always have -from and -to in the command. But generally, timers are not required to have these arguments.
Question: Should CPPR be taken into account for report_timing?
Answer: CPPR is not important for this project. Please disable it, if you have it already implemented.
Question: Can you provide golden results for testcases so that the contestants can verify their results? Can you provide evaluation scripts?
Answer: The aux_v1.0.tar.gz dataset has been uploaded. This contains 1K paths from the vga_lcd testcase and also includes a comparison script which can be used to verify the paths. Please review the README.txt file for additional details.
Question: Do we have to report setup violation and hold violation together (tau2015 behavior)?
Answer: Report only setup checks.
Question: Is there a slack_lesser_than option? In tau2015, it's hardcoded as 0.
Answer: -slack_lesser_than option will not be specified and the command should report the worst paths matching from/through/to specification. The command should not limit the reporting to negative slacks only.
Question: Will -from/-to/-through always result in a valid path? Are those specifier follows by topological sorted order?
Answer: They should result in at least one path. (Multiple paths may be matched, if -nworst is greater than 1, and multiple paths match.) The -through order is important. The pin reported first in the path should be specified before the next -through pin.
Question: What should be reported if no paths are found?
Answer: Although this should not happen with the testcases and benchmarking, the tool should report "No constrained paths", or anything equivalent.
Question: What is the numerical level of precision expected in the timing reports?
Answer: The precision should be down to 0.1ps. We will ignore any differences beyond that amount. Please be sure to still keep the precision internally. Only print out down to the 0.1ps level.
Question: Is clock network propagation important? Are parasitics important?
Answer: We are going to use ideal clock (i.e. ignore clock network propagation). Furthermore, to avoid computational mismatches between the reference timer and the contestant timers, we are going to run without parasitics and also use the *_Constant.lib files. This should guarantee the delay values be identical across all the timing engines. Please also don't worry about minor formatting differences between the reference and your output. We'll make adjustments to our comparison script as needed.
Question: Is the cell input pin important? We don't see it in aux_v1.0.tar.gz upload?
Answer: Our apologies for that oversight. We've uploaded aux_v1.1.tar.gz which fixes our data. We do expect to see input pins in the path.
Question: Are the begin points of the flip flops to be QN/Q, or CK pin?
Answer: Our timer uses Q pin as begin-points, but our comparison script will assume it to be CK pin. Please start with CK pin if possible.
Question: What is the expected number of report_timing commands in the *.ops file?
Answer: Our example shows 1K, but we could supply as many as 1M. Furthermore, we expect that the order of the paths in the output file match the command order of the *.ops file.
Question: In the aux_v1.1 set of files, the clock period (of 2) in run.tcl seems inconsistent with the clock period (of 100) in the .timing file. Which one is correct?
Answer: Sorry about the mismatches. We have updated run.tcl and regenerated the results in aux_v1.2.tar.gz.
Question: In the aux_v1.1 set of files, we've noticed that the delay of inst_57266/ZN is 7.30, but the vga_lcd_Late_Constant.lib shows a constant delay of 6.643. Why is there a difference?
Answer: It looks like our commercial timer is doing some extrapolation, as this net has a large fanout. To avoid extrapolation, we've increased the limit of the net capacitance axis by 10x. Please download testcases_v1.4.
Question: What is the Required Arrival Time of output pins?
Answer: The timing constraint is specified in the *.timing file associated with the testcase. However, we will requesting ONLY register-to-register paths during the benchmarking, so it shouldn't matter what you are using. Note that in order for your timer to be useful for other projects, it should support reporting from input ports/to output ports. It's just that for this contest, we didn't want to worry about the constraints at the input and output ports.
Question: Will -nworst option be used? Will the -max_paths option be used?
Answer: We have also decided not to test the -nworst or -max_paths options, so you don't need to implement those features.
Question: If multiple paths satisfy the report_timing command and they have the same slack, what should be used as the algorithm to determine which path is report first?
Answer: For setup checks, please use the later arrival time. For hold checks, please use the path with the earlier arrival time.
Note that for contest purposes, we expect to be issuing query commands that return only a single path.