Zed on Wired && Coded;

Connecting MCU and FPGA at 100Mbit/s Using Ethernet RMII [Part 2]

Sat, 23 Jan 2016 00:00:00 +0000

This is Part 2 of a two-part series on Ethernet RMII. In Part 1 I described my hardware setup and basic Ethernet operation. In the second and final part I will describe the design of specialized MAC cores I implemented on FPGA, and there will be measurements to see how much throughput and latency the system can achieve.

Connecting MCU and FPGA at 100Mbit/s Using Ethernet RMII [Part 1]

Tue, 19 Jan 2016 00:00:00 +0000

This is Part 1 of the two-part series on Ethernet RMII. Part 2 is also available.

Imagine your application requires a non-standard periphery controlled by an embedded processor. What options do you have? The periphery can be implemented in an FPGA; depending on periphery complexity you can choose an optimal FPGA that fits your budget. Where the processor goes? There are three possibilities: (a) inside FPGA as a soft-core → it will increase the cost of FPGA (larger type needed) and complicate HDL and software design. Or (b) inside FPGA as a hard-core → a nice compact solution and quite possible with heterogeneous FPGA from Xilinx (Zynq) and Altera (SoC). But the cost of these modern devices could still be too high for price sensitive applications. You must fit both your software and HDL to pre-engineered combinations of FPGA and ARM CPU sizes (perhaps a small Cortex-M core would suffice but you must pay for a gigahertz-class Cortex A cores).

The third option (c) is using a stand-alone MCU (maybe even not an ARM) and a standard FPGA. How do you connect them? You are limited to interfaces offered by the MCU. In modern low-end MCUs (by that I mean smaller STM32Fxxx devices) you have I2C (400 kbit/s), UART (115 kbit/s), SPI (~10Mbit/s), Fast Ethernet (100 Mbit/s). So what about the Ethernet core in the MCU? Could it be used to interface with FPGA? Sure it can!

ZedBoard: Late Xmas present has arrived!

Fri, 17 Jan 2014 00:00:00 +0000

Finally, after much waiting, my ZedBoard arrived on Tuesday. See it shining in the picture above, isn’t it lovely?

So far I managed only to unbox it and turn it on… Hence only a few notes on the beginnings:

Running Vivado 2013.3 in Fedora Linux: see my previous post.
Running the demo Linux bitstream from the supplied SD card: you need to reconfigure switches, at least JP8, JP9 should be at 3V3 side. Best to see the README on the SD card. The default configuration (JP7-11 at GND) is for JTAG download.
Installing USB-JTAG cable drivers in Linux: surprisingly, all I needed to do was to run Vivado/2013.3/data/xicom/cable_drivers/lin64/digilent/digilent.adept.runtime_2.14.3-x86_64/install.sh as root.
Missing impact tool in Vivado 2013.3: impact is deprecated. Use Hardware Manager / Open Target tabs in Vivado GUI.

Xilinx Vivado 2013.3 on Fedora 18: Working around a D-Bus bug

Sun, 10 Nov 2013 00:00:00 +0000

Running Xilinx Vivado 2013.3 (webpack license) on Fedora 18 may fail with the following error message:

$ vivado

****** Vivado v2013.3 (64-bit)
  **** SW Build 329390 on Wed Oct 16 18:26:55 MDT 2013
  **** IP Build 192953 on Wed Oct 16 08:44:02 MDT 2013
    ** Copyright 1986-1999, 2001-2013 Xilinx, Inc. All Rights Reserved.

INFO: [Common 17-78] Attempting to get a license: Implementation
process 17688: arguments to dbus_move_error() were incorrect, assertion "(dest) == NULL || !dbus_error_is_set ((dest))" failed in file dbus-errors.c line 282.
This is normally a bug in some application using the D-Bus library.
  D-Bus not built with -rdynamic so unable to print a backtrace
Abnormal program termination (6)
Please check '/home/jara/hdl/hs_err_pid17688.log' for details

The workaround is to make the D-Bus communication socket file /var/run/dbus/system_bus_socket unavailable when the Xilinx tools run.