Deep Embedded Processor Board

[rickman]

The thread on spinning a 386 in an FPGA made me think about the FPGA
boards available. I know you can find boards that are inexpensive and
you can find FPGA boards that have support for processor oriented
devices like RAM, Flash, Ethernet, etc. But is there any overlap
between these requirements?

I figured it should be practical to produce a board with SDRAM, a NAND
Flash chip and the minimum interface needed for a few interfaces,
Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can
envision could be prototyped in the FPGA and communicate with the real
world.

Does this board exist?

--

Rick

 

[Theo Markettos]

rickman <gnuarm@gmail.com> wrote:

I figured it should be practical to produce a board with SDRAM, a NAND
Flash chip and the minimum interface needed for a few interfaces,
Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can
envision could be prototyped in the FPGA and communicate with the real
world.

This is something I'm doing at the moment. We do have a (somewhat
heavyweight) processor which is constrained by its I/O.

Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined by
cache-coherent bridges. On the ARM side are various hard peripherals (micro
SD, 1G ethernet, USB, DDR3). It's possible to configure the bridges so that
the FPGA can look over the wall at the ARM-side peripherals, and so the FPGA
can map ARM-side peripherals into its own Avalon/AXI memory space.

This is more efficient than external chips, because there are not many
external chips for driving these kinds of embedded interfaces (most
separate-package USB/SD/SATA controllers would speak PCIe, which isn't what
you want)

However, once you have that setup you probably want to run the driver stack
on ARM Linux (drivers for things like USB being a pain, see our previous
conversation) and provide a more abstract interface to the FPGA - for
example a simple block device rather than dealing with the Synopsys USB
controller and USB mass storage. Then you can get away with a much more
minimal software overhead on the FPGA.

The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the FPGA
isn't very big:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=167&No=941

On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated, so
you can access the peripherals from either side. But there's no cheap Arria
10 as yet. There are also no Stratix IV/V parts with ARMs on them.

I don't know if Zynq can do something similar - anyone have more experience
with Xilinx-land?

Theo

 

[Allan Herriman]

On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote:

rickman <gnuarm@gmail.com> wrote:
I figured it should be practical to produce a board with SDRAM, a NAND
Flash chip and the minimum interface needed for a few interfaces,
Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can
envision could be prototyped in the FPGA and communicate with the real
world.

This is something I'm doing at the moment. We do have a (somewhat
heavyweight) processor which is constrained by its I/O.

Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined
by cache-coherent bridges. On the ARM side are various hard peripherals
(micro SD, 1G ethernet, USB, DDR3). It's possible to configure the
bridges so that the FPGA can look over the wall at the ARM-side
peripherals, and so the FPGA can map ARM-side peripherals into its own
Avalon/AXI memory space.

This is more efficient than external chips, because there are not many
external chips for driving these kinds of embedded interfaces (most
separate-package USB/SD/SATA controllers would speak PCIe, which isn't
what you want)

However, once you have that setup you probably want to run the driver
stack on ARM Linux (drivers for things like USB being a pain, see our
previous conversation) and provide a more abstract interface to the FPGA
- for example a simple block device rather than dealing with the
Synopsys USB controller and USB mass storage. Then you can get away
with a much more minimal software overhead on the FPGA.

The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the
FPGA isn't very big:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?
Language=English&CategoryNo=167&No=941

On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated,
so you can access the peripherals from either side. But there's no
cheap Arria 10 as yet. There are also no Stratix IV/V parts with ARMs
on them.

I don't know if Zynq can do something similar - anyone have more
experience with Xilinx-land?

Here's one in a familiar form factor at about the same price:
<http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/te0726-zynq.html>

It has some odd design decisions though - the Ethernet goes through
a USB to Ethernet adapter, rather than using the native controller.
(I guess one can take the "Pi-compatibility" thing too seriously.)

Regards,
Allan

 

[rickman]

On 4/25/2016 6:27 PM, Allan Herriman wrote:

On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote:

rickman <gnuarm@gmail.com> wrote:
I figured it should be practical to produce a board with SDRAM, a NAND
Flash chip and the minimum interface needed for a few interfaces,
Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can
envision could be prototyped in the FPGA and communicate with the real
world.

This is something I'm doing at the moment. We do have a (somewhat
heavyweight) processor which is constrained by its I/O.

Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined
by cache-coherent bridges. On the ARM side are various hard peripherals
(micro SD, 1G ethernet, USB, DDR3). It's possible to configure the
bridges so that the FPGA can look over the wall at the ARM-side
peripherals, and so the FPGA can map ARM-side peripherals into its own
Avalon/AXI memory space.

This is more efficient than external chips, because there are not many
external chips for driving these kinds of embedded interfaces (most
separate-package USB/SD/SATA controllers would speak PCIe, which isn't
what you want)

However, once you have that setup you probably want to run the driver
stack on ARM Linux (drivers for things like USB being a pain, see our
previous conversation) and provide a more abstract interface to the FPGA
- for example a simple block device rather than dealing with the
Synopsys USB controller and USB mass storage. Then you can get away
with a much more minimal software overhead on the FPGA.

The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the
FPGA isn't very big:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?
Language=English&CategoryNo=167&No=941

On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated,
so you can access the peripherals from either side. But there's no
cheap Arria 10 as yet. There are also no Stratix IV/V parts with ARMs
on them.

I don't know if Zynq can do something similar - anyone have more
experience with Xilinx-land?

Here's one in a familiar form factor at about the same price:
http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/te0726-zynq.html

It has some odd design decisions though - the Ethernet goes through
a USB to Ethernet adapter, rather than using the native controller.
(I guess one can take the "Pi-compatibility" thing too seriously.)

Interesting board. That is an odd decision though. Won't the kernel
need to be recompiled for this compared to the rPi? So why worry with
making the Ethernet driver compatible?

--

Rick C

 

[Allan Herriman]

On Mon, 25 Apr 2016 21:18:18 -0400, rickman wrote:

On 4/25/2016 6:27 PM, Allan Herriman wrote:
On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote:

rickman <gnuarm@gmail.com> wrote:
I figured it should be practical to produce a board with SDRAM, a
NAND
Flash chip and the minimum interface needed for a few interfaces,
Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can
envision could be prototyped in the FPGA and communicate with the
real
world.

This is something I'm doing at the moment. We do have a (somewhat
heavyweight) processor which is constrained by its I/O.

Altera's Cyclone V SoC parts have an ARM side and an FPGA side, joined
by cache-coherent bridges. On the ARM side are various hard
peripherals
(micro SD, 1G ethernet, USB, DDR3). It's possible to configure the
bridges so that the FPGA can look over the wall at the ARM-side
peripherals, and so the FPGA can map ARM-side peripherals into its own
Avalon/AXI memory space.

This is more efficient than external chips, because there are not many
external chips for driving these kinds of embedded interfaces (most
separate-package USB/SD/SATA controllers would speak PCIe, which isn't
what you want)

However, once you have that setup you probably want to run the driver
stack on ARM Linux (drivers for things like USB being a pain, see our
previous conversation) and provide a more abstract interface to the
FPGA
- for example a simple block device rather than dealing with the
Synopsys USB controller and USB mass storage. Then you can get away
with a much more minimal software overhead on the FPGA.

The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the
FPGA isn't very big:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?
Language=English&CategoryNo=167&No=941

On the Arria 10 (and Stratix 10) the ARM and FPGA are more integrated,
so you can access the peripherals from either side. But there's no
cheap Arria 10 as yet. There are also no Stratix IV/V parts with ARMs
on them.

I don't know if Zynq can do something similar - anyone have more
experience with Xilinx-land?

Here's one in a familiar form factor at about the same price:
http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/
te0726-zynq.html

It has some odd design decisions though - the Ethernet goes through
a USB to Ethernet adapter, rather than using the native controller.
(I guess one can take the "Pi-compatibility" thing too seriously.)

Interesting board. That is an odd decision though. Won't the kernel
need to be recompiled for this compared to the rPi? So why worry with
making the Ethernet driver compatible?

I was joking about the Pi compatibility. I don't expect that this board
would be running a distro like Raspbian.

It's hard to know the designer's intent. For all I know, he chose to
forgo the native Gb Ethernet interface because there wasn't enough room
for a PHY (and its power supply), although looking at the block diagram,
it seems more likely that he wanted to reserve the pins for GPIOs (I
assume the 53 MIO pins are shared between the bootflash, USB, UART, SDCard
and the GPIO).

Regards,
Allan

 

[Allan Herriman]

On Tue, 26 Apr 2016 10:57:34 +0000, Allan Herriman wrote:

On Mon, 25 Apr 2016 21:18:18 -0400, rickman wrote:

On 4/25/2016 6:27 PM, Allan Herriman wrote:
On Mon, 25 Apr 2016 19:14:22 +0100, Theo Markettos wrote:

rickman <gnuarm@gmail.com> wrote:
I figured it should be practical to produce a board with SDRAM, a
NAND
Flash chip and the minimum interface needed for a few interfaces,
Ethernet, USB 3.0, HDMI and maybe SATA so that any processor you can
envision could be prototyped in the FPGA and communicate with the
real
world.

This is something I'm doing at the moment. We do have a (somewhat
heavyweight) processor which is constrained by its I/O.

Altera's Cyclone V SoC parts have an ARM side and an FPGA side,
joined by cache-coherent bridges. On the ARM side are various hard
peripherals
(micro SD, 1G ethernet, USB, DDR3). It's possible to configure the
bridges so that the FPGA can look over the wall at the ARM-side
peripherals, and so the FPGA can map ARM-side peripherals into its
own Avalon/AXI memory space.

This is more efficient than external chips, because there are not
many external chips for driving these kinds of embedded interfaces
(most separate-package USB/SD/SATA controllers would speak PCIe,
which isn't what you want)

However, once you have that setup you probably want to run the driver
stack on ARM Linux (drivers for things like USB being a pain, see our
previous conversation) and provide a more abstract interface to the
FPGA
- for example a simple block device rather than dealing with the
Synopsys USB controller and USB mass storage. Then you can get away
with a much more minimal software overhead on the FPGA.

The cheapest Cyclone V SoC board, the DE0-Nano-SoC is $99, though the
FPGA isn't very big:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?
Language=English&CategoryNo=167&No=941

On the Arria 10 (and Stratix 10) the ARM and FPGA are more
integrated,
so you can access the peripherals from either side. But there's no
cheap Arria 10 as yet. There are also no Stratix IV/V parts with
ARMs on them.

I don't know if Zynq can do something similar - anyone have more
experience with Xilinx-land?

Here's one in a familiar form factor at about the same price:
http://www.trenz-electronic.de/products/fpga-boards/trenz-electronic/
te0726-zynq.html

It has some odd design decisions though - the Ethernet goes through a
USB to Ethernet adapter, rather than using the native controller. (I
guess one can take the "Pi-compatibility" thing too seriously.)

Interesting board. That is an odd decision though. Won't the kernel
need to be recompiled for this compared to the rPi? So why worry with
making the Ethernet driver compatible?

I was joking about the Pi compatibility. I don't expect that this board
would be running a distro like Raspbian.

It's hard to know the designer's intent. For all I know, he chose to
forgo the native Gb Ethernet interface because there wasn't enough room
for a PHY (and its power supply), although looking at the block diagram,
it seems more likely that he wanted to reserve the pins for GPIOs (I
assume the 53 MIO pins are shared between the bootflash, USB, UART,
SDCard and the GPIO).

I should have looked at the schematic instead of the block diagram. The
GPIOs are connected to Bank 34 (on the PL, not the PS), and the 53 MIO
pins on the PS are used for I2C, USB, SDCard, QSPI (bootflash) and some
GPIO connected to a MACHX02 CPLD.
It seems the designer simply ran out of MIO pins and wasn't able to fit
in Ethernet (although this could have been run through the EMIO to PL
pins).

On Zynq designs of mine, I've managed to fit in USB, bootflash, SDCard,
Ethernet, UARTs, I2C and some GPIO on the MIO, and a second Ethernet port
via EMIO and PL pins.

Regards,
Allan