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.
Use the same idea for subdirectories in a paper directory; for example:
2010.02.10.vers1/
2010.05.04.reviews/
2010.06.12.vers2/
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. Some 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.
- Write clearly and accurately. Almost any other rule can be broken if the resulting text is clearer. Accurate writing will enable a confused or newbie reader to re-read your text and eventually figure out what you are saying.
- Minimize ink. All ink has a cost (readers' attention) so 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.
  Corollary: Use a minimum number of fonts across text and figures. This includes font types, sizes, bold, italics, etc.
- For dissertations, theses, papers, and talks, work in this order:
  1. Do research, get data
  2. Generate graphs, figures, tables of data
  3. Write outline that is very well thought through. Probably do it in powerpoint.
  4. Write detailed outline where the most detailed points are a few paragraphs. Think through what will go inside each paragraph while you write the outline.
  5. Write the text
  6. Write the conclusion, abstract, title
  7. Edit with the key goals of clarity and minimal ink.
    1. Groups of sentences: logical and smooth flow of thoughts without repeating or gaps
    2. Individual sentences: logical and smooth
    3. Style and grammar
- As a rule, emphasize the metrics of throughput/area and work/energy (for example, fft_transforms/nJ). Make sure area numbers and especially power numbers are always given in clear context—for example, if your throughput/area is 10x higher than any previous work but the throughput is 2x higher than the second highest (but more than 5x smaller area at the same time) and the area is 2x smaller than the second smallest (but more than 5x higher throughput at the same time), then it would be easy for readers to miss how much better your results really are if you don't write carefully.
Papers
- Units should never be italicized. Use our \mmm latex macro for mm^2.
  Todo: integrate siunitx package.
- Variables are normally always italicized.
- If a variable has more than one letter in it, use $\mathit{Vdd}$ instead of $Vdd$. Especially when there are mixed letters and numbers, it looks strange. e.g., $Vdd = 1$ is formatted by latex exactly the same as V * d * d = 1.
  Todo: is it ok to use \emph{} in text mode?
  Notes from jowens: "Superscripts and subscripts are in italic type if they represent variables, quantities, or running numbers. They are in roman type if they are descriptive.": http://physics.nist.gov/cuu/Units/checklist.html )
  The nice \text macro is in amstext: http://ctan.math.utah.edu/ctan/tex-archive/help/Catalogue/entries/amstext.html
- \log is a built-in math function. It is not italicized. use \log_2 for log base 2. Only variables are italicized in equations!
- Don't leave blank lines between paragraph text and an "eqnarray". It uses unnecessary white space.
  Todo: Does "align" do everything we need? Eqnarray is obsolete.
- If journal/conference allows, make sure to request that some reviewers be excluded ("traditional computer architects," others groups that have given unfair criticism and failed to cite our work in the past (ask around the lab if you don't know the guilty ones), etc.).
- Important: whenever you have a paper accepted, make sure it gets uploaded to SRC and C2S2. (it isn't yet clear whether students can do this themselves, and whether it might be best to upload when the paper is submitted.)
- Add a bibtex entry to /net/pizza/vcl/doc/vcl.bib when your paper is accepted or thesis/dissertation is signed.
Figures
- Watch font sizes in figures—they are sometimes way too small
- Probably use a sans-serif font (such as Ariel) for figures
- 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.
  - The Academic Job Talk, Graduate Connections Newsletter, pp 4-7, Office of Graduate Studies, University of Nebraska-Lincoln, Feb. 2011.
Dissertations, theses, and technical reports

Common Errors and Weaknesses in Writing

No general unsubstantiated opinions, unsupported assertions, or guesses that may very well be true but come across very poorly when they are not backed up by things like data or references. For example, "most DSP architectures use clock gating," or "many processors are designed with speed as the most important design target."
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 the author copied a bunch of cites from somewhere and perhaps did not even read them. For example, "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. For example, "Some chips have low clock speeds due to low supply voltage [5], old fabrication technology [6], very long wires [7], or very long pipeline stages [8]."
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," "mm²," 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."
Be precise in choosing words. For example:
- Almost never use: better, best, worse, and worst which are imprecise value judgments
  Avoid: "our area is 3x better than previous work"
  Instead: "our area is 3x smaller than previous work"
  Avoid: "our area is improved 3x compared to previous work"
  Instead: "our area is reduced 3x compared to previous work"
- Units of speed are m/s, not Hz (a little picky I admit)
  Avoid: "the processor runs at a max speed of 1.2 GHz"
  Instead: "the processor operates at a maximum clock frequency of 1.2 GHz" (use "clock frequency" not just "frequency")
- Use only properly.
  Avoid: "The processor only dissipates 5 mW." (technically, this is saying the only activity of the processor is that it dissipates 5 mW.)
  Instead: "The processor dissipates only 5 mW."
- Avoid "analysis." Give an analysis, don't talk about it.
- Avoid "evaluation." Give an evaluation, don't talk about it.
- Avoid overusing "results." Give results, don't talk about it.
- Avoid overusing "performance." Do you really mean throughput, clock rate, or latency? If so, just say what you mean.
There is no sense of time inside of a paper so do not add it.
Avoid: "we will derive the equation in Section V"
Instead: "the equation is derived in Section V" (passive, not ideal)
Instead: "Section V provides a derivation of the equation" (not ideal, but maybe the best option)
Avoid: "The data will be shown in Ch. 5"
Instead: "Simulation results and analysis are shown in Ch. 5"
Never write first-person "I" or "we" unless really necessary
- Avoid first-person: "We ran the simulation and we saw that P = 10 mW."
- Avoid passive: "The simulation was run and it was seen that P = 10 mW."
- Say what you mean and skip the obvious: "Simulation results predict P = 10 mW." Or, "Circuit simulations using the PTM models predict P = 10 mW."
Never write "you"
Never use "works" to refer to other research--it is always singular: "Previous work in this area has shown..."
Never use "researches" to refer to other research--it is always singular: "Previous research in this area has shown..."
Never write "wanna." It is slang.
Never write "gonna." It is slang.
Never write "got." It is slang.
Never write "have to" or "has to." They are too informal.
Avoid "need," "needs," or "need to." They are too informal.
Never write "Note that..." Readers should note everything. Just say it.
Never write "It is interesting..." Everything should be interesting. Just say it.
Never write "It is important..." Everything should be important. Just say it.
Always spell check before passing the paper on to someone else.

Long-running Computer Jobs

We have about 35 cpus in the linux machines in the group that need to be shared among all of us. Here are a few principles for sharing them:

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 hour) 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.

When Your Paper is Submitted

Immediately submit a copy to the SRC web site.

When Your Paper is Accepted

List its reference on the VCL home page with "to appear" or "in press," and put a pdf copy you-know-where.
Post a web page with the paper's information and link to this page from the VCL home page's reference.
Add an entry in /net/pizza/vcl/doc/vcl.bib and test that it works.
Order business cards from the ECE office as soon as your first conference paper is accepted. They take about 2 weeks to arrive.

After Your Paper Appears at the Conference or in the Journal

Update the reference on the VCL home page.
Update the paper's web page with the final pdf.
Update the entry in /net/pizza/vcl/doc/vcl.bib and test that it works.

Travel Expense Guidelines

Our sponsors and the university expect us to use our funds wisely. Therefore, we must follow these guidelines concerning expenses for which you would like to be reimbursed.

The lowest cost method of transportation must be used.
Keep meal expenses reasonable and low—$10 per meal max.
Normally, rental cars and taxis can not be reimbursed unless it is absolutely necessary. An airport shuttle should be used if you fly. See if the hotel offers a free shuttle to/from the airport.
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.
Register on time. If you register late, you will need to pay the additional cost. The reasoning is that this late fee could have been used to pay other students' tuition and fees and it is not fair to penalize others for one person's lateness.

There can be exceptions to these rules when it makes sense and when funding is available, but you must talk to me (Bevan) first; thanks.

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

Should you accept a request to review a manuscript?
- Good reason #1: you can add the journal to a list on your CV showing journals for which you have performed reviews. Of course more than one review per journal has less value than the first.
- Good reason #2: making sure the authors have cited your related work which is very important especially as your work is becoming more widely known. It also increases your citation count which is very important. If the authors have failed to cite work that is closely related, ask the authors to include it in a way that does not give away your identity if the work is yours.
- Good reason #3: learn the very latest research results in an area you care about
Writing a good review
- Reviewers typically begin their review by writing a summary of the paper. There really is no point other than to show you read the manuscript. Keep your summary to a few (~2) sentences maximum.
- 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.

VCL | ECE Dept. | UC Davis

Last update: December 5, 2011