The Godfather talking
This is god damn my place! Capisci?
Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
December 18, 2018, 05:51:29 17:51


Login with username, password and session length


Pages: [1]
Print
Author Topic: ARM + FPGA ...  (Read 1387 times)
0 Members and 1 Guest are viewing this topic.
debugasm
Junior Member
**
Offline Offline

Posts: 68

Thank You
-Given: 35
-Receive: 238


« on: August 16, 2018, 01:47:35 01:47 »

... 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 ...  Roll Eyes ...

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

Thanks for any help.

debugasm
« Last Edit: August 16, 2018, 01:49:52 01:49 by debugasm » Logged
sarah90
Active Member
***
Offline Offline

Posts: 112

Thank You
-Given: 7
-Receive: 11



« Reply #1 on: August 16, 2018, 09:28:14 09:28 »

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.
Logged
debugasm
Junior Member
**
Offline Offline

Posts: 68

Thank You
-Given: 35
-Receive: 238


« Reply #2 on: August 16, 2018, 10:14:40 10:14 »

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.

 Roll Eyes
Logged
solutions
Hero Member
*****
Offline Offline

Posts: 1779

Thank You
-Given: 618
-Receive: 876



« Reply #3 on: August 16, 2018, 11:09:01 11:09 »

What are you trying to do?
Logged
debugasm
Junior Member
**
Offline Offline

Posts: 68

Thank You
-Given: 35
-Receive: 238


« Reply #4 on: August 17, 2018, 02:38:00 02:38 »

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
Logged
fpgaguy
Active Member
***
Offline Offline

Posts: 115

Thank You
-Given: 115
-Receive: 114


« Reply #5 on: August 17, 2018, 03:43:04 15:43 »

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

Logged
solutions
Hero Member
*****
Offline Offline

Posts: 1779

Thank You
-Given: 618
-Receive: 876



« Reply #6 on: August 18, 2018, 03:16:51 03:16 »

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.
Logged
debugasm
Junior Member
**
Offline Offline

Posts: 68

Thank You
-Given: 35
-Receive: 238


« Reply #7 on: August 18, 2018, 03:30:43 03:30 »

Thanks fpgaguy for your suggestions.

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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
Logged
h0nk
Active Member
***
Offline Offline

Posts: 158

Thank You
-Given: 128
-Receive: 106



« Reply #8 on: August 18, 2018, 10:07:19 10:07 »

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.)
« Last Edit: August 18, 2018, 10:26:55 10:26 by h0nk » Logged
debugasm
Junior Member
**
Offline Offline

Posts: 68

Thank You
-Given: 35
-Receive: 238


« Reply #9 on: August 19, 2018, 03:21:37 03:21 »

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.

Quote
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.

Quote
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.
Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC