How to couple a FPGA and a MPU?

[technix]

The two pals I want to couple in question: AT91SAM9260 and EP4CE15E22C8N. The former is an ARM926EJ-S SoC that runs a Linux-based host system. The latter is a FPGA that I want it to do things with the processor. Questions:

* Can I hold the FPGA in reset until the ARM boots and loads the FPGA with its configuration?
* If so, can the FPGA configuration loading channel be used as a channel of communication between the FPGA and the SoC after the FPGA is loaded?
* What is the best communication channel - parallel system bus, or some kind of serial interface?
* For AT91SAM9260, how to DMA into and out of the FPGA given the communication channel?

Also is this a reasonable system spec?

* SoC subsystem: AT91SAM9260 ARM926EJ-S @180MHz, 128MB (32M x32) SDRAM, 512MB SLC NAND, microSD card slot, Wi-Fi over SDIO, BT over UART, 10/100 Ethernet, 800x480 LCD with capacitive touch over RA8875
* FPGA subsystem: EP4CE15E22C8N, 32MB DDR SDRAM (32M x8), some kind of host interface, shared pins to LCD, some other exported pins, hopefully no external configuration device needed

And finally, given the connections (FPGA have access to LCD interface,) can I program the system to shut down RA8875 LCD interface after the FPGA booted, and let it function as a soft GPU?

[nctnico]

I'd go for a solution which allows to use PCI express. That gets rid of a whole bunch of problems.

[nctnico]

I'd go for a solution which allows to use PCI express. That gets rid of a whole bunch of problems.

Seriously? The op is designing a very cost sensitive application otherwise he wouldn't use arm9 and previous gen fpga. Pcie only brings cost much higher.

That depends on whether you factor in engineering costs. Too many people start with cheap parts and then spend months to get these to do what they want while a different solution can be brought up in days and likely doesn't run into bandwidth limits as a bonus.

[nctnico]

PCIe is a (standard) free core for Xilinx devices. But again: it all depends on engineering costs. Sure you can make cheap parts do what you want as well but is it (financially) worth the extra effort? The Zync solution may not be a bad one either.

[mikeselectricstuff]

* Can I hold the FPGA in reset until the ARM boots and loads the FPGA with its configuration?

Yes. There isn't really such a thing as "Reset" on an FPGA.

* If so, can the FPGA configuration loading channel be used as a channel of communication between the FPGA and the SoC after the FPGA is loaded?

Possibly but probably may or may not be a very sensible way to do it. JTAG would be the most flexible way to do it, but FPGAs usually have slave serial modes- you'll need to check the data to see to what extent & which config pins can be used as normal I/Os after configuration - this will vary between manufacturers and probably between families.

* What is the best communication channel - parallel system bus, or some kind of serial interface?

Totally unanswerable question without more info - depends entirely on your application's needs  - speed, latency, pin count etc.
The beauty of an FPGA is you can implement whatever interface(s) you want.
SPI (including enhancements like QSPI, DDR QSPI,SDIO etc,.) is  very easy to implement and can offer tens of MBytes/sec transfers over a few wires.

* For AT91SAM9260, how to DMA into and out of the FPGA given the communication channel?

Read the AT91 documentation. DMA just gives faster access to the peripheral, so is a secondary consideration

Also is this a reasonable system spec?

* SoC subsystem: AT91SAM9260 ARM926EJ-S @180MHz, 128MB (32M x32) SDRAM, 512MB SLC NAND, microSD card slot, Wi-Fi over SDIO, BT over UART, 10/100 Ethernet, 800x480 LCD with capacitive touch over RA8875
* FPGA subsystem: EP4CE15E22C8N, 32MB DDR SDRAM (32M x8), some kind of host interface, shared pins to LCD, some other exported pins, hopefully no external configuration device needed

And finally, given the connections (FPGA have access to LCD interface,) can I program the system to shut down RA8875 LCD interface after the FPGA booted, and let it function as a soft GPU?

Again it depends entirely what you want to do.

[legacy]

- "I have no idea about what I am doing"
- "but I want to couple a complex fpga chip to a super complex SoC"
- because science


LOL

[technix]

PCIe is a (standard) free core for Xilinx devices. But again: it all depends on engineering costs. Sure you can make cheap parts do what you want as well but is it (financially) worth the extra effort? The Zync solution may not be a bad one either.

Both chips I mentioned above are not BGA.

If I want to use PCIe I would go straight for iMX6Q + Cyclone V, or go with straight AXI with Cyclone V SoC, all in BGA packages. Here I am restricting myself to QFP only, hence the older ARM9 and Cyclone IV, as well as no PCIe.

[technix]

I don't know the details of the AT91SAM9260 but from the product page I see:
 SD/eMMC 2
 DMA Channels 27
 Parallel Port EBI
 External Memory Bus Interface: Program/Data

So if I needed good inter-processor (well FPGA to processor) communications I would:
* See if I could have the FPGA be a SPI master and the CPU be a SPI slave.  Maybe not possible / beneficial?
* See if I could have the CPU be a SPI master and the FPGA be a SPI slave. ...
 * See if I can map at least an 8 or 16 bit wide data bus between the CPU and have the FPGA look like a SRAM or memory mapped I/O device to the CPU.  The "Extermal Memory Bus Interface" and "Parallel port: EBI" capabilities lead me to think that should be possible.  The FPGA would use either its block RAM or at least a FIFO or register file or a few registers to appear as a memory mapped address space to the CPU and also be accessible by the FPGA.  Ideally you'd have at least one memory peripheral / register / FIFO / RAM area / register file that the CPU controls the addressing of and is used for CPU initiated -> FPGA destination data.  Similarly if possible have the same but in the opposite direction so that an I/O register or FIFO or  memory range as seen by the CPU is written by the FPGA and the CPU listens to it as a "mailbox" for incoming data.

* If the CPU supports SDIO or 4-bit SD or Quad-SPI or similar SPI ports that can have a high enough bandwidth to be useful that may be a good low pin count way for the CPU to send data to the FPGAand receive data from it by the FPGA emulating such an interface.  Or otherwise if not 2-bit or 4-bit wide maybe the basic free SPI ports can run at XX MHz from both devices and that could still be fast enough for use?

* CPU side DMA channels usually can be mapped with various pre-defined DMA triggers which can be tied to external events / signals.  Sometimes dedicated DMA request pins can be configured as inputs to the CPU requesting DMA service for particular DMA channels.  Sometimes interrupt request lines into the CPU can be associated with particular DMA channels.  Sometimes just GPIO input pins can be made to DMA request flags that are level or edge triggered.  Anyway ideally you can set such a line on the FPGA and have that enable directly or by interrupt a DMA transfer from the FPGA's I/O mapped or memory mapped address space so you can efficiently send blocks of data from the FPGA to the CPU without so much polling by the CPU using either interrupts or DMA channels.
If the interface was SPI or SDIO or similar then it should also be possible to have a DMA trigger cause the CPU to read (or write) data via such peripherals on demand also.

* For the CPU to the FPGA direction the CPU will control interfaces like SPI where the CPU is master or DMA where the CPU is the initiator but these can be triggered / activated based on some kind of handshake / ready / interrupt / DMA process between the devices to the CPU knows when it can / cannot send data.  Similar for I/O and memory mapped I/O.

* Some CPUs even have DMA modes where the external device can become a DMA master / controller and the FPGA could initiate and control access for itself directly to the CPU memory and I/O space by driving both address, data, and control lines to the CPU DMA interface.  You will have to see if there is benefit in letting the FPGA access CPU resident memory and I/O devices with high bandwidth like that or whether the CPU should / must be involved cooperatively to transfer data.

* Don't forget a system level watch dog and reset and power rail sequencing issues.  Usually you can have a FPGA wait for a CPU port to load FPGA configuration data to the FPGA.  Most FPGA lines will be Hi-Z until the FPGA is configured though some may be dedicated inputs / outputs or whatever even during / before the FPGA is configured.  And of course when the CPU boots it will reconfigure its I/Os so be sure there will be no bus contention with connected outputs any time and apply pull up/down or bus holding registers if needed to allow levels to be defined for the CPU/FPGA as needed when one or both are in reset / being debugged / whatever.

In my system there is no spare SDIO available - the microSD card slot and the SDIO Wi-Fi adapter have occupied them. I would prefer hooking the FPGA to the main CPU using parallel EBI, especially if the same EBI can be used to both load the FPGA with configuration, as well as communicate between the SoC and FPGA.

[mikeselectricstuff]

In my system there is no spare SDIO available - the microSD card slot and the SDIO Wi-Fi adapter have occupied them.

You could pass the SDIO through the FPGA and have a select line to multiplex an internal interface with the external port, so you could do comms when not accessing the SDIO peripheral.
If the EBI can be muxed with general purpose IO, you could probably combine config and data interfacing, by configuring as GPIO to config the FPGA via SPI (hardware or bit-bashed), then switch to bus mode once the FPGA is configured/
 But if you have enough GPIOs (or a spare SPI port) to dedicate to FPGA config that will probably make your life easier.
It certainly used to be that FPGAs could be configged via a parallel MCU bus type interface - I don't know if this is still the case for more recent parts. If so, I would assume that most of the pins become general purpose after configuration and could be used as a bus interface. Read the configuration guide for your FPGA.   

[dgtl]

For the Cyclone 4 line, check out the configuration guide:
https://www.altera.com/en_US/pdfs/literature/hb/cyclone-iv/cyiv-51008.pdf
The FPGA can be configured (booted) in multiple different ways, either it is active part (loads the configuration itself) or passive (waits for data). In your case, you want the passive mode, either passive serial or passive parallel. For example, connect the passive serial mode to the SPI bus.
For communications, you can use whatever interface you want and implement the same in FPGA. For example, connect the FPGA to the parallel memory bus and give it a chip select. Then it is visible in the memory space to the CPU.
Beware of the issues in the older SAM9 parts. The DMA for SDIO and SPI can underrun and the software can't do anything about it. Starting from 9263, the SDIO implemented a configuration bit, that stalls the SDIO clock when no data is available. I've had too many headaches with SAM9261.

[technix]

In my system there is no spare SDIO available - the microSD card slot and the SDIO Wi-Fi adapter have occupied them.

You could pass the SDIO through the FPGA and have a select line to multiplex an internal interface with the external port, so you could do comms when not accessing the SDIO peripheral.
If the EBI can be muxed with general purpose IO, you could probably combine config and data interfacing, by configuring as GPIO to config the FPGA via SPI (hardware or bit-bashed), then switch to bus mode once the FPGA is configured/
 But if you have enough GPIOs (or a spare SPI port) to dedicate to FPGA config that will probably make your life easier.
It certainly used to be that FPGAs could be configged via a parallel MCU bus type interface - I don't know if this is still the case for more recent parts. If so, I would assume that most of the pins become general purpose after configuration and could be used as a bus interface. Read the configuration guide for your FPGA.

The EBI is not MUX'd with GPIO, instead it is shared by SDRAM, LCD interface and NAND through CS lines on EBI. The SPI signals are shared too with the touch screen controller and I can only find one extra CS line at most.

The FPGA supports passive parallel configuration mode though - can that be used in conjunction with EBI to load the configuration data? The parallel configuration pins are also used to make the FPGA talk to the SoC during normal operation on EBI using a SRAM-like interface. If the parallel loading would work I can just load the configuration file in the SoC straight into the FPGA using the parallel configuration pins, and the kernel would simply DMA the entire thing from NAND right into FPGA.

[tszaboo]

I've worked with boards, where the FPGA and the MCU was connected with the memory interface on the MCU. There was a memory slave controller in the FPGA, so the communication with it was basically reading/writing to the memory space. It was probably the most fluent way of solving this, because the FPGA acted very similarly to a peripheral of the MCU.

[legacy]

I'd go for a solution which allows to use PCI express. That gets rid of a whole bunch of problems.

Well not so sure if it really gets ride a whole bunch of problems, especially on the HDL side. Also the linux side is not a piece of cake when you have to deal with bad beast like PCI and ePCI.

Indeed, in our business stuff, every ePCI-project involves three guys
- a PCB expert guy
- a linux expert guy
- a fpga expert guy

[mikeselectricstuff]

I'd go for a solution which allows to use PCI express. That gets rid of a whole bunch of problems.

Well not so sure if it really gets ride a whole bunch of problems, especially on the HDL side. Also the linux side is not a piece of cake when you have to deal with bad beast like PCI and ePCI.

Indeed, in our business stuff, every ePCI-project involves three guys
- a PCB expert guy
- a linux expert guy
- a fpga expert guy

And what sort of expensive-ass scope are you going to need to debug PCIe ?

[technix]

For the Cyclone 4 line, check out the configuration guide:
https://www.altera.com/en_US/pdfs/literature/hb/cyclone-iv/cyiv-51008.pdf
The FPGA can be configured (booted) in multiple different ways, either it is active part (loads the configuration itself) or passive (waits for data). In your case, you want the passive mode, either passive serial or passive parallel. For example, connect the passive serial mode to the SPI bus.
For communications, you can use whatever interface you want and implement the same in FPGA. For example, connect the FPGA to the parallel memory bus and give it a chip select. Then it is visible in the memory space to the CPU.
Beware of the issues in the older SAM9 parts. The DMA for SDIO and SPI can underrun and the software can't do anything about it. Starting from 9263, the SDIO implemented a configuration bit, that stalls the SDIO clock when no data is available. I've had too many headaches with SAM9261.

I would prefer the FPP mode since the pins can be shared for normal EBI operation. I wonder if the problem is fixed in recent QFP SAM9260, and whether the Linux kernel contained a workaround or not.

[technix]

I'd go for a solution which allows to use PCI express. That gets rid of a whole bunch of problems.

Well not so sure if it really gets ride a whole bunch of problems, especially on the HDL side. Also the linux side is not a piece of cake when you have to deal with bad beast like PCI and ePCI.

Indeed, in our business stuff, every ePCI-project involves three guys
- a PCB expert guy
- a linux expert guy
- a fpga expert guy

And what sort of expensive-ass scope are you going to need to debug PCIe ?

I am definitely not touching any FPGA DIY PCIe stuff - just sending traces from a module to a M.2 slot is already scaring me. (The M.2 slot implementation itself is also scary, with the PCIe lane, USB Hub and USB to SATA adapter involved. The upstream chip is MT7688 which provides only one USB host port and the PCIe lane. I do intend to allow the M.2 slot accept PCIe WI-Fi card, NVMe SSD or SATA SSD.)

[legacy]

I am definitely .......... snip

Just a few weeks ago you wrote you were in troubles with a simple CPLD, now you have magically increased your skills so much that you are able to handle a GPU. LOL!

[technix]

I am definitely .......... snip

Just a few weeks ago you wrote you were in troubles with a simple CPLD, now you have magically increased your skills so much that you are able to handle a GPU. LOL!

I am learning, okay?

The trouble in both projects lies in the hooking up chips phase - once I make my way past that the HDL and software part can be much easier for me. Also this board serves as a experimenting kit for me with FPGA tightly interacting with the SoC.

[CM800]

I'd suggest buying yourself an FPGA or CPLD kit, then buy a microcontroller board (e.g. Arduino Due, STM32F7... something like that)

Then just use headers to pass comms through, I doubt you will be playing with anything high speed enough to be an issue over header cables.

Try single or even quad SPI, you should learn a lot playing with that alone.

[dgtl]

Beware of the issues in the older SAM9 parts. The DMA for SDIO and SPI can underrun and the software can't do anything about it. Starting from 9263, the SDIO implemented a configuration bit, that stalls the SDIO clock when no data is available. I've had too many headaches with SAM9261.

I wonder if the problem is fixed in recent QFP SAM9260, and whether the Linux kernel contained a workaround or not.

Afaik, not. Atmel seemed to fix things in newer chips and not re-spin old stuff. They did not do any workarounds in kernel drivers either (last checked ~5 years ago). Once I asked them at Embedded World, they said that 926x is too old and they focus their developments on supporting new stuff and not working around old hw bugs and too bad that I had things that did not work, I should respin the boards with newer ICs. As I had to get the problems patched with a lot of devices already sold, I had to do some crazy workarounds. The SDIO controller had some other issues as well, sometimes it got stuck and sometimes it did not handle the busy signal from SD card properly. I had to mux the SDIO pins to SPI and do all the SD card communication over SPI to finally get it stable enough to avoid data corruptions on SD cards. Then I did DMA SPI through SRAM to avoid underruns due to high SDRAM usage.
For the SPI, the linux driver used any gpio as cs via gpio framework (not the controllers cs output).
As the SPI driver in linux is already DMA-accelerated, it is much simpler to write peripheral driver that uses SPI. Otherwise, you would have to mess with memory-to-memory dma yourself. If the bandwidth is sufficient, start with SPI. In future projects you can move on to either parallel bus or PCIe or whatever is faster.
Trying things out with eval kits and jumper wires is a good advice. Later as everything is worked out, you can spin your own board. There are plenty of FPGA boards, find one with similar FPGA (it may be larger, you can downscale to smaller FPGA quite easily). Then get yourself a SAM9260 EVK and wire up the two.

[AndyC_772]

Downloading a Cyclone IV is really, really easy. Just:

- compile your design in Quartus, and enable generation of a raw binary (.rbf) file
- embed the .rbf in your source code
- pulse NCONFIG and check NSTATUS, as per the instructions in the Configuration Handbook
- download the binary using DCLK and D0. An SPI interface using DMA is the fastest way, but you can bit-bang too if you don't mind configuration taking a few hundred milliseconds
- pulse DCLK a couple more times and you're done.

Passing data between CPU and FPGA might be a bit more difficult; it really depends how much bandwidth you need, and what built-in peripherals your CPU has which can be pressed into service. Few processors have anything designed specifically as an "FPGA interface", but there's usually something you can hijack.

The simplest is probably SPI, which is fine for a few 10's of MHz, depending on the capability of the CPU.

For more bandwidth, you may need to program your FPGA to have an interface which emulates an Ethernet PHY (use MII or RMII as your link), or a QSPI Flash memory device, or perhaps a camera. Some processors have an external memory interface, which may be suitable.

PCI-e... not unless there's absolutely no alternative.

[nctnico]

PCIe is a (standard) free core for Xilinx devices. But again: it all depends on engineering costs. Sure you can make cheap parts do what you want as well but is it (financially) worth the extra effort? The Zync solution may not be a bad one either.

Both chips I mentioned above are not BGA.

If I want to use PCIe I would go straight for iMX6Q + Cyclone V, or go with straight AXI with Cyclone V SoC, all in BGA packages. Here I am restricting myself to QFP only, hence the older ARM9 and Cyclone IV, as well as no PCIe.

Aha, you didn't mention that before. Does the MPU you have selected a synchronous parallel memory bus? That would be an easy way to connect it to the FPGA. The biggest problem with connecting parallel memory busses to an FPGA is that you have no real clock available for the memory I/O and you need to re-sample the signals into the FPGA's clock domain. I'm not saying it can't done but it is a nuisance to get right.

[legacy]

The trouble

 

Dude the problem with you is

[legacy]

e.g.
what the fsck is the final application?
what the fsck are constrains and requirements?
what the fsck is written in the customer working table? (which means budget and deadline)


You are blathering a lot of bullshit as usual to waste people time.

[technix]

e.g.
what the fsck is the final application?
what the fsck are constrains and requirements?
what the fsck is written in the customer working table? (which means budget and deadline)


You are blathering a lot of bullshit as usual to waste people time.

There is no final application other than playing with things. I have a budget cap and an ability cap but no real constrain otherwise. And there is no customer in question.

I am still trying to learn stuff, and there is absolutely no fscking business involved. If you feel that this forum is for the business talk, if you don't appreciate exploring and experimenting and the general idea of playing with items, you should really keep clear of most of my threads. Yes I may lack a clear idea what items I am talking about is or how it works, but the big idea is to find out those questions through experimenting. I don't have the experience you have accumulated in your years - heck I don't even have a true EE background.

Admins, if you mostly agree with the idea that this forum is for business and business only, ban me.