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.
Continue reading “Connecting MCU and FPGA at 100Mbit/s Using Ethernet RMII [Part 2]”
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!
Continue reading “Connecting MCU and FPGA at 100Mbit/s Using Ethernet RMII [Part 1]”
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 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.
Execute as root:
chmod o-rw /var/run/dbus/system_bus_socket
However, the workaround fix may interfere with system software, hence look out for potential side effects.
![Connecting MCU and FPGA at 100Mbit/s Using Ethernet RMII [Part 1]](https://www.jsykora.info/wp-content/uploads/2016/01/zed_plus_adapter_labeled-1.png)
