EEC 116 Collaboration Policy
There is a fine line between working together and copying. Working
with others, asking questions, and explaining concepts are
important steps in the learning process and are strongly encouraged.
Copying someone else's work or allowing your work to be copied does
not promote learning, is unfair to others, and is not allowed in
this course. The remainder of this document attempts to make the
separation between encouraged collaboration and unpermitted
collaboration as clear as possible.
If in doubt, play it safe and ask the instructor first!
Encouraged collaboration
These things are encouraged and are allowed at all times.
- Discussing material covered in lecture, or the readings.
- Discussing the requirements of an assignment.
- Discussing features of the languages, tools, and libraries
used in the class.
- Discussing general concepts of designing, layout, or
debugging. Encouraged example statements/exchanges include,
- "It worked well to test each module independently
before assembling the whole system"
- "When something doesn't work right, first look at all
input signals in the waveform viewer."
- "What should I do when I get a DRC error but I can't
find the location of the problem?" A: "Try running DRC
on halves, quarters, eighths, etc. until you find the
location."
- Any discussion between you and the instructor. You
are welcome to discuss any and all ideas, design, debugging,
and details with the instructor.
Permitted collaboration, but only if documented
When you engage in more detailed discussions of assignments, you
must include the name of the person(s) who assisted you and properly
credit their contribution to your work. This is akin to acknowledging
a reference in a research paper. These cases include:
- Discussing more detailed concepts of designing, layout, or
debugging.
- Some example exchanges requiring citation are:
- "Laying out my cells is requiring so much work, the
cells are very crowded! Is 10 lambda too short?" A:
"Yes, that is much too short, they should be taller."
- "My wires are so tangled, I can't keep them straight."
A: "Did you remember to route the odd levels
horizontally and the even levels verically?"
Unpermitted collaboration
The overall guideline for unpermitted collaboration is that
you must submit work which represents your original, independent
effort. It should not be based on, influenced by, or copied from
anyone else's work--including people not enrolled in the course.
- Copying work. This is the most blatant violation. You
should not be writing down anyone else's work, or allowing
anyone else to write down your work.
- Using work from past quarters. Using someone's work or
solutions from a previous quarter is an obvious violation.
- Looking closely at someone else's layout. You should never
examine anyone else's layout before yours is submitted; whether
it is on the screen, printed, or written out by hand.
- Debugging with another person. Working at the same computer
as someone and trying to fix a bug is not allowed. It makes it
too easy to look over someone else's work, and allows
(sometimes unintended) copying. Describing to someone your
problem and asking for advice on how to fix it is okay, but
you should do the actual debugging yourself.
- Copying someone else's high-level design. Discussing
high-level design with someone else and sharing ideas and
critiquing each other's design is okay if attributed. However,
just taking someone else's design is not allowed. It is akin to
taking someone else's outline for a research paper and basing
your paper on that.
- Discussing assignments in such detail that you duplicate
a portion of someone else's work in your own design.
This policy is based on the collaboration policy for CS
106X at Stanford.
Last Update: April 28, 2005