FAQ

This page will contain commonly asked questions that the contest organizers have received (questions can be paraphrased). We will update the contest documents as necessary. All submitters will remain anonymous.

Question: What will the topic of this year's contest be?

Response:

Incremental timing and incremental CPPR.

Question: What is the purpose of the duty cycle (i.e., l<ow %>) field in the .timing file associated with the keyword clock? How is this duty cycle used?

Response:

The duty cycle specifies what percentage of the time the clock signal is low (and implicitly defines when the clock is high). For example, if the <low %> field is 30, within one clock period, it will be low for 30% of the clock period, rise at the 30% time mark, and remain high for the remaining 70% of the cycle. For example, if the clock period is 10 and low percentage is 30, the clock stays low from time 0 - 3 and rises to high from 3-10; it then falls back to low at time 10 - 13, goes high from 13-20, and so on.

For this contest, the duty cycle will *not* be used.

Question: The verilog and .lib parsers from the ISPD contests seem to depend on comment keywords such as "Start PIs" and "Begin cell". Will all provided benchmark files contain these keywords?

Response:

Unfortunately, we cannot make this guarantee. The benchmark files we provide will be legal (though simplified) verilog/.lib/etc files, and this may or may not contain comments. We expect that your binary should be robust to consume any legal file that is specified within contest_file_formats.pdf. We would like to emphasize that the parsers are provided "as is" and they are intended for you to use as aids or references, and we do not intend on providing support for this code. So, please ensure that your parsers can handle files when comments are not present.

Question: How do we address arcs that have timing_type: combinational and timing_sense: non_unate?

Response:

If the timing_type is combinational, you will need to derive the arcs from timing_sense and cell_[fall/rise], where [fall][rise] refers to the sink transition. If the type is non_unate, you should assume that both arcs exist. Namely, because you cannot tell what the specific relationship between source and sink, you will need to assume that both exist. For example, in the case of XOR and the relationship between A and ZN with cell_rise, there will be both F->R and R->R transitions. If there is also cell_fall, you will also have F->F and R->F.

Question: When reporting slack, what slack value(s) should we use, pre- or post-CPPR slack?

Response:

Wherever appropriate, you will need to report post-CPPR everywhere that is applicable. That is, the credit from the most critical path/test will be applied to the test itself. For example, if you have a test that originally has -20 slack, and the CPPR credit you found was +5, then the test slack is now -15. To update the rest of the graph, you can adjust the RAT of the data input cone and the RAT of the clock input cone to reflect this credit. That is, all upstream points along the datapath should have a +/-5 RAT adjust (depending on the mode), and similarly with the clock path.

Question: What load should we use to look up in the .lib for delay and output slew calculation?

Response:

You should the total load as seen by the gate, which is the full RC parasitics of the net, including the capacitances at the taps of the net. This has been further clarified in contest_eduation.pdf.

Question: In the benchmark wb_dma on pin inst_1874:D, my report_slack -late -rise is different than the golden. Namely, the golden reports 0.0278, while mine reports 27. Why is there a difference?

Response:

This difference is a consequence of a specified cut-off value in the golden generator during CPPR. In the golden generator's CPPR algorithm, it does not consider (1) any paths that have positive pre-CPPR slack as well as (2) stop the current (negative pre-CPPR slack) path if the current credit awarded to the path + original pre-CPPR slack becomes positive. In this case, while the full credit should be ~75, yielding a positive post-CPPR slack of ~44, the tool stops tracing when the credit is ~30, making the reported post-CPPR slack just above 0. It is technically correct to keep the full positive slack value, and you may choose to either keep your existing path tracing methodology or implement the cut-off value as stated in the golden generator. During evaluation, if both your slack value and the golden slack value are both positive, then you will received full credit. That is, we will not be comparing the difference for passing slacks.