VCL Guidelines

Conventions, and good group etiquette

• File names for files shared among others
  Include YEAR.MONTH.DAY.TIME somewhere in the filename so files sort by date when listed out. Include year when versions are likely to be needed over different years. Ex: isscc08.2007.09.18.1530.ppt for a copy saved at 3:30pm on Sept. 18.

• Make frequent backup copies in a subdirectory called something like "backup" or "bkup" with subdirectories in there that are named by the day and time of the backup. For example, PaperDir/bkup/2007.09.18.1530/BackupFiles and keep the base name the same.

  Copy only important hand-typed files into backups. There should be no generated files (.ps, .pdf, etc.) or files that are not changing often such as figures. This is to keep the size of the backup from wasting disk space.

  For extra-readable backups, copy files using "cp -p" which preserves the last modification time of each file.

• Normally use only lower-case letters in filenames and directory names (for faster typing).

• Write text files (documents, code, etc.) with no more than 80 columns of text. Many people use multiple 80-column terminals side by side and wider columns are very annoying.

• Rebooting VCL computers
  Reboot our unix computers only as a last resort when you have tried every other solution without success. If you do reboot a machine, you MUST check to see if other people are logged into the computer and you MUST check with them if it is ok to reboot unless the reboot is extremely urgent. Otherwise, people can lose important data.

Guidelines for presentations and papers

• All
  • Always keep in mind the point or story you are telling. The readers/audience want to understand your work and it is your job to get the key points across clearly.
  • All ink has a cost (readers' attention); use it wisely. Your readers will give your work only so much attention before they quit or tune out. This includes text, figures, line segments, line crossings, etc. Use ink only if it deserves to be there, or earns its usage.
  • Almost all rules can be broken for increased clarity.
  • Common pitfall: use a minimum number of fonts across text and figures. This includes font types, sizes, bold, italics, etc.
  • Common pitfall: avoid opinions and unsupported assertions that may very well be true but come across very poorly when they are not backed up by things like data or references.

• Papers
  • Units should never be italicized. Use our \mmm latex macro for mm^2.
  • If a variable has more than one letter in it, use \emph{} instead of math mode. Especially when there are mixed letters and numbers, it looks strange. e.g., "Sp0"
  • \log is a built-in math function. It is not italicized. use \log_2 for log base 2. Only variables are italicized in equations!
  • Avoid saying things like, "Note that..." Readers should note everything. Just say it.
  • Don't leave blank lines between paragraph text and an "eqnarray". It uses unnecessary white space.
  • Generally avoid using "improves". Say what you mean instead. Say "increased throughput", not "improved throughput".

• Figures
  • Watch font sizes in figures—they are sometimes way too small
  • Crop figures to remove white space around them (especially for papers). This is easily done in Adobe Acrobat with: Tools > Advanced Editing > Crop Tool

• Talk slides
  • All text and figures must be easy to read or removed. Around 14 or 12 point fonts are the minimum.
  • Normally 3 or 4 fonts maximum per slide/talk. Ideally includes 1 font type, ~2 sizes, italics for emphasis, use bold for emphasis sparingly.
  • As a rule, only include material in your paper for a conference presentation.
  • Normally, put nothing on a slide that the audience does not have time to absorb.
  • Target 1 minute/slide. ~1/3 minute per slide for title, outline and acknowledgement slides.

• Talks
  • Overall goal: getting a small number of key ideas across to distracted listeners from a variety of backgrounds.
  • Try for a 3 or 4 main points.
  • Material on giving better presentations:
    • Terrible Presentations (and how to not give one), K. Compton and M. Chang. Here is a local copy as of Nov 2008.

Common Errors in Writing

• Citations are parenthetical, not part of the regular text
  Do not refer to them in the text, e.g., "In [3], the authors..."
• No unexplained citations in a long row
  It looks like you just copied a bunch of cites from somewhere and perhaps you didn't even read them.
  E.g., "Some chips have low clock speeds [5], [6], [7], [8]." Using range notation (e.g., [5-8]) is just as bad. The best option is to keep the citations and say something intelligent about each one—compare, contrast, or summarize them.
• Put entire equations in math mode
  Use "$3 \times 3$" and not "3 $\times$ 3". It makes the spaces correct. For an extra-nice looking appearance, use "$3 \times 3$" instead of "3 X 3".
• Italicize all variables
  Yes, this means everywhere; including: text, equations, tables, and figures.
• Do not italicize units such as "V", "ns", etc.
• Put a non-breaking space between a number and its units. For example in latex: "1.2~V", "2~ns", etc.
• Always define acronyms the first time they are used. For example, "Many-core globally asynchronous locally synchronou (GALS) processing arrays are..."
• To get quotes correct in latex, use two "back ticks" for the open quote and two apostrophes for the closing quote like this: ``in quotes.''
• Watch spaces around commas and quotes. There should never be a space before commas and quotes should be formatted, "like this one."

Long-running Jobs

• Urgent jobs needed for an important deadline have first priority on the fastest cpus and/or machines with the largest amounts of memory, if needed.
• Normally, jobs that run more than a brief amount of time (let's say 10 minutes) should be nice'd to at least 4. This is less important if you are running on your own machine.
• Normally, jobs that run more than a long time (let's say one day) and also where the user is running many copies of the job across many cpus, should be nice'd to 19 (the maximum).
• Nice'ing should be done more aggressively if:
  • someone is working on the console of the machine,
  • you are using the fastest cpus in the group (cookie and olive currently), or
  • you are running multiple jobs on one machine.
• do not run jobs on pizza other than commands that are greatly sped up with direct access to disks such as search commands like find or grep.

Travel Expense Guidelines

• The lowest cost method of transportation must be used.
• Keep meal expenses reasonable and low—$10 per meal max.
• Normally, rental cars can not be reimbursed and an airport shuttle should be used if you fly. See if the hotel offers a free shuttle.
• Talk to me first before you spend any money more than:
  1. Transportation to the conference including a shuttle van
  2. Basic conference registration
  3. A reasonable low-cost hotel room (share with others if possible); normally, it will be ok for a presenting author to stay at the conference's hotel
  4. Meals
• If traveling with others, get an individual receipt since a combined receipt can not be used on a travel reimbursement.

Guidelines for Responses to Reviewers' Comments

• Make sure you know exactly what the reviewer is complaining/commenting about. Not answering his question is the best way to get him frustrated and get your paper rejected permanently.
• Normally treat each reviewer's comment as one of three things:
  
  • You misunderstood, let me clear it up, or
  • You have a valid point, we have made the following change to our paper to address it. [followed by quote of new text], or
  • A combination of the first two points.
• So there is normally no point in explaining something to the reviewers if you didn't add it to the paper. It is likely to raise more questions.
• As a rule, every comment by a reviewer should result in 1 or more changes in the text. Even if the comment is not valid or nonsense, it should result in a change because it is an indication something can be explained better.
• Only in rare cases should you very very gently tell a reviewer their point is wrong and you won't change the paper.
• The ideal response to a reviewer would be several changes made to the text and/or figures, and those changes listed in the response. If all comments are addressed in this way, it will be much more difficult for the reviewer to recommend rejection.

Guidelines for Writing Reviews for External Papers

• Reviewers typically begin their review by writing a summary of the paper. There really is no point other than to show you read it. Keep your summary to a few (~2) sentences maxmum.
• Limit comments on grammar and writing style to 1) stating whether there are problems, and 2) mentioning a few recurring problems (e.g., use of technical terms that have not been defined, problems with basic readability, etc.)
• Key points to determine overall publish/reject recommendation:
  1. Does the work advance the state of the art in a key area such as speed, energy, circuit area, signal processing performance, etc.?
     • Is authors' and previous work's data fairly presented? (e.g., scaled for cmos technology)
     • Did they leave out any important related work? Is it really new?
     • Is their contribution significant enough to deserve publication in this journal/conference?
  2. Does the paper present the ideas and data clearly enough that readers will learn? (relates more to how serious of a revision is required)
• Also check whether the authors are really fair and accurate in their arguments about their work and the work of others. Have they built a solid case (not perfect, but solid) to show their work is novel and is in an area of interest to readers? For example, comparing power and not energy if their design is very slow.