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.
  Spend time thinking hard about how a reader/listener could possibly get confused. There are a million ways this could happen. Change your material to help a person who might get stuck in that way.
  Make it easy for a reader to understand your work (they will learn, appreciate, accept your paper) rather than challenging (frustration, reject your paper)
- 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.
  "A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that every word tell." –William Strunk
  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.
  Corollary: Probably the best way to have your audience think highly of you after your talk is if you teach them something worthwhile that they did not already know.
- The central dynamic is that you, the speaker, are talking to the members of the audience. As a first check, do the same things you would do if you were talking to two people sitting across from you at a small table. Do not face (talk to) the slides projected onto the wall or on your laptop screen for long periods of time. Close your laptop screen enough so that you can not see it to reduce the temptation. Your slides are there only to illustrate some points; the audience wants to focus on the speaker, not the slides. Do not face (talk to) one person in the audience for long periods of time. Give all members of the audience some eye contact on a regular basis.
- Make it easy for your audience to understand your work. There is a temptation to make it sound complicated so that no one thinks your work is simple but there is a far greater and more likely danger that they will stop listening and think you do not have a deep understanding because you can not present your work clearly.
- Try for a 3 or 4 main points.
- Laser pointer usage. It is very hard for the members of the audience to not follow your laser dot while you are shining it. So do not leave it on too long. Use it only to point out features that can not be easily indicated with words. Don't try to hold the laser dot in one spot but rather move it slowly back and forth (if you want to indicate a single point). Even if you are perfectly calm, the laser dot will shake and people will think you are very nervous. In cases when you can reach over much of the screen with your arm, it is often best to point to things in your slides with your arm rather than using the laser dot. It is more natural and gives the audience some variety. Be careful to not stand in the projector's light too long if you do.
- Ph.D. Exit Seminar and other seminars where you expect some of the audience is not very familiar with your research
  - For the Ph.D. Exit Seminar, use this guideline: the material of the first third of your talk should be understandable by your Mom, the material of the second third of your talk should be understandable by a first-year EE graduate student, the material of the last third of your talk should be understandable by only your advisor. But at the same time, you must make the key results and key significances of your work understandable to everyone in the audience. This requires you to tell people outright.
  - Make it clear which ideas are prior work (give cite on slide and mention author's name) and which ideas are yours (ideally give cite to your publication).
- 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 synchronous (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."
Choose precise and accurate wordings. For example:
- Sometimes the faulty words can be rooted out by reading the bare subject, verb, and object alone. Ex: The SPECpower benchmark, which includes a large number of modules, measures the power consumed by the processor. → The benchmark...measures...power. No it does not—the benchmark does not measure anything!
- 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"
- 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.
- 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")
- Read the wikipedia page on weasel words especially the sections describing Forms
With very few exceptions, avoid passive voice.
- Read the wikipedia page on passive voice
- If you find any of these verbs in your writing, the writing will most likely be more active if you remove and reword:
  - is,
  - was,
  - is being,
  - will have been,
  - would have got,
  - to be,
  - having been.
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.

Before Asking Someone to Proofread and Edit Your Paper

Run @vcl_tex_style_chk $(FILESTEX) Makefile checks
Read latex logs and fix all errors
Proofread it yourself carefully!

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.

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.

Thoughts on staying productive in research

Everyone goes through cycles of struggling ↔ being productive. Here are my top habit suggestions I started in grad school that I still do now:

This is #1 for sure: find a way to kill all distractions for a certain number of hours per day. Real work will never get done with distractions around. Close browser, turn off phone, go to lab, go to library, etc.
Put yourself in a productive mode for a reasonable number of hours every week. When you start a job, you will need to be there from ~9am until ~6pm every day and sometimes spend some time on weekends. As a graduate student, you should be spending at least that much time (subtract time spent on youtube, surfing, texting, etc.--you can't do those things at your future job either).
Make a schedule with goals to be completed for the next month. I work far more efficiently with some deadline stress. Daydreaming and distractions are easier to ignore when I have a deadline coming.
Keep a todo list with specific tasks to be done each day. It is easy to procrastinate on something due in two weeks but easier to attack a number of 30-minute tasks I want to get done today.
Work hard play hard. Except when a huge deadline is nearing, never work Fri and Sat night for sure. Take Sunday off too. Do some fun activities during the week (e.g., Monday night football or Wed night TV). No work whatsoever during those times.

Thoughts on advisor ↔ student interactions and expectations

Freshman/sophomore undergraduate researcher
Work is typically assigned on a daily basis
Beginning graduate student
Student asks many questions
Advisor replies with answers and references to be read
Non-beginning graduate student
If you are a graduate student in my group, you very likely have all the background needed to perform the research and you got a very good grade in the class that covered it.
As a graduate student you should be the one investigating, learning, and *explaining to me* when I ask you questions as your *advisor* and as the chair of your committee who is supposed to verify that you are ready for the MS degree. Of course I am available to help you get unstuck from technical issues, but this needs to be the exceptional case not the normal one.
- Not good:
  student: "what exactly do you want me to do?"
- Good:
  advisor: "did you finish investigating the..."
  student: "yes, I have done this and this"
  student: "I know why the voltage is limited here..."
  student: "We can increase throughput by a special adder tree..."
  advisor: "did you consider this..."
  student: "yes, I did a simple matlab simulation and found that the effect is....and therefore....here is a plot..."
  student: I also found a paper....
  student: We also need to consider this effect....
  student: I think the problem is best viewed in this way...
  student: I did a simple verilog simulation to find out...
Here is another way to look at productivity and creativity—a hack at a simple scale. 2 is the minimum for a productive graduate student. Higher is better!

VCL | ECE Dept. | UC Davis

Last update: May 11, 2013