FAQ

Frequently Asked Questions

• Q: What is DCTK

A: DCTK (i.e. Delay Calculator Took Kit) is code infrastructure created to develop delay calculator. The source code for TAU 2021 is available at https://github.com/geochrist/dctk/tree/tau2021

• Q: We noticed that the RC networks in the SPEF sometimes have internal nodes that don't have any capacitances. Is this normal and intended?

A: Yes, it is normal in RC circuits to be missing capacitance to ground.

• Q: We find that there are unused receivers in the testbenc and only one receiver is used in the SPICE simulation while the other terminals are left floating in SPICE. Will there be more receivers added in the future?

A: This year's contest is intended to model gates driving interconnect with multiple receivers. For each testcase in the deck, only one receiver will be evaluated. The SPICE simulation netlist is still being worked on. Please expect that the input cap from the Liberty model will eventually be instantiated into the netlist.

• Q: Will GSL (GNU Scientific Library) be available in the contest environment? What version may be available?

A: The AWS server seems to have only version 1.15. Please contact the contest team if you wish to use this library.

• Q: We noticed that the "unused_loads:" field is not populated in the *.yaml file.

A: There is an error in the runme.asu.2021 script -- please turn off (disable) pimodels (near the top of the script). Then the random net generator will generate nets with multiple loads.

• Q: The load parasitics of unused (side) loads are missing from the circuits (.yaml) and the SPICE decks: Does the problem formulation assume that the same load_interconnect is applied to all loads (both the target load and the side loads)? Or the .yaml file should be updated to include a different load_interconnect for each unused load (e.g. by changing the format of the “unused_loads” attribute to consider the C-R-C values or a single capacitance value for each side load)? In any case, the SPICE decks should be extended to apply a capacitor on the side loads, which is missing for now.

A: The unused side loads are not loaded. We expect those loads to have minimal effect. The receiver load will be included and is the value listed in load_interconnect: key of the YAML file.

• Q: For stages with more than 1 unused load, the last one is missing from the corresponding SPICE deck (i.e. for 3 unused loads, only the first 2 of them are included in the deck).

A: This has just been fixed (1/30/2021)

• Q: In the final evaluation, will you again consider a benchmark consisting of corner/extreme cases (using the create_random_nets_stress() ), or you will just use the default create_random_nets() which also includes such cases? In the first scenario, could you provide us the updated create_random_nets_stress() for distributed interconnects, so we can experiment with such extreme cases?

A: Yes we will be having stress test, but we are not certain that we will be letting the contestants know the algorithm beforehand. It is still TBD.

• Q: Is there a possibility of extending the final binary deadline, given the delay in the release of the DCTK framework for TAU 2021, various bugs in the framework, and the lateness of the contest.

A: Yes, the final delivery deadline will be delayed to March. Please check the main web site page for the latest dates.

• Q: I want to submit an alpha build. Is there a tag against which I should compile?

A: Please compile against one of the following (and let the contest committee know which one you used):

• tau2021_alpha210206

• tau2021_alpha210213

• tau2021_alpha210221

• Q: We are seeing extrapolation at the low end of the table bounds. Is this expected?

A: We looked at the library and it is a little bit un-orthodox. The "best" operating point for a single transistor stage gate is when it drives a fanout of 4 meaning four times its input pin cap and that load point is usually the third or fourth column in the table for best accuracy where it matters. In the case of this ASAP library the fanout of 4 point is the first or second column. So, extrapolation on the min side is more common with this library.

But there is nothing wrong with it. For the commercial timers we expect delays and slews to be within a couple of percentage points from spice for any load between 0.0 ff and 10% over max. Obviously below the min breakpoint and 10% over the max breakpoint. Also, the delays and slews are quite predictable on the min side.

The reason why the contestants see more short nets is due to the fact that the random net generator was biased to generate more short nets because these are the vast majority in a design. Long nets are fewer but more difficult to model. Also, the small nets are less likely to generate large transition times that will push the timer outside the slew bounds.

In the tau2021_alpha210213 tag, we have made adjustments to the random net algorithm:

• • The nets total load should be below the cell max cap limit but they can still be below the cell min cap from the delay table, which is still a valid situation (the bias towards very short nets have been somewhat reduced).

  • The net layer is now chosen automatically for wire total cap and based on some back-of-the-envelope calculations, the receiver input pin slews should be within the library slew range for the vast majority of the nets.

• Q: What are the recent scoring algorithm changes?

A: We have made a minor adjustment to the scoring algorithm: we have increased the penalty for outliers to half that of the total points for each category (cell delay vs net delay). Please also note that the net delay analysis is worth more than the cell delay analysis.