Direct Memory Access (ARM -> FPGA/CPLD?)

[suicidaleggroll]

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

That'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.

[nctnico]

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.

[C]

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.

 
 

[CM800]

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.

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

[nctnico]

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.

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

[markone]

Say I want to do some amazing wizardry and create a 25kHz position loop, that gives us 25000*32*12 = 1172kB/s
-snip

Have 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) read all field data from FPGA / MCU I/O
2) run 12 position control loop tasks
3) run some other stuff like state machines, protection check routines and so on
4) update all external motors controllers 
5) manage a communication control interface
6) leave some spare time to absorbe computational peaks

Mmmh, 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 ?

[BravoV]

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.

[CM800]

Say I want to do some amazing wizardry and create a 25kHz position loop, that gives us 25000*32*12 = 1172kB/s
-snip

Have 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) read all field data from FPGA / MCU I/O
2) run 12 position control loop tasks
3) run some other stuff like state machines, protection check routines and so on
4) update all external motors controllers 
5) manage a communication control interface
6) leave some spare time to absorbe computational peaks

Mmmh, 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 ?

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

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.

Now 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-enable
input
? General parallel GPIO
– 1 to 32 bits, FIFOed with speed control
– Useful for custom peripherals or for digital data acquisition and actuator controls

[Yansi]

External memory interface was has been already offered!! 

At least STM32 --> FSM / FMC peripheral. And others has mentioned that possibility also.

[CM800]

External memory interface was has been already offered!! 

At least STM32 --> FSM / FMC peripheral. And others has mentioned that possibility also.

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

[Jeroen3]

But TI's marketing people called it anExternal Peripheral Interface. 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: [Select]

int32_t enc[0] = cpld->encoder[0];
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 [peripheral], 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 microcontroller and are not moving to an processor.
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.
Like SmartFusion.

[CM800]

But TI's marketing people called it anExternal Peripheral Interface. 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: [Select]

int32_t enc[0] = cpld->encoder[0];
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 [peripheral], 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 microcontroller and are not moving to an processor.
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.
Like SmartFusion.

Yes, 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?

[timb]

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.

Just 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*

[Jeroen3]

There are always undocumented features:
https://www.eevblog.com/forum/microcontrollers/arm-external-bus-controller-timing/

[markone]

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.

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