FAQ
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.
1. Question: Are Boost libraries available?
Answer: Yes, Boost 1.6.6 is installed on the evaluation machine, but we encourage participants to provide a statically linked binary to avoid library issues. The contest organizers can provide some help in compilation if necessary.
2. Question: Can we use GPUs?
Answer: We will not be allowing GPUs for this contest, unless all contestants have access to them (and possibly the same type).
3. Question: Can we reconfigure the kernel to suite our algorithm?
Answer: Sorry, but reconfiguring the machine is out of scope of the contest, but you may ask the contest organizers about the details of the machine, if you wish.
4. Question: Where can we get documentation on the OpenTimer API?
Answer: See https://github.com/OpenTimer/OpenTimer/blob/master/wiki/home.md.
5. Question: I have some questions on how to use OpenTimer. How do I ask them?
Answer: Post them on https://github.com/OpenTimer/OpenTimer/issues.
6. Question: In contest_file_formats.pdf, <.ops> is given as input and output is the consequent result of .ops file. We are confused about this since from our expectation, results like the final Verilog code should be provided for scoring. What file do you need for scoring?
Answer: We have just updated the contest_file_formats.pdf and the contest_rules.pdf to indicate that we no longer need the *.ops file. Please study the Evaluation Process section to understand how the scoring will be done. (Basically, we expect the contestants' submissions to generate Verilog and matching SPEF of an optimized design. These files will then be read into OpenTimer to gather metrics. We will still ask for metric information to be produced in the output file for calibration/sanity-check purposes.)
7. Question: The max_capacitance is given in the library but contest_overview does not mention if this violation should be fixed.
Answer: No, this violation does not need to be fixed. However, violations may cause inaccuracies in the delay calculation.
8. Question: Leakage power and gate delay require the boolean value of each pin. Is constant propagation or case analysis considered in this contest?
Answer: Constants need to be propagated through its fanout network. Timing and power need to be computed after propagation of constants.
9. Question: Is the clock ideal? Are we allowed to modify the clock tree?
Answer: Clock needs to be propagated through the network . It is not ideal. And yes, you are allowed to modify the clock tree.
10. Question: Can we delete the buffers that initially exist in the netlist? How do we deal with the RC network after removing the buffer?
Answer: Yes, buffer deletion is allowed as long as the max_transition is not violated and the logical connectivity is not broken. For buffers deleted, the timer should stitch together the parasitics initially on the input and output nets of the deleted buffer.
11. Question: Regarding buffer insertion -- are we allowed to split the net on any SPEF node, to effect buffer insertion?
Answer: No -- buffer insertions should be done ONLY at existing gates input or output nodes. As a result, buffers inserted at output pins of existing gates should have the original output net re-attached to the inserted buffer's output pin, and the net connected to the input of the inserted buffer should not have parasitics. Similarly, buffers inserted at the inputs of the existing gates should have the original net at the input of the gate attached to the input of the inserted buffer, and the output of the inserted buffer should not have any parasitics. (We'll try to update the contest rules with a picture soon.)
12. Question: Is critical path isolation allowed? (This means inserting a buffer to drive only some of the fanouts of a gate.)
Answer: For this contest, the only way to effect critical net isolation would be to insert a buffer at an input of a gate. This may reduce the load seen by the driver of the net, but the parasitics to the inserted buffer must still be considered.
13. Question: Is power component both dynamic power and leakage power?
Answer: No, we will optimize only for leakage power.
14. Question: Which leakage value should we use? There are some that are dependent upon the boolean value of the inputs.
Answer: Please use the leakage values that are independent of the input pin values. These are the ones for "cell_leakage_power" attribute in the Liberty model.
15. Question: Will the timers need to support propagation of constants? Will the constraints include the standard "set_case_analysis" constraint?
Answer: set_case_analysis support will not be required for this year's contest. (We may require timer support for it, in the future.)
16. Question: For the max_capacitance constraint, can you explain why violations may cause inaccuracies in the delay calculation? Is it a cause of inaccuracy between OpenTimer and an alternate timer?
Answer: The max_capacitance constraint of a timing model is related to the maximum characterized capacitance of a timing arc. If the load capacitance of an output net exceeds this characterization, then the timers typically try to extrapolate the value (delay or slew), but different timers may use different algorithms. As a result, if the alternate timer is outside the table range, the accuracy may be compromised. In industry use, typically timing closure requires max_capacitance to be observed, or the cell the be re-characterized.
17. Question: In contest_rule, TNS is required to be reported by our timer. Is there any definition about this metric? Are those reported metrics being used during the evaluation? What will happen if there is a discrepancy between our timer and OpenTimer?
Answer: Usually TNS (i.e. Total Negative Slack) is computed by adding worst timing slack of each endpoint. During evaluation, TNS will be compared across different tool for same designs & constraint. All timing tools should also specify how TNS is computed by it, but we will use OpenTimer to verify your TNS, anyways. (If there is a discrepancy, the metrics produced by OpenTimer will be used, as would be consistent across all results. (All optimizers are supposed to produce an optimized Verilog and SPEF.)
18. Question: How should the timer evaluate multiple arcs between the same input/output pins in the Liberty model if no WHEN conditions are specified?
Answer: The static timer is supposed to provide the worst case delay in both late mode (largest delay) and early mode (smallest delay). As a result, if there are no conditions applied it is expected that ALL the arcs are evaluated and the worst case delay is kept. So if no constant propagation occurs, all the arcs need to be evaluated.
19. Question: What is the OpenTimer extrapolation for cell delay computation when the load cap exceeds the characterization range?
Answer: The extrapolation algorithm was defined by the TAU 2015 contest. It is linear scaling for the two boundary indices. Please see section 2.3 of TAU 2015 Contest Education
20. Question: Is CPPR to be enabled in this contest?
Answer: No, please make sure CPPR is disabled.
21. Question: Is there a requirement to list out the ECOs issued by the timer?
Answer: Yes, we would like the submissions to generate output in the format of the *.ops file commands that describe the changes performed. More details will be available soon, but expect that this output should be in the "output file".
22. Question: For buffer insertion, which buffers can we use? There are BUF, CLKBUF and TBUF in the timing library. Is BUF can only be inserted between FFs and the CLKBUF can only be inserted on clock tree?
Answer: For this contest, any buffer can be used anywhere. (Note that in real designs, only clock buffers must be used on clock nets, and probably they would not be used on data nets, since they are extra large -- optimized for minimal duty cycle distortion.)
23. Question: Can we use two INVs to replace a buffer?
Answer: Yes, an even number of inverters can be used to replace a buffer. The contestants must make sure that the design functionality is not changed during this optimization. If it is, the team will be disqualified from the contest. Furthermore, the original parasitics must be present in some segment of the logical net, and no new parasitics present elsewhere. (See the questions 10 and 11 for more details.)
24. Question: Will multiple corner optimization be considered for the contest?
Answer: Yes, multiple corner library will be given. The power metric will be based upon the typical corner, but the maximum frequency will be determined as the highest frequency for which all given corners have non-negative setup/hold slack. Note that although two corners were given, the file format allows for more than that number of corners. The next drop of the testcases will contain additional corners for your experimentation.
25. Question: There seems to be a bug regarding units for the SPEF reader, in OpenTimer.
Answer: This bug should have been fixed recently. Please sync the latest master branch.
26. Question: Is there a SPEF parser we can use?
Answer: There is a stand-alone SPEF parser that is available as part of OpenTimer. Please look at https://github.com/OpenTimer/Parser-SPEF
27. Question: How can we pass in the number of threads for the timer to use?
Answer: The optimizer should automatically determine the number of threads to use based upon the result from std::thread::hardware_concurrency().
28. Question: In the contest overview, it was mentioned that we should fix the max transition violation. Where can we find the max transition value?
Answer: This would be the maximum transition time that the table is characterized. A quick look at the Liberty model shows that this value seems to be 198.535ps for the typical corner, and 146.240ps for the fast corner. Please scan the Liberty models dynamically to identify this value. (In more advanced industry Liberty libraries, these values are part of the "max_transition" attribute of input pins, but our sample libraries don't seem to follow that convention.
29. Question: In Question #24, how does the timer interact with multiple corner libraries?
Answer: The timer should analyze the delays in multiple corners. These should be considered global corners, i.e. the min/max delays should be computed on a per-corner basis (do NOT take the min delay from the min corner and the max delay from the typical corner and attempt to compute slack. Instead, for a given corner, min and max delay should be computed, and then all corners should be analyzed when attempting optimization.
30. Question: Where should we put the name of the updated verilog and SPEF files, after optimization?
Answer: The name of the updated Verilog and SPEF files should be the 3rd and 4th arguments given to the optimizer:
<timer> <.tau2019> <.sdc> <output.v> <output.spef> <output file>
I have corrected the instructions in tau_2019_contest_file_formats.pdf, which had some incorrect information.
31. Question: Will the contest be changing libraries in other testcases.
Answer: While the contest is not expected to change libraries for other testcases, the optimizer should be reading in the libraries dynamically and not hard-coding the values.
32. Question: In the s1196 testcase, there is a clock period of 1ns and transition times of 5ns in the SDC. Is this an error?
Answer: Yes, the units in the SDC are incorrect. We'll go through the testcases one more time, adjusting the transition times to be much smaller than those of the clock period.
33. Question: There seems to be a discrepancy in the time units of the Liberty model (time_units : "1ns";) and that in SPEF (*R_UNIT 1 KOHM; *C_UNIT 1 KOHM; *T_UNIT 1 PS). How do we handle this?
Answer: The time units in these two files are independent, and the timer needs to appropriate interpret and translate into the timer's internal units. Each timer may determine internal timer units differently. Some timers may utilize the units in the first Liberty model encountered, whereas other timers may set a particular unit. In this area, we leave the choice up to the contestants. Just be sure to interpret the units in the SPEF and Liberty models for the data within the respective files.
34. Question: There seems to be a problem with the reference timer (OpenTimer) usage of Liberty models with time units of NS and SPEF netlist with time units of PS.
Answer: Yes, we've just been made aware of this issue. We will shift completely to PS time units in our testcases. Please look on the resources page for a tar file of updated Liberty models scaled to ps, that will be used in the contest.
35. Question: How do submit my binary?
Answer: Please send the binary, gzipped to the contest email account, and follow up with a separate email message to get confirmation it was received OK.
36. Question: I noticed there are some very large fanout nets. Can I use parallel buffers for those nets?
Answer: No, please build a buffer or inverter tree for that net. Delay calculation algorithms for parallel drivers is not consistent across all timers and we don't want to be debugging these differences. Also note that these nets will not have parasitics in the testcases. Thus, buffer/inverter trees should be built only for those nets. All other nets should adhere to the buffer/inverter insertion algorithm described above in questions 10 and 11.
37. Question: Do we need to fix hold time violations? How will contest score submissions that don't fix hold time violations?
Answer: Hold times must be fixed. They can always be fixed, but possibly at a cost of maximum frequency. While we may allow for mismatch in delay calculation against OpenTimer, blatant violations will cause substantially reduced score. We haven't figured that out yet, but hope that submissions don't have this problem. (In industry, if the chip comes back with a hold time violation, it is a big deal -- even worst than missing target frequency specification.)
38. Question: Will there be a hard time limit for the execution of the program?
Answer: There will not be a hard time limit, but if the optimization runs too slow, you will pretty much score a zero on that portion. The scoring is proportional to the timer with the fastest runtime. In industry, people will trade off maximum frequency with time to market, so slow optimizers are not desired.
39. Question: Will there be a path from a Primary Input to the cloud of logic between registers? How do we handle slew propagation in such cases.
Answer: There should not be any propagation path from PI to r2r logic in our testcases, because we have disabled set_input_delay and set_output_delay constraints. Optimization should be limited to register to register paths.
49. Question: How will you check if the optimization procedure does not violate the contest rules? For example, the merged net spef will deleted after buffer deletion?
Answer: We are working on techniques to catch optimization procedures that violate contest rules. We won't disclose those techniques now, and ask the contestants not to make such errors. We don't want to disqualify anyone.
50. Question: We've noticed that cell AOI2222_X1 has a function statement of "!(((A1 & A2) | (B1 & B2)) | (C1 & C2))" while cell AOI222_X4 has a function statement of "!(!(!(((A1 & A2) | (B1 & B2)) | (C1 & C2))))". Can these two cells be considered equivalent for sizing purposes?
Answer: Yes, because the function statements reduce to the equivalent result.
51. Question: There are some negative delays present in the Liberty files. Is there something wrong?
Answer: Negative delays often show up in the high slew, low load corner. The reason is that the input waveform may exceed the switching threshold of the gate early in the transition cycle, allowing the output drive portion to switch a low-load net pass the 50% mark, before the input waveform has passed the 50% mark. The characterization tool records this as a negative delay, and it should be considered real.
52. Question: How should the ECO commands in the output file describe a buffer deletion?
Answer: Please use "remove_gate" as the command to describe a buffer deletion. There is no need to list the connect_pin or disconnect_pin commands as we will not try to use these commands to reproduce the results in OpenTimer. The purpose is for us to understand the operations used and correlate the output SPEF and Verilog with each other.
53. Question: Are we allowed to insert extra capacitance on a net to slow down the delay?
Answer: Yes, this would be allowed. You will increase the area and leakage power, though.
54: Question: When will we know everyone's alpha submission results?
Answer: We will not be sharing alpha submission results with other teams. We will contact you regarding your alpha submission if we see problems. Please feel free to ask the contest organizers for feedback if you have not heard anything. (Possibly something got lost in the mail.)
55: Question: Can we have an extension for the submission.
Answer: Yes, we will extend the deadline by one week, to February 22nd. You may also continue to submit alpha versions, but there are no guarantees we'll be able to test them before the final submission deadline.
56: Question: Will the evaluation benchmark suite by available for testing internally?
Answer: After the contest, we will make the evaluation benchmark suite to those who are interested.
57. Question: Are we allowed to remove two connected inverters or modify or use an inverter tree?
Answer: Yes, you can do that, but you can't change the effective logic. If you make a mistake here, we will need to disqualify the optimizer.
58. Question: What happens if there is a cap or slew violation after optimization? (Sometimes cap or slew violation will help hold time.)
Answer: Please don’t have cap or slew violations. It creates accuracy issues. We will be using OpenTimer to benchmark the delays, and it isn’t clear if extrapolation would be consistent between your timer and OpenTimer. Definitely do not count on hold time fixing based on large slew or large cap. It burns crowbar power.