Review: Digilent Atlys

[NiHaoMike]

Recently, I graduated from Texas A&M, so I got a FPGA board in order to learn more Verilog. (I ordered it before I graduated so I can get the academic discount.)

Good:
* 4 HDMI I/Os, perfect low cost board for video experimentation.
* At $200 with academic discount, excellent value. (The FPGA on mine is speed grade 3.)
* Protection resistors on most I/Os to prevent short circuits during signal collisions.
* Board is surprisingly small for its capabilities.

Bad:
* Datasheet for Ethernet chip hard to find.
* Micro USB connectors connect upside down. They should have used a right side up connector or put the connectors on the bottom to avoid confusion.
* High speed I/O connector is hard to find, although Digilent does sell a matching one. (A friend of mine, Kat Kelsh, learned that the hard way... I made sure to get the connector when I ordered mine!)
* Stock heatsink seems to be a little on the small side, it gets very warm running the preinstalled demo.
* Power cable is really short and the power adapter blocks other outlets. Best solution would be to design the adapter with a detachable AC cord like most laptop power adapters.
* USB host PIC PMP not connected to FPGA.
* Programming header for USB host PIC not populated.

[joelby]

There are a couple of different options for the VHDCI connector, which are detailed on my Digilent Atlys Resources page.

The PIC programming header's probably not a big deal unless you plan to do a lot of PIC development on it for some reason (I don't think Digilent give you the source code or even a binary image, so be careful before blowing it away). Just stick a 6x1 header into your PICKit, and then balance that in the header pads. Gravity will ensure that you get a perfect electrical contact!

[NiHaoMike]

I eventually plan to connect the board to an Android tablet in order to use the tablet as a user interface. The stock firmware only supports keyboard/mouse and USB drives, with no USB hub support, so it really isn't that useful. But if it's reflashed to connect to an Android tablet, the board can make a very nice logic analyzer (among other things) that does not require a PC to operate.

[NiHaoMike]

After playing around with it some more, I found a few more shortcomings with the board.
* For some odd reason, the connector shields are not directly connected to ground but through a 1M||1n "soft grounding" system.
* Jumper to enable USB boot does not have series resistor. I made a resistored jumper with a 470R resistor to work around that problem.
* USB boot is really slow. Probably an issue with the firmware running on the PIC.
* I'm not certain, but it looks like the PIC cannot hard reset the FPGA in order to load a new firmware. Easy to fix by adding wire jumpers (they were thoughtful enough to bring out 2 unused PIC GPIOs in addition to the PIC programming pins) but a production board should not need any fixes!

[joelby]

* For some odd reason, the connector shields are not directly connected to ground but through a 1M||1n "soft grounding" system.

I can't explain this entirely, but you should generally only ground a shielded cable at one end - so maybe it's something to do with that? The connector itself has plenty of grounds, so the only thing you really need to be aware of is that the connector makes an awful ground point for oscilloscope clips!

* Jumper to enable USB boot does not have series resistor. I made a resistored jumper with a 470R resistor to work around that problem.

Does it need one? Possibly. Otherwise I suppose it ties one of the FPGA outputs and an LED high.

* USB boot is really slow. Probably an issue with the firmware running on the PIC.
* I'm not certain, but it looks like the PIC cannot hard reset the FPGA in order to load a new firmware. Easy to fix by adding wire jumpers (they were thoughtful enough to bring out 2 unused PIC GPIOs in addition to the PIC programming pins) but a production board should not need any fixes!

I can't think of any good reason to use the USB boot facility! It's ponderously slow, Adept works fine, and there's an on-board configuration PROM.

I'm not completely sure how it works (also, the schematic doesn't match the board at all) but you're right - it doesn't look like the PIC controls the FPGA's LOAD (or JTAG, which would also work). I think it just acts as an SPI master, though from a quick look it's not clear how it disables the PROM.

[NiHaoMike]

I plan to have a custom firmware running on the PIC that interfaces to an Android tablet, so that the tablet can send a (precompiled) firmware image to the FPGA for a given app or mode of operation. (The Kelly Wu board, which is capable of connecting to Android over USB, also uses a PIC24F so there shouldn't be too many issues with porting the code.)

[joelby]

That sounds a little convoluted - have you considered using MultiBoot? You can program a number of bitfiles into the 128 Mbit PROM. Without compression, the XC6SLX45 bitstream size is 11875232 bits, so you could fit about ten different designs.

You can trigger reprogramming using ICAP, and this could be driven by a command from the USB host PIC (along with the index of the design you want to reload to).

If you really want to store bitstreams on the tablet, and the tablet can act as a USB host, you might be better off using the Adept port, since the Cypress microcontroller is connected to JTAG, and there's an open source loader for Linux.

[NiHaoMike]

Look up ADK, IOIO, and microbridge. They all use a microcontroller to connect to an Android tablet over USB, even if the tablet doesn't support USB host. The Kelly Wu board actually runs a PIC port of microbridge. The tablet would load the firmware onto the FPGA, then communicate with it in order to run the given app.

The idea is to not require a board reflash in order to use a new app. In the future, I might design a low cost board just for use as an Android accessory, with a much lower end FPGA, a lower end PIC, and little more than the bare essentials to make it work. $200 or more is not going to make a very popular Android accessory, but a $40-50 board would be very reasonable. It would then be about the same price as IOIO and Arduino ADK, but also offer the benefits of FPGAs.

[joelby]

As a starting point, have a look at the Silicon on Inspiration boards. They're very simple and cheap, have low-end Spartan-6 parts, and are occasionally on special for about $10 less.

[NiHaoMike]

I just started developing the firmware for what is now known as the AndroidFPGA project, and I discovered yet more shortcomings.
* The PIC pins used to program the FPGA (DIN, CLK) do not support hardware SPI. The programming is done by bit banging, hence the unreasonably slow speed. Fortunately, it does not happen often, but it does mean a longer startup time for an app. The ones connected to the DONE and MODE pins do support hardware SPI, where it cannot do any good.
* The fact that the PIC cannot hard reset the FPGA means that proper implementation of the FPGA firmware loading process is impossible on a 100% stock board. Most likely I will end up modifying the board, but that will greatly limit the potential userbase. The modifications needed are very simple and easily reversible, but not something recommended for a beginner.

Most likely I will end up designing a dedicated board just for AndroidFPGA earlier than expected, although that's still a long ways off.

[joelby]

Can you use the Cypress microcontroller for this application instead of the PIC? It's connected directly to the JTAG interface and also has more data lines going to the FPGA. You can reconfigure the FPGA in only a couple of seconds. As a bonus, you also get many more data lines to the FPGA, which you can use for user applications.

The FPGALink project has some open source replacement firmware for it.

[NiHaoMike]

I want it to be compatible with tablets without USB host support and it should also charge the tablet as it's being used. I'll keep that in mind for using the board with a PC, though.

[NiHaoMike]

And the flaws keep coming. I was curious just how slow was the stock firmware, so I scoped it. It was about 800kHz, but more importantly, the signal termination unintentionally creates an attenuator that degrades the signal quality. That might be why they ran it at such a low speed even though it's easy to bit bang much faster than that. Easy to fix, but a good board should not need any fixes.

[joelby]

Honestly, I don't think anyone is actually using the USB firmware upload method

Where were you scoping the SPI? To examine signal integrity, you should do it at or as close to the FPGA pin as possible, but with a quick glance at my board, I'm not sure where you'd do that unless you scraped some of the solder mask off the appropriate via under the FPGA. Otherwise you could just try cranking up the speed and see if it still works reliably.

Maybe they were limited by their USB code rather than (or in addition to) the SPI bus? Unfortunately I don't think Digilent have released the PIC's firmware so it's difficult to examine it, but as a data point, some of the HDL I've seen written by them is a little shonky!

[NiHaoMike]

I was scoping it at R308. (It would actually be best to scope it at R229, but then the power switch would be hard to reach.) R308 along with R229 and R238 cause nearly 5dB of signal attenuation. I plan to replace R229 and R238 with a RC snubber just big enough to eliminate the ringing while introducing the least attenuation. (I currently have those resistors removed, which introduces too much ringing when the FPGA is driving the bus.)

[joelby]

Ah yes, for SCK, probing at the PIC end should be correct.

Termination with 100R or 200R is pretty standard on most commercial Xilinx boards, so I wouldn't worry about it until you've tried to drive SPI at a higher speed and run into problems! There's no point modifying the board if it's working well, and unless you're completely sure that you're not seeing a measurement effect.

[NiHaoMike]

The series 100R at the PIC along with two 100R to ground and 3V3 (50R impedance) cause a very significant signal attenuation even at DC. In fact, I'm surprised it worked at all.

The termination at the Flash chip is now 51R in series with 100p to ground. No ringing when the FPGA is driving the bus and no noticeable attenuation when the PIC is driving the bus. I also populated the PIC programming header and added two jumpers for the PROGRAM and INIT signals. Now I just need to write the PIC firmware (or rather, port the "Kelly Wu" microbridge firmware to it and add the FPGA programming code) and I should have a FPGA connected to an Android tablet.

[joelby]

Good one! I'm keen to hear how it goes!