Some debugging tips from the TAs.  Overall your best debugging tool is the scientific method:
 1) hypothesis: "The circuit should work like this: signal A goes high here, then signal B, blah blah blah"
 2) experiment: Use the logic analyzer, and find out that signal B doesn't do what you thought it would.
It's particularly useful if you explain step 1 out loud to someone before showing it on the analyzer.

ksjp


From Tony:

1) Hitting your head on the desk doesn't help
after the first time.

2) Use all the resources around you, especially
the other students in lab.

3) Design Manager reports warnings because they
help you debug!  There's even a hierarchy so
it's not totally impossible to track down
unloaded wires etc.

$Xblahblahblah refers to a component or wire on
page X of the main schematic.

$3XYZ\blah\blah refers to a subcomponent in
component XYZ.

Highlighting any component will cause the name
of that component (in computer and human readable
form) to be displayed on the bottom right hand
corner of the screen.

4) Run old tests whenever you suspect something
got screwed up.  Ptest is a good for testing UART.
Check2.bit test wiring/chips.

5) Output useful signals to unused pins so you
can trigger on a particular event/block.  So
output start_block so you can zoom in and see
what a particular block is doing on the scope.

6) Bugs tend to creep into programs past 3am.
Be very careful if you choose to debug while
you're tired.  Take breaks to refresh yourself
and don't stare at the screen for 6 hours in
a row.

7) Alot of times bugs are "obvious" mistakes.
Debug the components your partner designed
rather than your own.  Or try explaining
what your block does to your partner.
Stupid mistakes make alot of sense until
you catch yourself saying them out loud.

Most importantly, nobody said it would be
easy, so don't expect it to be!


From Brett:
- make sure the Xchecker cable is plugged into the board with the proper
orientation
- if Viewlogic explodes and the EDIF writer won't run any longer, you might
have to shutdown the machine and reboot it to get it working again.
- set Camera.exe to dump the serial data to a file to verify what you are
sending


From Prof. Fearing:

(From page 4-110 in Xilinx manual).
Here is a list of pins which are not available to use for
extra debugging outputs:

Already used
TDI P15
TCK P16
TMS P17
INIT P31
M0 P30
M1 P32
M2 P34
HDC P36 (high during configuration, then general IO)
LDC P37 (low during configuration, then general IO)
DONE P53
PROG P55
DIN  P71
CCLK P73
TDO P75

VCC P2, P11, P22, P33, P42, P54, P63, P74,
GND P12, P21, P31, P43, P52, P64, P76, P1

Don't put outputs on the switch lines because you will fry your Xilinx
if the switch is in the wrong position. These lines are inputs only!
Inputs only:
P19, P20, P23, P24, P25, P26, P27, P28


>From Sunil:
-When we were running the program which turns the
schematics into xilinx stuff, we had to save the stuff on C:\temp. So when
another group used that terminal, they had access to the compiled
project...I know atleast one occasion where a fellow classmate accidently
downloaded my code onto the xilinx...and started getting the exact error I
was getting. So tell people to cleanup c:\temp everytime they log in/out.

I don't know if this still occurs with the current version of the software.