Direct Memory Access (ARM -> FPGA/CPLD?) - Page 1
Forum section: electronics / general

author: CM800
author_rank: Frequent Contributor
timestamp: June 01, 2016, 08:16:12 pm
content: I'm interested in direct / ultra high speed access of data between ARM chips and FPGAs or CPLDs (more lightly)The idea is to have a high speed encoder interface or PWM system in a CPLD or FPGAand have it interfaced very directly with an ARM chip, to the effect of it pretty much being a peripheral.Is this or anything of the sort possible? and to what price range / how common is it?Do I need to look at specialist manufacturers or would standard chip companies make these? (TI, ATMEL, STM, Lattice, MicroSemi)

author: Scrts
author_rank: Frequent Contributor
timestamp: June 01, 2016, 09:37:32 pm
content: Quote from: TCWilliamson on June 01, 2016, 08:16:12 pmWe've used Atmel Cortex-A5 series external bus interface with Cyclone V. The interface basically worked like SRAM interface, which was easily interfaced to Alteras' Avalon-MM bus.

author: 6thimage
author_rank: Regular Contributor
timestamp: June 01, 2016, 09:48:49 pm
content: Have you considered using a SoC based FPGA - either a zynq from Xilinx or a cyclone V SoC from Altera? They have an FPGA fabric which connects to the processor through an AXI bus, allowing fast movement of data.

author: CM800
author_rank: Frequent Contributor
timestamp: June 01, 2016, 10:08:35 pm
content: Quote from: 6thimage on June 01, 2016, 09:48:49 pmI have but they are high end and very expensive, much more expensive then say a $9 ARM and a $5 CPLD or $15 FPGAAlso far higher end then needed too.

author: nctnico
author_rank: Super Contributor
timestamp: June 01, 2016, 10:11:18 pm
content: A very simple way is to use a MAC (ethernet interface). You can clock that from the FPGA and the microcontroller will deal with the clock domain crossing issues. Depending on the maximum clock spec you might be able to get much more bandwidth out of it than with ethernet.

author: CM800
author_rank: Frequent Contributor
timestamp: June 01, 2016, 10:22:26 pm
content: Quote from: nctnico on June 01, 2016, 10:11:18 pmThe thing is I want absolutely minimum processing done on the chip so I can price down the chip as low as possible.

author: Scrts
author_rank: Frequent Contributor
timestamp: June 02, 2016, 02:18:32 am
content: Ok, how much of bandwidth do you need? SPI is the cheapest option then.

author: chickenHeadKnob
author_rank: Super Contributor
timestamp: June 02, 2016, 05:29:44 am
content: Quote from: TCWilliamson on June 01, 2016, 10:22:26 pmEthernet Mac! even if you are only sending cut down datagrams sweet jesus , no, just no. He wants a simple device with a simple state machine on both sides of the interface. It doesn't get any simpler than a parallel interface. Most small cplds don't even have an ethernet MAC but they will have sufficient LUTs to do what he needs.Mr. Williamson check out these application notes from altera for basic ideas similar to what you want:https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an265.pdfhttps://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/an/an488.pdfYou don't need to use an altera device, lattice ice40, mach02 or Xilinx CPLDs can do this just as well. A parallel interface eats into the I/O pin count on both sides so most desgners will resort to an SPI interface for medium speed communication and conserve their IOs. If you want an external memory bus in a micro-controller you typically need to select the high pin count packages, and pay more. It isn't hard software wise and only a little bit slower to use the GPIO ports of a micro to effect the same interface.

author: westfw
author_rank: Super Contributor
timestamp: June 02, 2016, 06:36:15 am
content: Many Microcontrollers with DMA can specify a GPIO port as the destination for a transfer, I think. But I'm not sure how flexible they are about timing such transfers, or providing the sort of hand-shaking needed to let an external device know that new data is available - you may have to use a timer and/or some sort of "event system" to handle that part (unless you use the full external-memory interface, or unless the micro has some "parallel" interface more complex than plain GPIO.(Hmm. Also note that the quad-spi interfaces on some of the newer micros are getting to be pretty fast, compared with 8-bit parallel "real memory." Fast enough that they'll happily execute code from them. (although, I'm not sure that they can do DMA writes via QSPI.))

author: obiwanjacobi
author_rank: Super Contributor
timestamp: June 02, 2016, 06:44:43 am
content: Or a device that has both in one package? Like the Xilinx Zinq?

author: nctnico
author_rank: Super Contributor
timestamp: June 02, 2016, 06:55:23 am
content: Quote from: chickenHeadKnob on June 02, 2016, 05:29:44 amAn ethernet MAC is super simple to implement! It is nothing more than an SPI bus with several parallel lanes! There are way more microcontrollers out there with an ethernet MAC than an external memory bus. Secondly an ethernet MAC in a microcontroller usually has DMA capabilities so the processing overhead for doing the data transfers will be minimal. Going the ethernet MAC route really makes sense once you care to investigate in how it works under the hood. There is no black magic about it.

author: AndyC_772
author_rank: Super Contributor
timestamp: June 02, 2016, 07:58:33 am
content: I've done this; implementing a proprietary packet-based interface between CPU and FPGA by emulating an Ethernet MAC in the gate array.IIRC you do need a compatible CRC calculator, so the CPU doesn't reject received packets as corrupt. Other than that, I agree it's fairly straightforward.

author: Jeroen3
author_rank: Super Contributor
timestamp: June 02, 2016, 08:08:40 am
content: What speeds are you talking about?You have several options:- Single high speed SPI, should work with the DMA, still needs code to do read/writes.- Quad high speed SPI, if the MCU supports this it should be able to map it as external memory.- External memory interface, access the FPGA as it's mapped as RW in memory, fully hardware.- MAC, needs driver code that is not intended for this purpose. But you can make this work.Unless you'd need a real ethernet port as well.I know some people who implemented some basic computer vision algorithms in an FPGA and used the external memory interface of an STM32 to read and process the data at high speed.

author: CM800
author_rank: Frequent Contributor
timestamp: June 02, 2016, 08:22:31 am
content: Okay, for a better idea of the setting, here is what is going on:Closed loop Stepper / Servo drive, likely multi-axis.We will have 3-6, possibly up to 12 encoders that are either Serial or Incremental.The CPLD will be decoding them and allowing the microprocessor access to the values of their positionsalong with the ability to reset the value to zero or set it to another value.All values are 32 bit signed ints.Priorities in order are:Minimum Latancy (I need to read the most up to date value as possible as it goes into a feedback loop for positioning.Minimum Processing cost (I need to spend as little time reading the value as possible as every microsecond wasted will lower the performance of the motion control)Minimum Cost (Lets not try develop an ASIC here or use a Zinq.)

author: Jeroen3
author_rank: Super Contributor
timestamp: June 02, 2016, 09:05:59 am
content: 12 encoders, I see why you'd want some hardware to scan those.Those are all soft definitions. What is the speed of the feedback loop?You're looking at 384 bits per loop I guess.If you make a continuous 10 MHz spi output stream you can run the loop at 25 Khz.Or a little bit lower depending on the amount of undocumented wait cycles that are inserted.

author: AndreasF
author_rank: Frequent Contributor
timestamp: June 02, 2016, 09:23:26 am
content: As suggested bywestfwyou could use the internal DMA controller (e.g. of an STM32F4xx) to continuously read 16-bit GPIO port inputs, or use the external memory controller (ST calls it "flexible static memory controller") if you make the FPGA/CPLD look like an SRAM device to the microcontroller. You would probably want to use circular, double-buffering and also need some sort of syncing mechanism, but both of those things can be done with the DMA controller, i.e. without involvement of the CPU core (perhaps using a timer in capture mode to create the DMA requests, if you use the GPIO).Lets says you have the full 12 encoders, i.e. 12x32bits. Those could be transferred from the GPIO to memory in 24 16-bit DMA operations. If you run/trigger the DMA at 48Mhz, which should be possible, you could read the full set of 12 encoder values in half a microsecond. If you use double buffering the value you get to work with would therefore be no older than 1 microsecond.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: June 02, 2016, 09:48:19 am
content: Look at what speed you really need - SPI may be enough. QSPI/SDIO may be another pretty fast option without too many IO lines.If your MCU has a parallel camera interface that may be a good option for input.

author: Yansi
author_rank: Super Contributor
timestamp: June 02, 2016, 10:58:06 am
content: So what data rates we are talking about? Exact number please! Is it a few kB/s? Or 10MB/s?You have a large choice of: USART, SPI, QSPI, SDIO, ETH MAC (MII/RMII), parallel memory interface.I would recommend SPI (workable usually up to 50mbps) or the paralel memory interface (up to hundreds MByte/s or so)(And I would not recommend ETH MAC and SDIO)

author: CM800
author_rank: Frequent Contributor
timestamp: June 02, 2016, 03:33:28 pm
content: Quote from: Yansi on June 02, 2016, 10:58:06 amSay I want to do some amazing wizardry and create a 25kHz position loop, that gives us 25000*32*12 = 1172kB/sAgain, data rates arn't so important, Latancy is the highest priority. I need the latest values (and I need them now)Complexity on the CPLD is also important as I want to keep the gate count low.Huge thanks to all the responses so far, You have given me a lot to think about and I certainly need to go digging through datasheets now when I get back home.

author: Jeroen3
author_rank: Super Contributor
timestamp: June 02, 2016, 03:53:23 pm
content: Quote from: TCWilliamson on June 02, 2016, 03:33:28 pmNo, you need them before the next loop. Unless of course it is crucial that they are fetched faster than the 40 us it takes at 10Mhz spi.What latency is allowed?

author: CM800
author_rank: Frequent Contributor
timestamp: June 02, 2016, 04:12:08 pm
content: Quote from: Jeroen3 on June 02, 2016, 03:53:23 pmWell, looking at it like this:Sensor latancy + CPLD Cycle time (time taken from input to update the stored values) + transfer time need to be a reasonable amount under the period of the update rate, say 25KHz, 40uS.I'm trying to get as close to ideal as possible, there is a feedback loop that looks like this:The older the data you input, the more off your output will be which will in turn put your input further off, Maybe I am pushing too far and SPI will be just fine.I can be a bit of a perfectionist sometimes when it comes to the theory. EMC seems like a nice solution though however, plus it means I can put a lot more of the inputs into the CPLD (possibly put my ADCs in there too) Maybe even unload some of the more repeatative calculations into the CPLD or FPGA leaving the controller to handle the orders and interfaces.So many ideas to be considered and plans to be reviewed...

author: Jeroen3
author_rank: Super Contributor
timestamp: June 02, 2016, 05:01:01 pm
content: You should be able to run the spi at 50 MHz. That is well above 100 ksps. Should work imho.What speed controller are you using? If it's pid it should slow down before reaching the setpoint.I cannot imagine a few ms delay could be such a huge issue. Unless you're building some ultra high tech stuff for Lithography or nasa.

author: CM800
author_rank: Frequent Contributor
timestamp: June 02, 2016, 05:49:14 pm
content: Quote from: Jeroen3 on June 02, 2016, 05:01:01 pmLife goal: develop an X-ray Lithography machine to go on a NASA space station.I'm doing the groundwork for a long term goal of developing a motion controller.I'm looking at the best practices for operating down the line so I can work out the control system,this means that I can develop the simpler products / ones I'm working on now with that in mind, ensuring easy future expansion and development(keeping the IDE, development framework and IC manufacturers the same ideally and the user programmed code in line so it can be expanded logically onwards)

author: nctnico
author_rank: Super Contributor
timestamp: June 02, 2016, 06:12:42 pm
content: If this is a long term product without clear boundaries I would use an FPGA and a softcore and not look at the price. A design which is already optimised for cost is not going to be versatile in the long run. The first real customer you get will probably already exceed the capabilities of the system because all the off-the-shelve systems have the same limitation your system has.An FPGA with softcore allows for a simple start (low investment) and offers the flexibility of letting the FPGA do more (or less) depending on the requirements at hand.

author: CM800
author_rank: Frequent Contributor
timestamp: June 02, 2016, 06:48:38 pm
content: Quote from: nctnico on June 02, 2016, 06:12:42 pmWe do not have the design resources to hit the top market yet. I'm mostly trying to get my head around the actual timeline of products, we are planning to start with some small, low cost products then scale up.Cost is a major object in many areas. We are trying to focus on low cost high quantity rather then low quantity high cost. We have found the latter market completely full but the former very... empty.Our company has been a distributor for over 10 years, we are moving towards developing our own products.

author: suicidaleggroll
author_rank: Super Contributor
timestamp: June 02, 2016, 07:02:45 pm
content: Quote from: TCWilliamson on June 02, 2016, 06:48:38 pmThat's a fine end goal, but you don't want to cost-optimize yourself into a corner right out of the gate. When you're trying to design to a price point, you need to know your requirements to a "T". The exact protocol you're going to use, the speed you're going to run it at, etc. You don't want to make assumptions, build it as cheap as you can, and then find it won't work for the application. Start bigger than necessary, get it running, and THEN scale it down once you know your exact requirements.

author: nctnico
author_rank: Super Contributor
timestamp: June 02, 2016, 08:01:45 pm
content: I agree with suicidaleggroll; starting by looking at cost first can limit the options severely.But I'd also be wary about competing on price with a completely new product. I'd start by looking at what makes the other products expensive. Maybe it involves a lot of engineering (control loop theory) or customers needing massive amounts of support to get a system going.Either way I wouldn't turn the softcore + FPGA idea down yet. If someone can make a template with a softcore and toolchain (for example the LM32 softcore from Lattice) you'll have a good base to start from.

author: C
author_rank: Super Contributor
timestamp: June 02, 2016, 09:44:28 pm
content: Latency becomes less a problem if you know when the sample was taken.Add a time stamp to when the hardware took the encoder's value.The control loop can then look back in time at what the computer thought was the position and what actions have all ready been taken and refine the output going forward.

author: CM800
author_rank: Frequent Contributor
timestamp: June 02, 2016, 10:05:11 pm
content: Quote from: C on June 02, 2016, 09:44:28 pmNice in theory, but take note that all that adds processing power.I'm going to dig through and pin down some hard specifications for this unit.

author: nctnico
author_rank: Super Contributor
timestamp: June 02, 2016, 10:38:39 pm
content: Quote from: C on June 02, 2016, 09:44:28 pmThis delay is already covered by modelling the control loop! The easiest way is for the FPGA to dump data into the CPU which then triggers an interrupt. The first thing the interrupt routine does is dump the previously calculated data towards the controls (PWM, DAC, whatever) and then uses the new input data to calculate new output values. This way you have a very deterministic system to implement a control loop with known/predictable latencies.

author: markone
author_rank: Frequent Contributor
timestamp: June 03, 2016, 02:35:19 am
content: Quote from: TCWilliamson on June 02, 2016, 03:33:28 pmHave you a precise idea about the computational power required to properly close all the loops @ 25Khz ?If i well understood, within every 40us deterministic "slice" you should have to :1)readall field data from FPGA / MCU I/O2) run 12 position control loop tasks3) run some other stuff like state machines, protection check routines and so on4)updateall external motors controllers5) manage a communication control interface6) leave some spare time to absorbe computational peaksMmmh, what are you thinking for the CPU/MCU part ?Sure not a cheap one.In your place i would aim to a design where the FPGA close the control loops, but soft cores inside cheap devices are absolutly not convenient, so ... which is your budget ?

author: BravoV
author_rank: Super Contributor
timestamp: June 03, 2016, 04:48:07 am
content: Excuse me as a noob, its just I read TI's Arm-M4F TM4C129x MCU series ->Datasheet, there is a interesting built in peripheral called EPI (External Peripheral Interface), don't know if its suitable for your needs.Attached below brief summary of what EPI capable of, and highlighted few items that I "guess" maybe suitable, cmiiw.

author: CM800
author_rank: Frequent Contributor
timestamp: June 03, 2016, 06:58:50 am
content: Quote from: markone on June 03, 2016, 02:35:19 amBudget is a difficult one, It's a case of what I can justify. I need to do some more research to get a solid plan (so the first product will likely be a 1 axis proof-of-concept motion controller, from there once we developed the technology we will go straight to 8 axis, then use software to strip down to offer lower axis versions)I have seen some products out there that can do up to 64 axis and use a chip around the area of an Intel atom.We arn't going to have half the features they do. We are more interested in targeting the low budget market.Quote from: BravoV on June 03, 2016, 04:48:07 amNow that is interesting... Infact, exactly what I am looking for!General-Purpose mode– Wide parallel interfaces for fast communications with CPLDs and FPGAs– Data widths up to 32 bits– Data rates up to 150 MB/second– Optional "address" sizes from 4 bits to 20 bits– Optional clock output, read/write strobes, framing (with counter-based size), and clock-enableinput? General parallel GPIO– 1 to 32 bits, FIFOed with speed control– Useful for custom peripherals or for digital data acquisition and actuator controls

author: Yansi
author_rank: Super Contributor
timestamp: June 03, 2016, 09:18:07 am
content: External memory interface was has been already offered!!At least STM32 --> FSM / FMC peripheral. And others has mentioned that possibility also.

author: CM800
author_rank: Frequent Contributor
timestamp: June 03, 2016, 09:26:35 am
content: Quote from: Yansi on June 03, 2016, 09:18:07 amI read that a little early in the morning.I'm gonna spend the next few days investigating putting together a proper specification for the products... something I should have done earlier.

author: Jeroen3
author_rank: Super Contributor
timestamp: June 03, 2016, 09:45:39 am
content: But TI's marketing people called it anExternalPeripheralInterface. That is different, can't you see?If you use the cpld as if it was an memory mapped on the external memory controller you can just do:Code:int32_t enc = cpld->encoder;Minimal programming required. Speed depends on the clock of the bus.But it opens a lot of other possibilities too. You can use your own HDL peripherals!If the chip of choice does not contain , no problem just put it in the external hardware. Yes, you have a memory access latency penalty of a few clocks, it's not core register!. (considering you're staying on an microcontrollerand are not moving to anprocessor.But that could lead to some interesting things too, a processor. An ARM Cortex A or similar running with external flash, external ram and an external peripheral cpld/fpga.LikeSmartFusion.

author: CM800
author_rank: Frequent Contributor
timestamp: June 03, 2016, 09:53:04 am
content: Quote from: Jeroen3 on June 03, 2016, 09:45:39 amYes, I certianly like the idea of that. the MicroSemi SmartFusion SoCs looks quite apaitzing, lower cost then the Altera / Xilinx equivilents.Does anyone know the quality of Microsemi's toolchain (does it cost $$$$$?) and how... user friendly it is?

author: timb
author_rank: Super Contributor
timestamp: June 03, 2016, 11:27:13 am
content: Quote from: BravoV on June 03, 2016, 04:48:07 amJust FYI, the EPI has some major errata associated with it. Be sure to check before you even think about using it.They have a reference design for a SRAM board that fits to the Tiva C Connected Launchpad. Shouldn't cost much to have made and it's a quick way to test if the EPI will work for you.Unfortunately it didn't exist when I was working on an EPI based design. After spending weeks laying out a board, I stumbled upon the errata, which wasn't linked to from the product page, but a post on TI's forum. So I posted, asking if it was valid. They told me it may or may not be an actual bug, it could have just been a software problem but they couldn't be sure, but an engineer would contact me with a definitive answer. They never did.So, I switched to a PSoC 5LP, which also has support for external memory, going so far to support custom non-memory devices, in hardware even! Though, their documentation leaves a bit to be desired, but I can forgive that as it appears to be a new feature.Anyway, the EPI on the Tiva C did appear to basically work, and it's well documented in the TRM. You can even execute code from it! Sadly for me, it seems their engineers never anticipated that someone would want to use fast, high density SRAM as a framebuffer for the onboard Graphic LCD engine hardware... I mean, that's totally an unpredictable corner case, right? *Sighs*

author: Jeroen3
author_rank: Super Contributor
timestamp: June 03, 2016, 11:33:24 am
content: There are always undocumented features:https://www.eevblog.com/forum/microcontrollers/arm-external-bus-controller-timing/

author: markone
author_rank: Frequent Contributor
timestamp: June 03, 2016, 04:16:17 pm
content: Quote from: TCWilliamson on June 03, 2016, 06:58:50 amEven excluding last ATOM octa core chips and taking in account a lot cheaper model like the C2350, we are talking about total different beasts, especially when it comes down to FPU power and memory bandwidth numbers, those things literally draw circles around the current most powerfull arm MCU.If half features means half power (and so on) then you need at least an arm MPU incarnation to accomplish your task.