RoadTest: USB104 A7: Artix-7 FPGA Development Board
Author: Fred27
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: If the PC104 form factor isn't important to you then there are plenty of other Artix-7 board available. If it is, then this is a unique product.
What were the biggest problems encountered?: Inability to get the sample code for the Zmod peripherals to run. (These peripherals are not part of this road test.)
Detailed Review:
This isn't my first Xilinx FPGA board roadtest. I seem to be making a habit of them! I'm going to stick to the same process I usually follow when doing these roadtests. I'll describe the board and how it might fit in to your toolbox. Then I'll work through some of the sample code provided by the manufacturer. I find that there can be a lot you need to hit the ground running with a new FPGA board. The example projects and IP that are supplied can be crucial. The version(s) of Vivado / Vitis used can also be particularly important as it isn't always simple to upgrade projects.
So first, let's take a walk around the board...
The USB104 A7 is designed around a Xilinx Artix-7 FPGA. This is not the beefiest of the Xilinx FPGA range, but not quite down there with the cost-optimised Spartan 7 range. The Artix range focuses a little more on the performance-per-watt and also includes high speed GTP transceivers compared to the Spartan family. Xilinx also have the Kintex-7 and Virtex-7 ranges if you want a little more FPGA and have a higher budget.
The onboard XC7A100T device is at the upper end of the Artix-7 range which start down at the 12T (with 12,800 logic cells) and goes all the way up to the 200T with (215,360 cells). The 100T has 101,400 logic cells and also 15.850 slices, 126,800 flip-flops, about 1Mb of distributed RAM, 4.8Mb Block RAM. The full spec sheet for the range is as follows, with this particular device highlighted. Not that in this package, the Artix's GTP transceivers are not available for use.
Another thing worth noting is that the included FPGA is an industrial temperature device - perhaps hinting at the device's purpose as industrial I/O rather than as a development board.
Most Element14 readers will be very familiar with the Raspberry Pi's 40-pin header. You'd also be likely to recognize that slightly wonky Arduino header format from the other side of the room. Would you believe that these two well known formats were far more recent that the PC/104? The PC/104 format has been around in one variation or another for 28 years! That meant that back in the day you were likely to see a PC/104 host board with something like an Intel 80386 running Windows 3.1. We may have come a long way, but PC/104 is still around.
The physical PC/104 form factor relates to the dimensions - 96mm x 90mm (or 3.775" x 3.550") and the location of the mounting holes to stack the boards on top of each other. In this respect the USB104 A7 fits the standard just fine. Digilent even include appropriate metal standoffs to stack your board - creating a tower much like that depicted on the right. By default these mounting holes are covered by rubber feet so the board does sit nicely on a developer's desk until you decide to put it in its final mounting place.
Strictly speaking, the USB104 A7 doesn't follow enough of the form factor to meet any of the PC/104 variants. They all require a PC-based connector - somewhere from ISA up to PCIe. These variations are also shown in the same image of stacked boards. Considering the Artix-7 can support PCIe over those GTP Transceivers, I was a little surprised to see that only USB connectivity was supported. I suppose that USB will meet many of their customer's needs and be far simpler to implement. I experimented with PCIe connectivity to an Artix-7 on an old cryptominer board and I must admit I found the PC side of things difficult.
The primary connectivity provided to interface to a PC/104 microprocessor board that might find itself in your stack. I suppose these days it might be a microcontroller rather than a microprocessor providing the core processing power and as long as it supports being a USB host then we can connect it to the USB104 A7. The board contains a single USB type B socket which can be used for both communicating with the FPGA and also programming it via the onboard JTAG circuitry. Digilent provide sample projects for USB communication, which we'll delve into when we look at the software later.
The board also includes a rather newer connectivity option - the Zmod / SYZYGY interface which I explorer in my earlier road test for the Eclypse Z7: Zynq-7000 SoC Development Board - Review. This is a high speed connector - intended to be cheaper and simpler than a large mezzanine connector. So far i believe it's only been adopted by Digilent for FPGA devices - on this and the aforementioned Eclypse Z7. However, SYZYGY not just a physical connector. The SYZYGY ecosystem also requires the carrier and peripheral boards to communicate over I2C to negotiate voltage and power levels before it is enabled. Digilent's own Zmod system adds some further layers on top of this.
As I have a couple of Digilent Zmod boards from the previous roadtest I will be looking at how well supported these are on the USB104 A7.
There are also the usual array of further features. This included 3 Pmod interfaces, 2 push buttons and 4 LEDs. There are debug headers for both the PMU IC and the ATmega 328 that's used to handle the SYZYGY interface but it seems unlikely that the end user would need to mess with these.
Power is supplied by a very similar wall wart as supplied with the Eclypse Z7. I'm in the UK so once again has the issue that I can't use his without a UK to EU (or US) adapter making it even bulkier. There's also the problem that the 12V supply for the Eclypse Z7 is very similar to the 5V supply for the USB104 A7 - including the barrel jack. You can only tell the difference by reading the small text on the devices. There is a risk that I might mix the two up and destroy my A7. Obviously this would be my fault, but it would be nice if this wasn't quite so easy to do.
So, you have some form of processor in your PC/104 stack and you now have a shiny new Xilinx FPGA. There's not much point if you can't communicate between them, is there? Luckily one of the example Digilent provide is their USB104 DSPI Demo. I've always found that Digilent provide good documentation and support for their products and it seems the USB104 A7 is no exception. This page give you links to a Vivado project for you hardware design, a Vitis project for your MicroBlaze-based software and also a C project (Windows only) to demonstrate the PC side of the communication. I'll run through this from the top down.
The C demo app that Digilent provide appears to be Windows only. This wasn't a problem for me, but I thought I'd mention it in case any readers are in the Linux-only camp. The Adept libraries on which it relies are cross-platform so I suspect it wouldn't be a huge leap to port this to Linux if you're happy writing C and can call a few libraries. I didn't try though. The C code is well presented and documented. and the instructions for getting up and running are good. I was a bit surprised that I had to install Digilent's Adept software (and reboot) before it would work, but considering that the Adept libraries that are used for communication to the FPGA that's reasonable. The build of the C source code failed on my machine - simply because I didn't have gcc installed. As there was a prebuilt executable included I didn't go to the trouble of installing gcc just to build from source. I'm sure it would have worked.
Looking through the code it's clear and understandable. It does use prebuilt Digilent DLLs under the hood for communication. These libraries are closed source and seem fairly old - supporting devices back to the Coolrunner II CPLDs and I found copyright messages in the header files going back over a decade. I suspect this code speaks directly to the USB104 A7's onboard Digilent JTAG adapter. Looking through the well-documented sample code it appear to set up SPI communication at 125kHz. This, and the fact that the code is peppered with 1ms delays makes me think it's not designed for high speed data transfer.
To be honest, well documented stable code is probably what you need rather than high throughput. I suspect that the most common customer use case would be to hand off some critical processing to the FPGA and only be concerned with the data from this process. Here you can see some snippets of the code to initialise the DSPI layer and to write data to the "registers" defined on the FPGA side.
The Vitis project contained no surprises. It appears to use Xilinx's standard xspi drivers so the code is fairly standard looking stuff. I can see that it initialises SPI_0 and configures it as an SPI slave device. It's standard and simple - and I mean that as a compliment. If you want to get started form sample code that it's good when it feels familiar and easy to work with. Here you can see the debug output from Vitis (over a debug serial port) for the same communication.
Similarly, the Vivado project was nothing unexpected. It simply contains a block design for a MicroBlaze and its associated memory, rests and AXI bus. It should look familiar to anyone who has created a MicroBlaze soft processor on a Xilinx FPGA. There are also some GPIO set up for the LEDs and buttons, and some Xilinx IP for the AXI Quad SPI device. Once again, this is exactly what you need if you want to start creating your own design.
All in all, I'm impressed with the DSPI sample. It's simple and simplicity is a good thing. You want a nice simple working design to help you get started and it's good that it's been created with a fairly recent version of Vivado. The sample code is setup for Vivado/Vitis 2020.1. Vivado 2020.2 has come out only very recently and I'm sure porting this code up one minor version would not cause any major issues.
The only surprise I've had so far is that there's been no attempt to make use of the Artix's excellent high speed communication. This would have meant a very different board. PC/104 supports PCIe and so does the Artix 7. Using this could have unlocked far more performance, However, it would have been at quite a cost. The physical design of the board would have been more complicated. In my experience, the software side of things would have been too. As I mentioned earlier when discussing the hardware I've tried to use PCIe to communicate with an Artix 7 and I found it to be both difficult and limited to specific Linux versions. All-in-all I think I agree that USB was a better choice.
In addition to the PC/104 form factor, one of the stand-out features of this board is the SYZYGY / Zmod connector. I was lucky enough to road test the Eclypse Z7 which came with two of Digilent's own Zmod peripherals - one ADC and one DAC board. It would probably help to give a bit of background on this, in particular why it seems to have two names.
Syzygy is an open standard for high speed peripheral connectivity created by Opal Kelly. It claims to fill the middle ground between the low-speed Pmod style connectors and the large, expensive and unwieldy high-speed mezzanine connectors. Having looked quite thoroughly into Syzygy (including designing my own peripheral board) I can say that I think they've done a fairly good job. It claims to be a vendor agnostic solution but to be honest I haven't seen any products by anyone but Opal Kelly themselves and Digilent (2 FPGA board and 2 peripherals). Syzygy is more that just a specification for the connector pinout. It also specifies the physical mounting for the board and how a carrier and peripheral communicate over I2C to negotiate things like power delivery and IO voltage levels. Designing my own board turned out to be a little bit more work than I anticipated, but I suppose considering how it's intended to be used that's not too surprising.
Zmod is a Digilent-specific standard built on top of Syzygy. Digilent provide base Zmod libraries and and libraries specific to a certain Zmod peripheral. These libraries are provided for either baremetal or Linux. Zmod is essentially a software abstraction layer over their platform.
As I've mentioned, Digilent are pretty good at providing well documented and up to date support for their hardware. I was pleasantly surprised to see the DSPI sample code was for Vivado/ Vitis 2020.1. However, the Zmod samples for the USB104 A7 are provided for Vivado 2019.1 - not quite as recent but still reasonably good. There was a significant change between 2019.1 and 2019.2 when the Xilinx SDK (for the software side of things) was changed to Vitis. Whilst both still work in the same way, the way that hardware is handed off from Vivado to Vitis changed. Luckily I've been playing with Xilinx FPGAs for long enough to have multiple version of Vivado installed and using 2019.1 wasn't a problem.
Once again, the samples provided were good. There's a nice block design in Vivado including the required MicroBlaze soft processor and Zmod IP. Xilinx SDK is essentially the software IDE to write C code for your custom Microblaze (or Zynq) processor. Once again a sample project was provided and this included the pre-generated bitstream that describes this custom hardware.
Unfortunately, on the Xilinx SDK side things didn't quite go as smoothly as I expected. I initially steamed in with "I know what I'm doing with Xilinx SDK" and despite opening the project it didn't want to run. So I went back and very carefully followed the detailed instructions without skipping bits. No. Still not working. Everything looked fine until I tried to run the project. The hardware handover seemed fine. (I even regenerated it just to make sure.) The bitstream was loaded. The C++ application compiled and loaded. However, the code didn't want to start at the main function. It appeared to start at some function in the Zmod library. Continuing from here just stepped through some disassembled code. The same happened with both the ADC and DAC samples. I just couldn't get anywhere. I spend quite a while looking for the problem - fully expecting it to be something daft I'd done. I posted on the Digilent forum, to no avail.
Luckily after posting 14rhb gave it a try and managed to get it to work. It turns out that you need to regenerate the bitstream and export the hardware as you might do with the usual Vivado/SDK workflow. I thought I'd tried this already and the instruction specifically tell you not to do this, but it seems that the bitstream/hardware definition in the sample SKD project is not correct. very odd how you end up with similar strange behaviour in both the ADC and DAC projects.
Anyway, once you do this, the Zmod can be controlled from the windows command line using DPSI in much the same way as the basic DSPI example. Here's a video of the process in action for the Zmod DAC. This is much easier to demonstrate that the ADC but they work in a similar way.
I'm still working on my own custom Syzygy board. Initial test show that it will happily negotiate I/O voltage levels with the USB104 A7. Once I've made a bit more progress, I'll be sure to test it with this board and I'll see if we can add HDMI output.
Creating a SYZYGY board - assembling the board and testing
Apart from the problems I has with the Zmod sample code, I can say that once again Digilent have produced a nice well-supported board. Code is provided which covers the most likely use case of the board - communicating with another device in you PC/104 stack over USB. There's a nice selection of expansion options. The Pmod connectors cover simple low speed IO and the Zmod is ideal for anything faster. I can't imagine a mezzanine connector would be a practical option for a board already intended to be stuck in a stack. Software support is there for reasonably recent versions of Vivado / Vitis. In my experience this is normally not the case for most FPGA boards.
I've given the board a reasonably high score expect in 2 areas. I can't honestly say that it's good value when other Artix-7 board are much cheaper. However I can imagine that any situations where you want PC/104 for industrial use the likely customer won't be particularly price-sensitive. I've also marked down on the quality of the demo software. I did manage to get the Zmod demo working but only by ignoring the instruction and handling hardware handoff in the "usual" way. Considering the problems occurred due as a result of making sure that I followed the instructions to the letter, it seems likely that I wouldn't be the only person to fall into this trap.
Obviously there are a few alternatives if you're just after an Artix-7. There's the tiny Cmod A7Cmod A7 or the Arduino format Arty A7kArty A7k. There's the training focused Basys 3Basys 3 or Nexys A7Nexys A7. All of these are significantly cheaper than the USB104 A7, so if you're just playing around then these may be a better choice for you. Things like the physical form factor and the industrial grade FPGA hint that this is a board you'd use to expand the IO and performance of an existing PC/104 based embedded control system. If that's what you're doing - or if for any reason you want PC/104 - then it's a no-brainer. No other FPGA board will fit the bill. Similarly, if you need an FPGA (rather than a Zynq SoC) with a Zmod interface then your list of options also boils down to just one.
Once again, the guys who write the taglines for Digilent's packaging have beat me to it. I should learn from this and just start my road test by quoting them! On the box it says "Add Artix-7 power to your PC/104 stack". That pretty much sums it up. If you are working with on a PC/104 system and need the power of an FPGA then this is the device for you.
Top Comments
One thing to note is that the connectivity via USB is just a FIFO provided by the FTDI device with limited bandwidth. Adding USB3 would have made this board much more palatable for high speed HIL projects…
I look forward to reading yours too. It's good when there are a few road testers that the road tests head in slightly different directions and cover different aspects of the same product.
Good, comprehensive review.
-
dimiterk
-
Cancel
-
Up
+3
Down
-
-
Reply
-
More
-
Cancel
Comment-
dimiterk
-
Cancel
-
Up
+3
Down
-
-
Reply
-
More
-
Cancel
Children