1. Where can I buy an XLR8 board?

2. What FPGA is used on the XLR8 and Snō boards?

It’s an Intel MAX10.

3. What chip is used for the USB to serial interface?

It’s an FT230XQ FTDI chip.

4. Will AloriumTech support users who want to create their own XBs (Xcelerator Blocks) for XLR8?

The short answer is Yes. The long answer is, well, longer… Out of the gate, AloriumTech’s primary goal was to create an FPGA-based board that is a drop-in replacement for the Arduino Uno, meaning that it is the same footprint, runs the same sketches, uses the same libraries, and is programmed with the standard Arduino IDE. The XLR8 board comes pre-loaded with a few different XBs, and supports FPGA image updates via the USB port, which enables users to upload images with new XBs supplied by AloriumTech. There is also a JTAG footprint on the board (which will not be populated on the production boards), so that more advanced FPGA users can use a JTAG programmer (the Intel USB Blaster, specifically) to talk to the FPGA directly. Initially, AloriumTech will provide limited support for users who want to create their own XBs and interface to the on-chip microcontroller. Down the road, we do plan to provide access to enough source code and documentation to make it possible for someone proficient with Verilog or VHDL, and with Quartus, to create their own XBs.

6. Is there special software required to program an XLR8?

7. How do you tell XLR8 or Snō to use its floating point hardware instead of using lots of clunky Arduino instructions?

In order to access their floating point hardware, we provide a library that you include in your sketch, but there are some changes required to the floating point arithmetic operations in your sketch, as well. Our library defines functions that directly access the general purpose registers within the processor core, such that the hardware-based floating point operations can be performed extremely fast. Any floating point operation that you want to accelerate in your sketch (or in any libraries you’re using) needs to be converted into the XLR8-specific function call. For example:

c = a + b;

becomes

c = xlr8FloatAdd(a,b);

Because I’m a lazy typist, I typically do this:

#define xA xlr8FloatAdd

so the line of code I end up with looks like:

c = xA(a,b);

There are similar functions for subtract, multiply, and divide, too. We debated a few different approaches for this, and landed on this one for the time being.

8. Which MAX10 device does XLR8 use? What about larger (or smaller) devices as additional offerings?

XLR8 uses a 10M08 device. The smaller MAX10s don’t have enough flash to properly emulate the 328p microcontroller. Larger MAX10 devices could be used, and we may consider those for future boards based on user demand for a larger FPGA.

9. How much space is available on the FPGA for XBs?

The microcontroller uses about half of the available space on the 10M08 MAX10, so about half is available for XBs.

10. Is the microcontroller cycle accurate with a standard ATmega microcontroller?

Yes, based on all of our testing to-date, our implementation of the ATmega-compatible microcontroller is cycle accurate with the standard ATmega micro. If we (or someone else) finds a case where that isn’t true, we are treating that as a bug.

11. Does AloriumTech have plans to develop a dual core or hyperthreaded version of the board?

We don’t have specific plans for that. Right now, our focus is predictable, easy-to-use performance enhancements to the standard ATmega by providing intelligently-designed hardware acceleration that users can access within a well-known development environment. Of course, we are still building our roadmap for future enhancements, so please keep the ideas coming!

12. Will AloriumTech also sell the bare FPGA for users who want to build their own board around it?

That’s something that is on our roadmap. Keep in mind that the MAX10 we use is a 0.8mm pitch BGA, so there are definitely some skills required to put it down on a board! But, for those of you with the skills (and the equipment), check back with us soon to learn more about what else we have planned!

13. Is it possible to use a toolchain other than the Arduino IDE with XLR8?

C/C++ programs can be directly compiled with avr-gcc, makefiles, etc., and uploaded using avrdude over the USB/UART interface. It’s not a path that we use every day, but we do it occasionally. It’s a great way to avoid some of the overhead of Arduino’s built in libraries. Programming the chip via the ICSP header instead of through USB/UART is not in our short term plans. It would take us some verilog design work to enable that path, but it could be done if there’s enough demand for that capability. Since we only have the USB/UART path for program upload, the Arduino optiboot bootloader is currently hardcoded into the design. It’s a pretty good bootloader, taking just 256 locations (512bytes) from the instruction memory. The ATmega’s “fuses” don’t really exist in our design, and the options they control are set to the Arduino defaults.

14. Is it possible to run the CPU faster than the standard ATmega runs?

Yes, it should be. Timing analysis of our implementation of the ATmega core shows that it should run at more than double the standard Arduino Uno clock speed. We plan to provide a path for users to access higher clock speeds in future FPGA image updates.

15. Does the implementation of the AVR core have the same memory available as the standard ATmega328 part?

The user will see the same program/flash and data/sram memory space as the ATmega328 (32Kbytes and 2Kbytes respectively). Beyond that there is some extra sram on the FPGA that the XBs can use, but that the AVR doesn’t directly see. We don’t have any on-chip EEPROM memory, but the production board design has a spot where an external EEPROM could be added.

16. Will XLR8 and Snō include support for non-AVR cores in the future?

The Arduino ecosystem supports a number of different processor architectures. Because the AVR core seems to be the most prevalent core, and specifically because of its limitations, we wanted to offer an upgrade path to help Arduino users with a large base of AVR code to dramatically improve performance. Down the road, user demand will help us decide on additional upgrades for XLR8 and Snō.

17. Does XLR8 have the same analog I/O capabilities as the Arduino Uno?

XLR8 has built-in ADC functionality just like the Uno, but a few of the specifics are different. We don’t have the option for an internal bandgap reference, nor do we have the ATmega’s analog compare function. On the plus side, XLR8 will give correct ADC results regardless of whether it’s powered from USB or from the barrel connector, unlike an Arduino board which, when powered from USB, will give incorrect ADC readings due to a reduced 5v supply. Additionally, the MAX10 ADC is higher performing in both speed (1MHz) and resolution (12 bit) than the ATmega ADC, so look for future enhancements to XLR8 that will make these additional capabilities readily available to users!

18. Is SPI supported on the same pins as on the Uno and the ICSP pins?

Yes it is. There is one note regarding SPI on XLR8 that is worth pointing out from Section 3.9 of the XLR8 User Manual:

3.9 SPI

The SPI interface on XLR8 should operate the same as the SPI interface on an Uno or Redboard. The only item to note is that we’ve seen some SPI examples where the XLR8/Uno/Redboard is the SPI slave and instead of being driven from the SPI master, the SS pin is left floating. XLR8, due to its I/O pullups, needs to have SS driven and not floating.