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)

  • A few key goals and pitfalls for papers
    • Present something that is useful to readers--that can be applied to different domains besides the one you use
    • Show tradeoffs whenever it makes sense; for example, among different approaches or by sweeping variables
    • Give a sense that some "space of interest" has been covered adequately. In other words, you would not want a reader to think, "ok, you covered A and B, how about C?"
    • Avoid having the appearance of "I built just this one specific idea"

  • 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.

  • It is always better to let data speak for itself rather than using vague language. For example:
    "2.57 GHz at a supply voltage of 1.00 V" rather than "good performance."
    "Higher throughput than the Abc 1.2 GHz GPU and Def i7-2500 processor" rather than "Faster than the other architectures."
    "10x lower energy" rather than "10x improved energy".

  • For papers, talks, dissertations, and theses, work in this order:
    1. Do research, measure data
    2. Generate graphs, figures, and tables
    3. Write a first-pass Abstract to commit to the paper's key points—the paper's story. It should be understandable (as much as possible) by someone not familiar with your subject area. It should also include the most important results of your work--the abstract should draw readers in and tell them why they should bother to read the rest of the document!
    4. Write an outline that is very well thought through. Probably do it in powerpoint.
    5. Write a detailed outline where the most detailed points are a few paragraphs. Think through what will go inside each paragraph while you write the outline.
    6. Write the text
    7. Finalize the Abstract. Write the Conclusion and Title.
    8. Edit with the key goals of 1) clarity and 2) 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

  • Watch significant digits. For example, even if the calculation shows an energy reduction of 54.182×, think of it this way, if you measured a different chip, would the measurements be within 1% of the first measurements? Probably not. So more than three significant digits (54.2×) is not warranted.

  • 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.

  • Thanking sponsors is very important. Take the time to find out who should be thanked. ST requests, "The authors would like to thank STMicroelectronics for donating the chip fabrication" for papers that use their chips.

  • The following general outline works very well for many kinds of research whether writing a thesis or a paper to be published. I recommend using it as a starting point and modifying to suit your case as necessary. Read a few recent VCL papers and VCL theses to see how other students have constructed their outlines.

    1. Introduction — contains an overview of the project, arguments why the research is important, and a very short obligatory overview of the paper/thesis.

    2. Background

    3. "Theoretical" description of what you did — this is a description that others can easily adapt to other settings. For example, this might include new algorithms.

    4. A description of what you designed and implemented. For example, this might be a verilog hardware design.

    5. Simulated and/or measured results of what you designed and implemented. For example, maximum clock frequency, energy dissipation per workload calculation, chip area, numerical SNR, etc.

    6. Comparison of your work with other work. Ideally with other published work. Otherwise with the fairest comparisons you can make with other approaches implemented. This almost certainly includes a very large table with all known similar prior work in the top rows and "This Work" on the last row. Columns on the left side of the table are more basic data such as max clock freq., energy dissipation, etc. Data in columns become increasingly complex as they progress to the right side of the table, for example, "Normalized Energy × Time".

    7. Future work — think of the things you would have worked on next if you had more time. These are also the projects a future student would work on if he/she were to continue your work. Only a few pages.

• 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" for a series of equations. It adds too much white space.
    Todo: Does "align" do everything we need? Eqnarray is possibly outdated/obsolete.

  • Make sure you cite all appropriate work, especially closely-related work done in our group.

  • If journal/conference allows, request that some reviewers be excluded ("traditional computer architects," other 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 to upload it to the SRC web site.

  • 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—it is easy to make them way too small

  • Probably use a sans-serif font (such as Arial) 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 3 or 4 main points per talk, 1 main point per slide.

  • Specific important items for an excellent talk
    • Get constructive criticism from friendly colleagues on slides
    • Get constructive criticism from friendly colleagues on a practice talk
    • Get really tough questions (the toughest reasonable ones they can think of) from friendly colleagues after a practice talk
    • Investigate and type up excellent replies to those really tough questions
    • Make sure you are comfortable saying, "That is a really good question and I do not know the answer." Afterwards say something like, "I will check with my co-authors..." "I do not recall the data..." "We did not investigate that..." Of course never bluff.
    • Finish your slides ~3 days before your talk and even if they can be changed, don't do it except for minor tweaks.
    • Do not memorize your talk
    • Do not memorize nothing at all
    • Memorize the topic of each slide and the main points on each. This will be automatic after you practice out loud a few times.
    • Do not speak exactly what is on your slides
    • Practice the talk out loud as many times as you can. Ideally in a setting as similar as possible to the setting of your talk (slides projected on wall, face away from screen, user laser pointer, perhaps wear your presentation clothes, etc.)
    • Wear a suit with tie, or coat and tie with dress slacks (men) or equivalent dressiness (women)
    • Whenever possible, go to the room/location of your talk when the room is empty and stand at the podium for 15+ minutes looking at the audience's chairs. Practice as much of the talk as you can there.
    • 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 you will look 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. Do 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

  See the instructions at the bottom of the "Getting Started in the VCL lab" web page when you are completely done.

  Although the CERL laboratory is not well known, it is the umbrella under which the computer engineering research groups are publishing technical reports (and dissertations and theses which are published as technical reports). Technical reports from the VCL group should follow the following numbering standard: ECE-VCL-YYYY-## where YYYY is the year of publication, and ## is the tech report number.

  To publish a technical report, follow these steps:
  1. Look in the /afs/ece.ucdavis.edu/labs/cerl/WebPage/techreports to see the next unused number for the year of your publication. This number will be your tech report number (## from above).
  2. Make a new directory to hold the tech report number (i.e. mkdir 2011-2). You might need to either get access to klog in this directory from Dr. Baas or have him (or someone else with access) make the directory for you.
  3. Navigate to /afs/ece.ucdavis.edu/labs/vcl/WebPage/pubs and make a new directory for your paper using the VCL scheme:
     • TechReport: YYYY.MM.techreport.ReducedTitle
     • Thesis: theses/YYYY-## (same as determined in step 1)
  4. Make a .JPG of the first page of the .PDF of your paper which has a height of 350 pixels.
  5. Put the image and your .PDF in your new directory.
  6. Copy a index.html file from an adjacent publication page in the folder, and modify so that it contains the correct information for your paper and attached files.
  7. Make sure all your files are readable. For example:
     cd ..
     chmod -R a+X yournewdirectory
     chmod -R a+r yournewdirectory
  8. Navigate back to the CERL folder you created (i.e. /afs/ece.ucdavis.edu/labs/cerl/WebPage/techreports/2011-2)
  9. Copy the .HTML file that redirects, you can do so by doing:
     cp ../2011-2/index.html .
  10. Modify that .HTML to point to the URL of the directory you made in the VCL folder.
  11. Add a link to the /afs/ece.ucdavis.edu/labs/vcl/WebPage/index.html file, following the formatting of adjacent papers.

  Always use the URL you created to link to your paper. (i.e. http://www.ece.ucdavis.edu/vcl/pubs/theses/2011-2)

• Feedback from me on your writing

  • Please take my comments not as "these are the only things that need fixing" but rather as giving an indication of the types of issues I believe are in your writing that must be improved before it is ready. So after fixing the specific examples pointed out to you, go through your entire writing looking for analogous issues, and fix them before the next review cycle.

  • The ideal situation is that your thesis/paper is well written, comments are brief, and editing effort is short. Each editing cycle takes a lot of your time and my time and is tiring and stresful. Please try to do the best job on each version and not scrape by and therefore end up with many review cycles.

  • Keep improving your thesis until it is signed. Writing is never done, you just quit when it is good enough.

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, latency, or something else? 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.
  
  "Active voice makes subjects do something (to something); passive voice permits subjects to have something done to them (by someone or something). Some argue that active voice is more muscular, direct, and succinct, passive voice flabbier, more indirect, and wordier. If you want your words to seem impersonal, indirect, and noncommittal, passive is the choice, but otherwise, active voice is almost invariably likely to prove more effective." –The Columbia Guide to Standard American English (1993)
  • 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 them 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 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

• The lowest cost method of transportation must be used.
• Keep meal expenses reasonable and low—$12 per meal maximum.
• 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 the following items and you would like to get reimbursed for them:
  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.

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.
• A good example of how to format a reviewer response can be found at /net/pizza/vcl/doc/2006.06.JSSC/2007.08.15.submitted/yu.asap.response.comments2.pdf
• When I was an Associate Editor for several IEEE journals, here is what I would often write to authors along with their reviews: "I ask you to include a complete listing of all reviewer suggestions with a description of how you addressed each of them in your revised manuscript or your explanation if you believe there was a misunderstanding. It is essential that each of the reviewers' comments is addressed. Even in the case of reviewer misunderstandings, it is worthwhile to consider whether a change in the manuscript could be made to avoid the misunderstanding for other readers. Your response to the reviewers' comments should normally be an explanation of what you have changed, added, or removed from the manuscript to address particular comments, and not an explanation by itself since that explanation would be missed by journal readers and should be included in the manuscript."
  I think it is a very good practice for all authors.

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: learn the very latest research results in an area you care about.

  • Good reason #3: making sure the authors have cited related work (for example, your related work which is very important especially as your work is becoming more widely known. It also increases your citation count which is 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 includes yours.

• 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.

  • Keep comments on grammar and writing style short and limit them 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)

  • Consider 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

• 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.

Preparing for your Ph.D. preliminary exam

• There are many topics to be familiar with for the preliminary examinations. In Active and Passive Circuits, for example, you must know high frequency device models and derive frequency responses, the principles behind feedback and stability, what the Miller effect is and how to apply it etc. However, you must not neglect the fundamentals, review them constantly. Spend 10 to 15 minutes writing down the device equations and all the basic transistor amplifiers along with gain, input impedance, output impedance, etc. every morning and evening until you can recite and derive these subjects in your sleep.

  It is natural to feel very nervous before the examinations. Treat them like you would a race. You wouldn't run 10 miles the day before you compete in a race, so don't do any heavy thinking or studying the night before your exam. Rather, do something you enjoy and is not very mentally taxing. However, absolutely make sure that you get a lot of rest the night before your exam. Like training for a race, the more work you put into preparing in the months and weeks before the exams, the more prepared you will be for the exams themselves. Do not cram. Practicing answering questions on a white board aloud in front of your peers is also very helpful. Be sure that you can explain every step of the problem you are solving and think about questions that could be asked during the solution process.

• Digital Systems:
  • Be proficient with truth tables, manipulation of Boolean expressions, Karnaugh maps, state diagrams, etc.
  • Exercise problems in textbook are a good starting point.

  Physical Electronics:

  • Be intimately familiar with operation of the pn junction, BJT, and MOSFET.
  • Because this exam is more qualitative, textbook exercise problems are less helpful. The only value in working numerical problems is to get a feel for "typical" values, like what is a "typical" dopant concentration or MOSFET threshold.
  • In physical electronics, it is easy to get distracted by all the equations in the text. Don't focus on memorizing equations. It is more important to understand the underlying physics and be able to explain verbally how everything works.
• General Guidelines:
  Do not take three areas; it is tough to prepare everything for three different domains and yield your best in the exam week on all three domains. Moreover, you may also be occupied with classes/TA during exam week. So, you are suggested to take only 2 subjects and prepare your best.

  Start preparing for the exam as early as possible (Ideally beginning of Fall quarter).

  Textbooks and class notes are the best resources for revising the materials.

  Check the syllabus carefully for each domain and if your undergrad is not from UCD, please visit different class webpages to get more information about class notes, text books, home works, and exams.

  Ask your lab seniors and students from other labs about type of questions being asked in the exam and their overall experience about the exam.

  Practice all kinds of problems irrespective of difficulty and remember that the follow up questions in the exams may cover a broad range.

  Most of the questions will be conceptual; however, signals and systems domain requires you to remember a lot of formulae related to various transforms (Laplace, Z-transform, Fourier series, Fourier transform, DFT, FFT etc.) and their properties.

  The most important thing is to practice out loud on white board and let senior lab members or others ask you questions well before exam week. You may solve a problem on pen and paper very easily, but solving it quickly on white board before professors during exam is a different story.

  You must attend the mock exams run by some of the senior students before actual exam, about which you will get an announcement from Kyle around first week of January.

  Be interactive with the examiners while solving the problems. The examiners should get a clear idea about your thinking process while you solve the problems.

  Do not be panic during the exam week and keep the spirit high until the exams get over.

  Digital Systems Design:
  Questions related to K-Map implementations

  MUX and Decoder design

  Questions related to timing constraints (set up time, hold time, clk-q, minimum clk period etc.)

  Draw state diagram for a given case and implement using Moore/Mealy machine

  Serial adder design

  FPGA vs. ASIC

  Name the circuit (Single pole-double throw (SPDT) switch containing a coil), implement the same circuit as XOR, AND, OR.

  Ring oscillator

  Active and Passive Circuits:
  What would be the response of voltage across capacitor in a series RC circuit when a step voltage input is provided to the circuit? What would be the response of capacitor current for the same case? After how much time, output settles to final value? What if a pulse voltage input is provided instead of step? If width of pulse gets reduced, how the circuit output would change? What do you mean by time constant?

  Draw a common base transistor. Draw the AC signal model for the same CB transistor. Find out the voltage gain and output resistance.

  What is a Cascode circuit and why is it used?

  Find out the poles for a given circuit (ideally a cascaded connection) and the corresponding frequency response.

  Some problems related to Op-Amp (logarithmic amplifier, adder).

  Signals and Systems:
  Draw the frequency response of a band-limited signal whose frequency is 5 KHz.

  Draw the frequency response at the output of sampler for that 5KHz signal, if the sampling frequency is 10 KHz.

  How can you retrieve the original baseband signal from the sampled signal?

  Draw the circuit diagram of a synchronous demodulator and state whether whole system is causal, linear, and stable?

  What is the bandwidth of a WBFM (wideband FM) signal?

  What is the Fourier transform of a step input?

  A system consists of sampler, up sampling block, down sampling block, and a low pass filter is given. Find out the frequency response of each block in the system.

  Control system section:
  What is the integration of step signal?

  Whether both step and ramp signals are bounded input?

  Integrator is BIBO stable or not? What do you mean by BIBO stability?

  Is an integrator time invariant?

  Calculate the steady state output of a system for a given sinusoid, how the output would change for the same system with a step input?

  What do you mean by gain margin?

  Can you find gain margin of a given closed loop system without applying the as usual gain margin formula? (Just follow the definition, apply RH criteria and find the value of gain, which would make the system unstable)

  If R-H criteria yields that system gain parameter, K > 0, can K be infinity?

  Find out the break away point on a root locus for a given open loop transfer function.

Preparing for your Ph.D. Qualifying exam

As I see it (you should also ask other profs on your committee what they expect), you should be prepared with:
1. Have a "story" including your prior work and plans for future work that makes a nice overall project

2. Know background of this field. Be able to answer reasonable questions about prior work. Not just mechanics (Smith published a paper in 2005), but being able to explain significance, relevance, etc. The only time I witnessed a student fail a qualifying exam is because he did not know the background well.

3. Have some preliminary results in this area. The ideal is to have a paper ready for submission, in review, or even published but it isn't necessary.

4. Writeup a research proposal. Most students make it too long; I'm hesitant to give an expected length however it does need some solid info.

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:

1. 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.

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

3. 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.

4. 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.

5. 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.

"Why Do So Many Men Never Amount to Anything? Thomas A. Edison, the great inventor, answers this pointed question", The American Magazine, January–June 1921.

"There is no expedient to which a man will not resort to avoid the real labor of thinking," –Sir Joshua Reynolds.

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. 3.5 is the minimum for a productive graduate student. Higher is better!
  
  
  1: "Here is the plot from the simulation you told me to run; I don't know what it means."
  
  2: "Here are the results from some designs. I don't know why, but I plotted X vs. Y, Y vs. Z, and X vs. Z and I don't know if it is working correctly or if it is similar to any previous work."
  
  3: "Here are the results from some designs I found. I implemented essentially the same ideas as what was published in several papers I found. I analyzed them in the same way as what was done in the papers."
  
  4: "Here are the results from some designs I developed. The ideas are different in some cases and the same in some cases from what I found previously published. I believe my designs are better in the key metrics of ...."