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?: Cyclone IV "chinese" brands, Gadget Factory Papilio Pro, Saanlima Pipistrello
What were the biggest problems encountered?: Lack of Serial-USB.
This is a review of Terasic DE0-Nano FPGA board. This board is built around an Intel (former Altera) Cyclone IV FPGA, with some extra on-board devices, power supply and GPIO pins.
This roadtest/review is based on a custom port of a full System-on-a-Chip, ZPUino, which I develop and maintain.
The objective was to test all board devices and most FPGA features, however due to lack of time a few items were not tested or exercised. They are still accessible from within the software, if you wish to play with them.
All outputs from the port, including FPGA design, CPU code, IDE, supporting software, PCB schematics and design for the custom board, as well as other artifacts are released and made public using open-source licenses.
The board arrived well-packed, with a few leaflets and an USB cable. A clear acrylic top can be seen, held by a few metallic standoffs and bolts. The board is very compact, with two double-row headers on top, standard spacing, and another double-row header on the bottom. A mini-USB connector can also be seen, as well as a few ICs, switches, LEDs and pushbuttons.
Before starting, and after going through the board schematics, it became almost evident that the USB connector could only be used to power the board and program the FPGA itself – no other connectivity with the FPGA would be possible, like raw USB or USB-serial. This would present a problem, since most ZPUino programming is done via a serial link, usually encapsulated over USB. I then decided to design a bespoke board with an USB-to-serial adaptor, and also use this board to reorganize the GPIOs in such a way that I could use some “shield” boards I own which are made with a different pinout. While this board was being designed and manufactured I used an external adaptor (FTDI-based) connected to the GPIO headers to provide the required serial link.
The initial ZPUino port was based on a previous port I made for a similar (Altera) board, but tuned for de0-nano specifics, such as pin layouts and clocks.
Everything was performed using Debian Linux. I already had Altera Quartus installed, but I recall it was easy to install at the time.
The board comes with a few devices which are accessible from within the FPGA.
Although the serial flash (a Spansion device, but reports as an EPCS) is often only used to store the FPGA design, ZPUino requires also some space to store its programming and extra data. The serial flash pins were routed to the FPGA after powerup so it could be used form within the SoC (and including reprogramming the FPGA design itself without using Altera Quartus programmer).
There’s one accelerometer present on the board, connected via an I2C bus. This device was used for the first demonstration
One eeprom is connected to the I2C bus, shared with the accelerometer. This device was not tested during this roadtest due to lack of time (and purpose)
Eight LED are present and connected directly to the FPGA. One 8-output/16-bit PWM controller was used to modulate the LED outputs, which can be seen on the first demonstration.
Four switches and two buttons are soldered on the board, but they are hard to use when the acrylic top is attached. The switches were used to select the accelerometer axis for the first demo. The buttons were not used for this roadtest.
The board packs a 32Mbyte SDRAM from ISSI. The SDRAM was connected via the ZPUino SDRAM controller to the SoC, and used as main memory for the SoC and for some DMA devices.
The ADC has not been exercised.
ZPUino is a 32-bit System-on-a-Chip with a ZPU 32-bit core and a bunch of IO devices. It runs on several FPGA boards, from several board and FPGA vendors. All of ZPUino is released under open-source licenses. It can be programmed using the Arduino IDE, thus easing migration from traditional CPUs to FPGA-based CPUs (also known as soft-CPUs).
ZPUino also features PPS (Peripheral Pin Select) for a few of its devices – this means you can route the inputs/outputs of a specific IO device (such as SPI) to any GPIO pin from within the software running on ZPUino. Neat!
Also featured is a read-only filesystem that can be placed on the serial flash, and accessed using regular POSIX semantics. This allows for usage of common UNIX libraries, such as libpng and libjpeg. Just place your files on a directory and they will be programmed along with your sketch.
Although ZPUino is a generic platform intended for any FPGA, a few particular, device-specific components had to be mapped using Quartus. This ended up being very simple and intuitive.
For the main PLL we required two clock outputs – one 96Mhz for the main CPU and the devices, and a 48MHz for the RGB controller. This was accomplished by using the ALTPLL “macro”.
The SDRAM controller requires a DDR flip-flop to generate the SDRAM clock, which cannot be easily inferred (if at all) This was accomplished by using the ALTDDIO_OUT “macro” from within Quartus.
Port did not go without some hassles – I got the SDRAM clock polarity wrong the first time, and although I was able to test all of the SDRAM positions individually, it simply did not work for the fast, full-speed bursts that the ZPUino instruction cache uses to read the program being executed. This led me to use an interesting feature – the SignalTap II Logic Analyser. Although I have used it the “hard” way, it does look quite simple to use by anyone (if you follow the rules – sometimes you cannot find the signals you require due to optimizations).
Only one “variant” of the ZPUino was ported for the DE0-Nano. This variant includes:
The first port had SDRAM issues, so I used the internal FPGA RAM instead (a total of 32KB were allocated to the CPU memory).
For this first test I used the accelerometer data to control the LED outputs, using a software-decay controller so that they would fade nicely. All of the axis were reported correctly to the software, and the LED were also correctly lit.
Check out the video at the end of the review to see the accelerometer and LED in action.
The main driver for this board was in fact the lack of USB-serial on the de0-nano. This was my first attempt at manual soldering of a QFN package using an hot-air gun (a Silicon Labs CP2104, QFN-24). First attempt was not successful, but second one did look OK and works very well so far. The USB-serial is able to handle up to 2Mbaud, which is more than enough for this demo.
Since I was at it, most GPIO0 and GPIO1 signals were routed in the “papilio” format, and I added a HUB-75 connector for an RGB panel, although I could have lived without it (and I had a few soldering issues with this connector, all fixed now).
You can see the board on the photos, along with the DE0-Nano board.
To avoid shorting the through-hole connections from the custom board, I replaced the de0-nano metallic standoffs with plastic ones and removed the acrylic top.
For long I have been using cheap RGB panels (HUB75 interface) connected to FPGAs. For this demo I used a previously-closed RGB controller I designed, which I am releasing under open-source. This controller can connect to more than one panel line, thus maxing at about 4x4 (16) panels.
Configured display size: 128x32 (96x32 visible, 3072 LED)
Depth: 7-bit (per channel, 21-bit per pixel), indirect PWM modulation
Panel clock speed: 24Mhz
Theoretical bandwidth: 144Mbit/s
Refresh rate: ~90Hz
The RGB controller may look a little bit “odd” to many HDL implementers, in the sense it does not have a framebuffer of its own, but rather fetches the display data directly from SDRAM (which is shared with CPU), and then feeds it to a “line” FIFO which in turn is used to stream data to the panels. This saves a few important resources on the FPGA, still maintaining the required display speed.
Since I was playing with the RGB panel, I used the extra I2C channel to connect a Wii Nunchuck using an adaptor I already owned. Picked up some software I had previously developed, and put a game to work. You guess which game it is:
You can watch it live in the video at the end of the review.
I confess I’d love to test/impleme more stuff, which could be relevant for more advanced users, but time is at short. Those were:
Although I do have an HDMI “shield/wing”, and despite I routed all signals differentially from the board to the relevant headers, the HDMI core requires some manufacturer-specific primitives called SERDES, which I had only used for Xilinx. It also would require a dynamically-reconfigurable PLL, which I looked at but had no time to implement/integrate.
Although a “kid’s” scope, it would be interesting to test the channel isolation from the ADC, as well as the bandwidth
I have a few DSP stuff I could use, like a software-configurable 64-tap filter. No time.
I have not made use of the SigmaDelta output. It can be easily used for stereo audio, with remarkable quality, just requiring a simple low-pass filter.
The not so good:
No roadtest or review is complete without a proper video. Here is is:
ZPUino Sketch, custom PCB design and other files (still being updated): https://github.com/alvieboy/de0-nano-sketch
[Edit] Minor typo corrected
The internal I2C bus, which has the Accelerometer and the EEPROM is not externally accessible. That forced me to add two I2C controllers to ZPUino, one connected to the internal bus, and the second one to the GPIO headers. If I had access to the internal I2C bus I'd just connect the Wii Chuck there, avoiding a second HDL controller.
Take a look here: https://github.com/alvieboy/ZPUino-HDL/blob/de0-nano/zpu/hdl/zpuino/boards/terasic/de0-nano/de0_nano_top.vhd , lines 851/852 and 885/886, where you can see the two (double) I2C bus buffers, one for each I2C instance.
Nice review, but I am confused.
You claimed the I2C bus was internal only, but earlier you said it had an external I2C bus to the output pin array.
What was your issue?
I can understand having the internal I2C set up and terminated to take advantage of the on board sensors, but the external I2C should allow you to add sensors as needed.