Its a good article in general with one very minor error. It explains you want on board LEDs and switches because its too easy to screw up soldering your own. The core reason why you want LEDs and switches on a FPGA board, why you'd buy included or solder your own, is too often during debugging this will be your UI.<p>So you are in a quandary about which of several PLL designs to implement. Its not 1990 anymore, you've probably got space on the chip to put them all in, and select which operates in real time using the switches. Then you wire up your spectrum analyzer or scope or whatever exotic test gear you require, fire it up, and instantly flip between implementations while its running. You figured it out in theory, now in practice which one actually has the fastest lock up, or the lowest noise performance, or the least noise spurs at critical freqs? Just flip the switches and find out.<p>And on the LED side, there's a lot of testing patterns that boil down to "and when the state machine hits this state, aside from entering state 8, it also fires the LED on a little timer" Again hook up all your real world hardware and see what happens.<p>True, you could implement a VGA display and PS/2 keyboard without much hardware work, but then you have to drive them probably with an embedded processor, a little picoblaze or whatever running the UI... and all that screwing around to basically re-implement LEDs and switches, just slower and harder to do.<p>There are in circuit analysis tools, some of them pretty cool, and some of them are actually reliable, but fundamentally you're always going to find some LEDs and switches, its just too easy and convenient.<p>There is also the "hello world" test proving your hardware and dev system aren't screwed up, everyone has their personal favorite, what I always use is a simple 3-input switch / 2 output LED full adder.<p>I've also been known to do things like output the version number of my project on the LEDs. Hey, they're just sitting there and everyone who's actually done labwork has had the amusing experience of thinking they're testing version 12 but finding out they uploaded version 11 or whatever.<p>Finally when the analog / hardware side isn't ready, if theres no timeouts and its a strict state machine, I've been known to flip switches as inputs, many millions of times slower than the real hardware works. Hand toggling switches to talk to an I2C slave or SPI is a little tedious, but sometimes the best option. Once you get past layer 2/3 type problems there's higher level protocol tools, some are even cheap like the "bus pirate" or you can send $375K to Agilent for slightly more advanced test equipment.