ARM + FPGA ...

[debugasm]

... but not Zynq or Cyclone, only separate chips.

Hi friends, I nedd of some help with new pcb hardware for me. I have to interface a quite powerful ARM processor to an FPGA (Spartan 6) with a speed of at least 250 Mbit/s (32 MB/s) definitely obtained with DMA (I imagine).

I can not and I do not want to use Zynq or Cyclone (with integrated ARM) because these are too expensive and complicated.

I have select this device to connect together:

ATSAMA5D35

Spartan-6 XC6SLX75

From what I understand the only bus that can be used for this purpose is "External Bus Interface (EBI)" or "Static Memory Controller (SMC)" but which one is best suited to my purpose ?

My FPGA (Spartan-6) has interconnected peripherals built using EDK without Microblaze (replaced by external ARM) this internally uses an AXI bus. How to physically connect this ARM to the internal AXI bus so you can use peripherals on FPGA ?

Does anyone know a VHDL/Verilog interface to be implemented on FPGA to build a "bridge" between EBI/SMC and "AXI Master Bus" (with burst capability) ?

After all this, a small example of a linux driver to use the devices ...   ...

Can someone help me ? Does anyone have experience on this type of interface ?

Thanks for any help.

debugasm

[sarah90]

Not an answer, but an idea: there are some pretty cheap cyclone dev-boards like the de10-nano that contain chips that are more than twice or thrice the price of the dev board itself. You could base your design around such a board.

[debugasm]

Thanks for replay.

I have already Zybo, ZedBoard, MicroZed, ZC702. I do not have Altera but it's similar.

I have to build inexpensive hardware, leave hard work on the FPGA (as small as possible) and use a relatively powerful ARM for calculation / management.

 

[solutions]

What are you trying to do?

[debugasm]

I have to build something like that :



I have to receive two transport streams from two satellites (or the same one), taking 16 MP2 / AAC audio streams, decoding them and sending them to 16 I2S transmitters.

FPGA would do the raw work of extraction and transmission, ARM would do the work of decoding and management.

Any FPGA with an ARM on board (Zynq or Cyclone) would be ideal, I am well aware of this and it was the initial idea, but for cost issues I have to split the two parts with two separate chips.

All this does not seem to be too complicated but I am stalled on the part of EBI <-> AXI Master, this was the basic idea but maybe there is some other technique.

A few flashes of genius ?

Thanks very much.

debugasm

[fpgaguy]

I would skip the EBI unless you have free IP targeted to your fpga

Instead use a small more integrated SoC + Phy
(2 serial, USB, Sata, PCIe, and dual 10/100/1000 eth, nand, spi, I2C, I2S, and some I/O gpio)

My favorite one is Kirkwood (marvell 6281), this is 32 bit ARM - then bring this out as PCIe to the FPGA
Use SPI as a boot device for low pin count
Use x16 pair of DDR2's



you can get a free PCIe endpoint and example code for your spartan6 from xilinx
the other peripherals you have, of course, you will need to code in RTL


Since your I2S is streamed from the SAT  - I would probably code that up in the spartan - but there should be something on opencores to get you started

I've gone away from spartan now to Artix - which is a bit more modern in resources - and also would not be bad choice

[solutions]

Moving stuff between chips seems like nothing but excess baggage and creates latency.

I'm thinking it's just as simple and low cost to do all of this with 16 ARMs, no FPGA.

[debugasm]

Thanks fpgaguy for your suggestions.

I would skip the EBI unless you have free IP targeted to your fpga

I was looking for something already done but I can not find anything about it.

My favorite one is Kirkwood (marvell 6281), this is 32 bit ARM - then bring this out as PCIe to the FPGA
Use SPI as a boot device for low pin count
Use x16 pair of DDR2's

At first sight it is a very interesting SoC. I have searched for documentation (datasheet, manual, etc.) but without success for this device. Marvell always makes "precious" its own documentation, unfortunately. I can not even find a shred of price.

you can get a free PCIe endpoint and example code for your spartan6 from xilinx
the other peripherals you have, of course, you will need to code in RTL

I've never used PCIe, it would be the first time. I took a look and the documentation and examples should be sufficient. The rest of the FPGA structure is not a problem.

Since your I2S is streamed from the SAT  - I would probably code that up in the spartan - but there should be something on opencores to get you started.

This part is already done, only the ARM <-> FPGA interface is missing.

I've gone away from spartan now to Artix - which is a bit more modern in resources - and also would not be bad choice

I would have to go to Artix / Spartan7 too but I have a lot of code written for ISE / EDK that I should convert to Vivado and I still do not have time to do it.

I keep looking for some documentation, if you have something to add I thank you in advance.

Moving stuff between chips seems like nothing but excess baggage and creates latency.

I'm thinking it's just as simple and low cost to do all of this with 16 ARMs, no FPGA.

The question is spontaneous: how import Transport Stream from Satellite input to ARM processor ?

debugasm

[h0nk]

Hello debugasm,

> The question is spontaneous: how import Transport Stream from Satellite input to ARM processor ?

I would assume that even a fast ARM could not handle this.

I know nothing about DVB-S2 but for DVB-S there are specialized chips (e.g. STV0297, STV0299).

From the Description of a "Programmable Transport Interface":

The input interface may select between either a LinkIC stream or an IEEE 1394 controller as the
source for the transport stream. Data packets from the input interface are input into a FIFO while
the PID is checked to see if it is currently selected for processing or is to be discarded. A selected
packet is parsed by the module to determine its type and to extract data from it. If the packet is
encrypted using the DVB or DES Standards the correct key is written into the DVB or DES decryp-
tion core in the transport module and the packet is decrypted.
...
DVB standard sections are filtered by a set from 32 possible 8-byte filters to look for a match.
Matching sections are then transferred to memory buffers for processing by software.


The input data from the tuner is normally 8 bit wide and the controller has to hunt for 8 bytes of data.
This may work for a single PID.

The clockrate (27 MHz) is controlled by a PLL/VXCO and aligned to the stream.


Best Regards

P.S.: For DVB-S2 look for the STV0903 data sheet. (I dont have it.)

[debugasm]

I would assume that even a fast ARM could not handle this.

I do not agree, an ARM is certainly able to manage them using the DMA. See the receivers that use linux and have an ARM.

I know nothing about DVB-S2 but for DVB-S there are specialized chips (e.g. STV0297, STV0299).

From the Description of a "Programmable Transport Interface":

The input interface may select between either a LinkIC stream or an IEEE 1394 controller as the
source for the transport stream. Data packets from the input interface are input into a FIFO while
the PID is checked to see if it is currently selected for processing or is to be discarded. A selected
packet is parsed by the module to determine its type and to extract data from it. If the packet is
encrypted using the DVB or DES Standards the correct key is written into the DVB or DES decryp-
tion core in the transport module and the packet is decrypted.
...
DVB standard sections are filtered by a set from 32 possible 8-byte filters to look for a match.
Matching sections are then transferred to memory buffers for processing by software.

The input data from the tuner is normally 8 bit wide and the controller has to hunt for 8 bytes of data.
This may work for a single PID.

The clockrate (27 MHz) is controlled by a PLL/VXCO and aligned to the stream.

On this thing I am quite experienced and it is not a problem. I miss it, because never made it, to interface an FPGA to an ARM with good speed.

P.S.: For DVB-S2 look for the STV0903 data sheet.

I have this and many others.

I only ask if anyone ever made / saw something like that and maybe has experience.