Downloads

A trace-based simulator (click to download) : (CVPv6, October 2018)

  • Reads instructions from a trace in .gz format directly.
  • One instruction from the trace may generate several "pieces" that contestants will have the opportunity to predict.
  • The number of pieces depend on the number of 64-bit output values. For instance :
    • A vector instruction that writes 128-bit registers will cause two pieces to be generated.
    • A scalar instruction that produces two general purpose registers will cause two pieces to be generated.
    • A vector instruction that writes 2 128-bit registers will cause four pieces to be generated.
  • In general, however, instructions from the trace will only generate a single piece.
  • Schedule instructions according to the dataflow as well as structural constraints :
    • Configurable window size.
    • Configurable superscalar width.
    • Configurable number of execution lanes.
    • 3-level cache hierarchy.
    • Branch direction and target prediction.
    • Oracle memory disambiguation.
  • Report overall cycle count.
  • See README for more detailed use information.

135 small traces (click to download) :

  • 30M Insts.
  • Mix of compute (INT and FP), crypto and server-class
  • Used for ranking.

2013 large traces (click to download) :

  • 100M Insts.
  • Mix of compute (INT and FP), crypto and server-class
  • Not used for ranking.

General Rules

The championship has three tracks, each designing value predictors with different storage budgets: 8KB, 32KB, and unlimited size (Competitors can choose not to compete in a particular budget category). In each category an additional side buffer of unbounded size is allowed for tracking additional information used by the predictor (e.g., global history). Top submissions will be invited to present at the CVP workshop. All source code, write-ups and performance results will be made publicly available through the leaderboard.

Before You Submit

Each submission should include an abstract, write-up (up to 4 pages using a standard double-column template), and predictor code. We should be able to simulate your predictor with a reasonable amount of memory (not exceeding 16GB), and within six hours of simulation time. Also, your predictors must not violate causality (cannot use future information to predict the current value). Furthermore, you are not allowed to spawn another thread from your predictor code. Lastly, the simulator must be run with default parameters (e.g., issue-width, window size, etc.), although authors are welcome to change the default values for their own experiments.

  • Please mention the key evaluation result (the Average [geomean] IPC obtained by your predictor over the 135 public traces) in the abstract.
  • Please report the storage computations in a dedicated table. Specifically, each predictor structure should have its own line, how many bits are used, and a pointer to code structure that implements this structure. While there is no limit on the size of the side buffer used to track inflight metadata, we also ask that you provide the number of bits required (or at least number of bits per entry). For authors concerned with page-count, this table may be added as appendix.
  • In the code, please comment the structures that are used with what the structure corresponds to, how many bits it is using if it counts toward the storage budget, and why not if it does not, as well as a pointer to the line in the table of the write-up corresponding to that structure.
  • In general, we strongly encourage authors to comment their code to help with the review process.

Submissions may be sent back to the contestants after a short write-up and code review if the write-up is not clear enough and/or there are issues with the code (e.g., does not compile, does not run, does not follow the rules).

Submitting Your Predictor

To submit your entry, you will first need to create a tarball named after the first author, using the following instructions.

1. Create a directory with the full name of the first author (say John Smith) and CVP subdirectories:

mkdir JohnSmith
cd JohnSmith
mkdir cvp8KB
mkdir cvp32KB
mkdir cvpUnlimited

2. Copy the predictor files mypredictor.h and mypredictor.cc to each relevant directory. For example, to submit to the 8KB track, you would have:

cvp8KB/mypredictor.h
cvp8KB/mypredictor.cc

You are allowed to submit to multiple track within the same tarball. For example to submit to the 32KB category also, you would take the 32KB predictor and copy it to cvp32KB directory as cvp32KB/mypredictor.h and cvp32KB/mypredictor.cc

3. Copy your writeup as paper.pdf within the JohnSmith directory. The paper must be written in conference format (double column, 10 point font) with a limit of 4-pages. The paper should clearly describe the organization of the predictor, the working of the predictor, and computation of the storage budget.

4. Create a text file called README.txt within the JohnSmith directory with the following information:

1. Contact author name, institution and email address.
2. Any conflicts authors have with organizers.
3. Which track(s) your submission is targeting.

5. Type "ls" (It should now give you the following)

==
cvp32KB/
cvp8KB/
cvpUnlimited/
paper.pdf
README.txt
==

6. Create the zipped tarball, using the following commands:

cd .. tar -cvf JohnSmith.tar JohnSmith/ gzip JohnSmith.tar.gz

7. To submit your entry, send an email to [email protected] with the following:

Author Names (in the order)
Tarball (AuthorName.tar.gz)