Digilent Atlys Resources

The Digilent Atlys is a pretty good board! It has a nice, high speed VHDCI connector, gigabit Ethernet, HDMI, and DDR2 memory. Unfortunately it suffers from a manual with some glaring errors (including a misspelling of 'FPGA'), an Ethernet chip with an impossible-to-obtain datasheet, and a reference design that was created using the SDK. For those of us using ISE, read on!

Ethernet

I wanted to use the Gigabit Ethernet interface to send data (ideally in UDP packets) to a host computer at high speed. Most HDL experts say that this should be possible without using a microcontroller. They're right, but it's a big pain for several reasons.

Xilinx supplies a triple-speed Ethernet MAC core, TEMAC, but it requires a license, and if you had the money for one of those you could be using a Microblaze soft core and thus Digilent's reference implementation. Opencores.org has a gigabit MAC but I couldn't make much sense of it, which I find is pretty typical of my experience with the site.

Turning to a physically realised design that uses Gigabit, I delved into the USRP2 software defined radio's HDL and firmware. It uses a different chip, but contains a working GPL licensed gigabit-only MAC and MDIO interface. After many hours of studying this in an attempt to figure out how it works, pulling apart the Digilent reference design to figure out which registers I needed to set on the PHY, and then writing a state machine-based driver for the Wishbone bus, I came up with a working implementation, which I present to you here:

Atlys Gigabit Ethernet Version 1 (20110228) - fails when packets are large.
Atlys Gigabit Ethernet Version 1 (20110404) - does everything great!

License is GPLv2, but parts written for the USRP2 are currently not attributed properly

It generates a hard-coded UDP packet (the size of the payload is controlled by the SPST switches) without checksums when the 'reset' button is pressed and works pretty well. The PHY is re-initialised when BTNU is pressed. Receiving is not implemented in the top-level test application (though it is included in the MAC implementation and I have no reason to think it wouldn't work). If you generate packets larger than 1500 bytes, you will need to increase your NIC's MTU (9000 should do it). Otherwise, large packets *will* mysteriously disappear.

Caveats

Note that there may be some clock domain crossing issues involving resets in this example that I haven't had a chance to fix. These don't affect operation.

Unfortunately the state machine approach is quite annoying and cumbersome, even for just sending a single packet. I would therefore like to design a similar aemb based soft core controller along with a tutorial on how to actually go about using aemb (once I figure it out myself), since one is sorely lacking. I may never bother with this, since I've lost all interest in using aemb for now.

I use a PLL to generate 90 and 270 degree clocks for the ODDR that drives the TX clock at 125 MHz. This is poor design - it's safe to use the ODDR's built-in clock inverter (and by some accounts much better). It should also be possible to avoid the extra PLL trickery and just clock TX at 180 degrees out of phase from the GMII signals. The 90 degree phase is just a leftover from when I was troubleshooting the design.

If you change the IP header (MAC and IP addresses), you will need to calculate a new header checksum, or your PC will drop the packets (and they won't be visible to Wireshark etc.).

These issues will be fixed at some point in the distant future when I feel inspired, but let me know if you need any help in the meantime.

Memory interface

I have written some extensive notes on using the MIG with the Atlys.

VHDCI connector

When building a board-to-board interface using the VHDCI connector, your options for male connectors are:

Use Samtech part VHDCP-68-01-M-EM. Requires a 0.8mm PCB. Body of the connector doesn't physically attach to the PCB, so you have to be very careful about disconnecting it in order to not stress your PCB traces. When used with the Atlys, differential pairs end up being split between the top and bottom layers, which feels a bit dirty but seems okay when I've tried it at 200 MHz.
Use All Best electronics part R-HI-008068-2, which is presumably what Digilent use on their mating boards. Digilent now sell this connector for $8.99 (and seem to have discontinued the female connector). It is not stocked by any of the major distributors, but can be bought from the manufacturer; however it is very expensive in low quantities due to a $100 handling charge and an unspecified shipping charge.

The final option is to use a female VHDCI connector (which are much more common than the male) and a VHDCI cable. Digilent sell these, and they're fairly common on eBay. I don't really like the idea of long, thick cables connecting to my tiny, fragile interface board though!

HDMI

The reference manual states a few untruths about the HDMI interface. The Digilent test application uses an EDK-ed version of the XAPP495 code, and not the xps_tft core. XAPP495 does not provide an implementation of HDMI's EDID, so the dvi_demo may not work if you connect it to a source (such as some PC graphics cards) that require EDID. One solution is probably to set the jumpers for SCL/SDA pass-through, though that may only work with one input channel.

Note that HDMI input J1 is disabled by default unless you install JP5, which is connected to the TMDS141 chip's output enable. This is not documented anywhere!

If you're new to ISE, here are the steps you'll need to take to try out XAPP495:

Create a new project in ISE. Set the device to XC6SLX45-CSG324, speed grade -3.
Add all of the Verilog (.v) files in the XAPP495 distribution to the project.
Set either vtc_demo.v (colour bar generator) or dvi_demo.v (2x2 switch matrix) as the top module by right-clicking and selecting "Set as Top Module"
ISE won't like it if you add both of the UCF files, so either add dvi_demo.ucf or vtc_demo.ucf to the project, depending on the demo you want to try. You might want to create two projects - one for dvi_demo and one for vtc_demo.
Select the top module and Generate Programming File.

The vtc_demo should cause you no woe, but dvi_demo will probably require some reconfiguration of jumpers on the Atlys for it to work:

Add jumper JP5 to enable HDMI input on J1
Install jumpers JP6/JP7 to enable SDA/SCL pass through from J3.
Install jumpers on the anonymous header labelled SDA/SCL next to J1 (they're called JP2 on the schematic, though). On the boards I've seen and heard about, these were supplied from the factory with jumpers connected, but installed incorrectly, shorting SDA and SCL together on both sides rather than passing them through. Check the schematic diagram to see if this applies to you and then rotate them if necessary.

USB ports

Host

The manual and a close look at the board indicates that the USB host is controlled by a PIC24FJ192, while the schematic says it's a PIC32MX440F256H-40I/MR!

The PIC will load a bit file placed on a USB drive formatted with a FAT file system if jumper JP11 is closed. Note that it takes about 26 seconds for the load process to complete! LED7 will be stuck on while JP11 is closed, but the jumper can be removed once the FPGA has been initialised.

The PS/2 interface provided by the PIC uses open drain ports, so it's necessary to provide pull-up constraints:

Net "PS2DATA" LOC = N18 | IOSTANDARD = LVCMOS33 | PULLUP;
Net "PS2CLOCK" LOC = P18 | IOSTANDARD = LVCMOS33 | PULLUP;

Note that the manual may be wrong with regard to the pin associations - clock and data may be swapped. I have not confirmed this yet.

Device

The Atlys has a USB-serial device, which works fine, but for higher speeds consider using MakeStuff FPGALink. It is a library and firmware for the Cypress FX2LP USB controller (the "PROG" interface) that replaces Digilent Adept and provides an open source, cross platform bitstream upload facility and a high speed (25 MB/s) data transfer facility.

PicoBlaze

There's now a version of the PicoBlaze soft processor for the Spartan-6, but it didn't originally include the UART peripheral that came with the Spartan-3 core. I've fixed the UART so that it synthesises and runs on the Atlys and have written a small demo/framework design based on the old alarm clock demo. It's intended as a nice starting point for new designs that require PicoBlaze.

Spartan 6 PicoBlaze demo (20110513)

Note that a new version of KCPSM6 has since been released, complete with UART, so you should drop the new files into this demo until I get around to updating it.

AC'97 codec

Predictably, the manual again has some grievous errors. The references to the 1/8" audio ports (J15-J18) are wrong (should be J4-J8), as is the codec (IC19 should be IC3). The FPGA pin assignments given in the diagram on page 14 are correct (N16, L13, T18, U17, T17), but those in the table on page 15 are wrong. This was probably copied and pasted from another board's manual and not corrected.

Digilent's built-in self test application has plenty of code for decoding and encoding AC'97 frames (ac97_if), and comprehensive example MicroBlaze C code for initialising and playing with the codec (ac97_if_00.c).

Digilent have now released a MicroBlaze design demonstrating just AC'97.

Speed grade

It's impossible to tell because the Spartan-6 chip on the Atlys has a heatsink attached, but according to mrflibble, Digilent report that it's a -2. The BSB files that Digilent supply claims that it's a -3.