ARM with fast parallel GPIO

[Nominal Animal]

If anyone is interested, I just posted in another thread here a description on how to use SET and CLEAR GPIO registers available on many ARMs with a couple of lookup tables, to implement semi-efficient "buses" with completely arbitrary pin mappings; just in case there are devs unfamiliar with this technique.

These write-only registers have the property that clear (0) bits mean "no change" to the output pin state, and set bits (1) either set or clear the GPIO pin output state corresponding to that bit and bank.  There is usually also a third register, TOGGLE, that inverts the output pin state; this can be very useful for read/write strobes and the clock pin.  The downside is that it does require a dozen or so instructions per "bus" access, some RAM (or Flash, if the pinout is fixed at compile time) lookup accesses, and that even when the pins are in the same GPIO bank, rising edges are always before falling edges (or vice versa).

The code shown there is not optimized for any specific architecture, and can be optimized further.  (In particular, instead of doing a second lookup for the clear part, one could just invert all the bus bits in the looked-up bit masks instead.  Much faster.)

[technix]

I know you don't want FPGA, but it seem to me that a Zynq 7010, SmartFusion or a Hercules M7 would work best for your use. All of which are FPGA + ARM combo chips, Zynq 7010 has a dual-core Cortex-A9, while SmartFusion and Hercules M7 has Cortex-M3.

For the package, SmartFusion has QFP144 and QFP208. Hercules M7 has QFP144 and QFN88.

What you need here would be a minimal initialization on the FPGA with that parallel interface and necessary memories hooked directly into the ARM core.

[technix]

Interfacing with FPGAs is such a common task that I don't understand why chip vendors do not include a dedicated peripheral for that, which would be also reusable as a general purpose parallel streaming interface.

AFAIK most FPGA's uses either standard (Q)SPI interface or standard SRAM interface for MCU interfacing - from booting to application communications. Then there are all those FPGA + MCU hybrids like Microchip SmartFusion, Gowin Little Bee and Hercules M7, as well as FPGA + MPU hybrids like Zynq and Cyclone SoC.

[dietert1]

I remember using a Kinetis Arm Cortex with a feature they called "Flexbus", maybe 2014 or so. I could configure it for different data and address widths and it would behave like a microcomputer bus, mapping a segment of the MCUs data address space. I used it to map the RAM of an LCD controller for fast access.

Regards, Dieter

[Bassman59]

Interfacing with FPGAs is such a common task that I don't understand why chip vendors do not include a dedicated peripheral for that, which would be also reusable as a general purpose parallel streaming interface.

AFAIK most FPGA's uses either standard (Q)SPI interface or standard SRAM interface for MCU interfacing - from booting to application communications. Then there are all those FPGA + MCU hybrids like Microchip SmartFusion, Gowin Little Bee and Hercules M7, as well as FPGA + MPU hybrids like Zynq and Cyclone SoC.

The fun thing about FPGAs is that you can use any sort of thing you want to interface to the MCU. That is, there isn't any standard. I've used I2C, I've used UART, I've used the SiLabs EMIF.

But I still want a synchronous parallel interface that supplies the clock. Why do the MCU vendors give us an SDRAM interface but an async SRAM interface? Having the MCU supply a continuous clock with the data, address and R/W strobe solves a bunch of problems.

[technix]

The fun thing about FPGAs is that you can use any sort of thing you want to interface to the MCU. That is, there isn't any standard. I've used I2C, I've used UART, I've used the SiLabs EMIF.

I should have been more clear about this. What I mean is ports that allow the MCU to both configure and communicate with he FPGA.

But I still want a synchronous parallel interface that supplies the clock. Why do the MCU vendors give us an SDRAM interface but an async SRAM interface? Having the MCU supply a continuous clock with the data, address and R/W strobe solves a bunch of problems.

I'd rather have an independent clock for the FPGA from the MCU, and use the WAIT flag for flow control.

[Berni]

I should have been more clear about this. What I mean is ports that allow the MCU to both configure and communicate with he FPGA.

FPGAs can do self reconfiguration so its possible to have a FPGA reconfigure part of itself trough any custom interface. Tho this does get rather complicated.

Another way to use a custom bus to load a configuration into a FPGA is to implement a bridge from your custom interface to whatever external configuration flash it uses. You write the new configuration into flash and then reboot into it. To prevent bricking itself its also often possible to have 2 sets of images and choose the one to boot depending on some pins.

In any case pretty much every external boot flash FPGA out there supports booting from SPI flash. Not only does pretty much every MCU under the sun have a SPI port, the modern ones typically have like 2 to 6 of these things. Sometimes you also get I2C or a 8/16bit parallel bus. Also you don't always have to emulate a flash chip on this bus since a lot of the FPGAs typically also have a "slave mode" on this interface, so you get to feed the FPGA its bitstream at whatever speed you like.

But I still want a synchronous parallel interface that supplies the clock. Why do the MCU vendors give us an SDRAM interface but an async SRAM interface? Having the MCU supply a continuous clock with the data, address and R/W strobe solves a bunch of problems.

I'd rather have an independent clock for the FPGA from the MCU, and use the WAIT flag for flow control.

Once you have spent some time designing FPGA code you will see just how annoying clock crossings are. It's usually most convenient to make the FPGA march along at whatever clock the other device is going at because then you can always sample input signal on a clock edge and be sure you got good clean non metastable corrupted data.

The biggest problem with having no clock when you start doing asynchronous burst operations on a memory bus. These kinds of transfers tend to be required to squeeze the maximum throughout out of a MCUs memory controller. But during these transfers you typically have all the control lines stay in the active state while only the address pins count up. This makes it very difficult for a FPGA sampling the bus at its own clock speed to determine when it should put the next bit of data on the bus, especially since sampling right on a transition might get you a garbage address. So you see it counting 0x0E 0x0E 0x1E 0x10 0x10 0x10 0x10 0x11 0x11

Still QSPI is an excellent high throughput interface bus to a MCU. It still wont go as fast as a 16bit parallel bus but it does tend to support fairly high clock speeds so its not that far behind.

[Bassman59]

But I still want a synchronous parallel interface that supplies the clock. Why do the MCU vendors give us an SDRAM interface but an async SRAM interface? Having the MCU supply a continuous clock with the data, address and R/W strobe solves a bunch of problems.

I'd rather have an independent clock for the FPGA from the MCU, and use the WAIT flag for flow control.

Once you have spent some time designing FPGA code you will see just how annoying clock crossings are. It's usually most convenient to make the FPGA march along at whatever clock the other device is going at because then you can always sample input signal on a clock edge and be sure you got good clean non metastable corrupted data.

Berni's correct here. This is exactly why I want the micro to supply a clock to the FPGA that is synchronous with the data and address and strobes. It's the basic source-synchronous bus. It makes the design a lot easier.

I notice that the TI TM4C1294 "Tiva" and its cousin the MSP432E have exactly what I ask for in an external bus interface.

[technix]

Synchronous parallel... can the FPGA just emulate SDRAM? Also is it somewhat synchronous if the asynchronous-style bus and the independent-ish clock has the same source? (STM32F103ZE + FPGA style - STM32F103ZE has an asynchronous parallel external memory interface with wait signals, it also have a MCO pin that outputs some internal clock signal, and both are clocked from the same PLL.

If you do get to use Zynq, SmartFusion or Hercules M7, those FPGA + MCP/MPU combo chips just give you bare AXI/AHB interfaces which is also synchronous.

[Bassman59]

Synchronous parallel... can the FPGA just emulate SDRAM?

Sure, but why overcomplicate the matter?

[technix]

Sure, but why overcomplicate the matter?

It is much more common to find SDRAM support on processors, both MCUs and MPUs. It is up there with QSPI and direct internal clock output.

[jonroger]

Here is a case where 50 Msps parallel input was achieved on a teensy 4.1.   Simple software polling is good for about 15-30
 Msps.

https://forum.pjrc.com/threads/66201-Teensy-4-1-How-to-start-using-FlexIO?p=279459

[Nominal Animal]

The cheaper Teensy 4.0 ($20) has 5 FlexIO1 pins (2, 3, 4, 5, 33), 9 FlexIO2 pins (6, 7, 8, 9, 10, 11, 12, 13, 32), and 14 FlexIO3 pins (7, 8, 14, 25, 16, 17, 18, 19, 20, 21, 22, 23, 26, 27); of these, pins 7 and 8 are available in both FlexIO2 and FlexIO3.

FlexIO1 has one consecutive group of pins, 4-8 (pins 2, 3, 4, 33, 8).
FlexIO2 has three consecutive groups of pins: 0-3 (pins 10, 12, 11, 13), 10-12 (pins 6, 9, 32), 16-17 (pins 8, 7).
FlexIO3 has three consecutive groups of pins: 0-3 (pins 19, 18, 14, 15), 6-11 (pins 17, 16, 22, 23, 20, 21), and 14-17 (pins 26, 27, 8, 7).

What I haven't realized before, that just because the other pins aren't exposed, does not mean they cannot be used.  For example, FlexIO3 4-5 (AD_B1_04, AD_B1_05) and 12-13 (AD_B1_12, AD_B1_13) are not used on the Teensy (connection schematics here).  They do exist on the BGA package, but are not exposed nor used for other purposes, like say AD_B0_04..AD_B0_11 are for the bootloader chip.  So, if one does an 16-bit shift to FlexIO3 0-15, one gets bits 0..3, 6..11, and 14..15 on pins 19, 18, 14, 15, 17, 16, 22, 23, 20, 21, 26, 27; i.e., twelve of the 16 bits as outputs.  For receive/input, the 12 input bits are just spread over 16 data bits with two two-bit holes in the middle.

Mmm, more experiments to do!

[SiliconWizard]

Sure, but why overcomplicate the matter?

It is much more common to find SDRAM support on processors, both MCUs and MPUs. It is up there with QSPI and direct internal clock output.

I see the point; SDRAM support is common, and the IOs dedicated to SDRAM can toggle much faster than typical GPIOs (they usually should accomodate 133MHz or 166MHz SDRAM.) Implementing a communication bus at those rates with common GPIOs is usually not possible on most MCUs.

[Berni]

The SDRAM pins usually don't really have any special IO drivers on MCUs, they just set the IO for the highest drive strength.

You often see support for both SRAM and SDRAM on the same data and address pins. However they usually only support async SRAM, so you don't get any clock pin, and its understandable since most SRAM out there is async, its only the more specialized high performance stuff that is synchronous SRAM and that is something you typically wouldn't use as memory for a MCU.

The reason why you wouldn't want to use the SDRAM bus is because it is much more complicated than SRAM. On SRAM the address is simply placed on the address pins and the data is returned onto the data pins, that is it. On the other hand SDRAM operates in a way that is convenient for DRAM, so instead of an address it sends commands for selecting rows and columns, these commands take certain numbers of clock cycles to execute (CAS RAS timing) and read/write commands also execute with a certain numbers of cycles of delay, so you can string together read commands into the pipeline and have them execute staggered simultaneously with all of there data coming out later on. This means that acting like a SDRAM memory chip is a lot more work in a FPGA, while making it act like a SRAM chip takes about 10 lines of Verilog/VHDL.

Even the more serious larger SOCs sometimes retain a SRAM bus, but its mostly for backwards compatibility with async bus peripherals. The actual memory tends to be some flavor of DDR and this does typically run on dedicated pins that often don't even have the ability to be used as GPIO at all.

[SiliconWizard]

The SDRAM pins usually don't really have any special IO drivers on MCUs, they just set the IO for the highest drive strength.

Possibly so, although I do not know that for sure on all MCUs.

But that's beyond the point - what matters is, SDRAM controllers can usually get you faster data throughput than using any other peripheral on most MCUs. As I mentioned, what mid-range MCU using what peripheral  can get you a parallel bus @166MHz? I do not know of many examples. That was the point.

Of course if on some MCU, you have an FMC-like interface that can work at the same frequencies, it's much easier to use that. But I just haven't seen many MCUs like that.

[Berni]

True the SDRAM interface is typically the highest clocked. But it does have significant amount of overhead and latency where it has to set up a transaction before it happens so there are some slight tradeoffs still.

The kind of interface that is really well suited are synchronous SRAM with burst transfer support. This is used by some parallel interface raw flash chips.It looks similar to SRAM except it does have a clock and the burst transfer will transfer a word of data on each clock cycle. This also typically optionally supports address latch mode so the first word of the transfer contains the address, saving you a lot of address lines.

Still the sort of speeds possible with these are so high that a MCU might have difficulties doing something useful with it, since at that point the CPU only has 1 or 2 instruction cycles per word for doing any actuall processing on it. So for this reason a high clocked QSPI tends to be as fast as you would typically need to go. Most of the benefit for using a external memory bus is that the FPGA can be memory mapped to the CPU like any other peripheral. This potentially saves a significant amount of overhead inside peripheral drivers that otherwise need to be told to actually send a command over that does the thing you want to do, yet if its memory mapped the CPU can work with it just like the FPGA was built into the same chip. No need to DMA buffers over into RAM to be worked on, you can just access the buffer like it is RAM itself.

[tom66]

For 4-bits, Quad SPI can be used.  However, for more bits, it gets tricky.

A solution I have seen before used an inexpensive CPLD, which took SPI data and derived a 1/8th clock from the byte data to do serial to parallel conversion.    In principle if you keep the SPI buffer fed the data will be continuous. The trick then comes in doing it at high data rates - SPI might max out around 25Mbit/s, so max 8-bit data rate ~3.12MHz.  You could try a quad-SPI to 8-bit converter, which would get you up to 12MHz.  Still quite below your 50-100MHz goal.

There exist some ARM+FPGA devices, though probably overkill for this.   A lightweight option of a Microsemi SmartFusion SoC is an option, but the toolchain is bloody terrible, and the device isn't exactly cheap.  Xilinx Zynq is almost certainly overkill, but this kind of work is its bread and butter (software/FPGA fusion)

A CPLD or micro FPGA with an integrated PLL might be able to take jittery 8-bit parallel data and clean it up somewhat - feed in the data with some handshaking signals and you could get a decent buffer rate out.  But you'd probably need to buffer hundreds of samples to clean the jitter up nice enough and the FPGA design would not necessarily be trivial if you haven't done that kind of thing before.

[SiliconWizard]

True the SDRAM interface is typically the highest clocked. But it does have significant amount of overhead and latency where it has to set up a transaction before it happens so there are some slight tradeoffs still.

Yes, it's far from ideal. I was just somehow getting technix's point.

Generally speaking, I find easy-to-use, general-purpose, high-speed interfaces lacking on MCUs in general.
Your best bet for high-speed/low pin count are ethernet (but it's rarely gigabit ethernet on MCUs, which would still be "only" about 100 MBytes/s, and 100M ethernet is 1/10th that...) and USB. Both are relatively annoying to implement on the other side, except if the device you want to communicate with already supports this.

Could be nice to have some high-speed SERDES on common MCUs, say Cortex-M7, that could be used for general-purpose stuff, without too much overhead and a not too complex protocol to handle. And preferably one that is not covered by a nasty patent with fees to pays to use it. Anyway...

Otherwise, of course, one approach is to use a FPGA. Either connected to a MCU - as said by tom66, comm between the two can be asynchronous, and the FPGA can take care of making it synchronous. Or, you can do it all on FPGA with a soft core.

[Berni]

I seen cases where people used the SPI peripheral as "SERDES" on a 8bit AVR in order to get fast enough IO to bitbang color composite video out of it. Tho on these small 8bit MCUs the SPI runs at the same clock speed as the CPU. On a more modern ARM chip the SPI typically runs significantly slower on its own peripheral bus, so its not nearly as useful of a trick. Still QSPI is not to be underestimated in terms of speed.

In my projects i always used a SRAM bus to get high bandwidth communication between a MCU and FPGA and it works great (Especially love being able to debug FPGA peripherals straight from the MCU IDE since its all just memory). Or if speed was not as critical, then a SPI bus that encodes  bus read/write commands.

[tggzzz]

Hello,

I'm looking for some Cortex-M MCU which would be ideal to feed fast DAC through a parallel interface.

1. I don't want any DSP or FPGA, just a regular ARM MCU.
2. I don't have any strict minimal speeds in mind just as fast as it can be.. getting some parallel interface that could run close to 50-100Mhz would be nice.

I'm in a process of reading up on various MCUs and going over my options but if there is somebody who has used some ARM for something similar I would be glad to hear it.

Hardware and bus interfaces are usually the easy bit. The more difficult bit is guaranteeing by design hard realtime timing in software, especially if the processor has caches and uses interrupts. Naturally doing anything other than feeding the i/o significantly complicates matters, but that is not insuperable.

There is only one family of processors that I am aware of that directly addresses and solves those issues: the XMOS xCORE processors. Buy those at DigiKey. FFI, see my other posts on the subject.

[DiTBho]

[..] timing [..]

I am having a lot of troubles with u-boot on a the RAM controller of PowerPC SoM.
I have here several PC100 and PC133 ram sticks. Some do work, some do not work.
I am manually patching the code here and there, and timing is very problematic.

I guess, it's not as easy as people think.

[Bassman59]

Hello,

I'm looking for some Cortex-M MCU which would be ideal to feed fast DAC through a parallel interface.

1. I don't want any DSP or FPGA, just a regular ARM MCU.
2. I don't have any strict minimal speeds in mind just as fast as it can be.. getting some parallel interface that could run close to 50-100Mhz would be nice.

I'm in a process of reading up on various MCUs and going over my options but if there is somebody who has used some ARM for something similar I would be glad to hear it.

Hardware and bus interfaces are usually the easy bit. The more difficult bit is guaranteeing by design hard realtime timing in software, especially if the processor has caches and uses interrupts. Naturally doing anything other than feeding the i/o significantly complicates matters, but that is not insuperable.

There is only one family of processors that I am aware of that directly addresses and solves those issues: the XMOS xCORE processors. Buy those at DigiKey. FFI, see my other posts on the subject.

... but what if my application is not hard real-time? I just want a fast synchronous parallel bus. The bus fits somewhere in the micro's memory map and provides address (of however many bits are interesting), data (same), read/write indication and maybe a chip select just to save pins (we don't need a full 32 bit address). By synchronous I mean that the micro provides a clock synchronous to the bus, and that clock always runs, so my FPGA doesn't need a separate oscillator and there are no synchronization issues. The micro does read and write accesses to that address space and it just works. We've been doing this forever, back when we were using microprocessors and not microcontrollers!

This bus exists: synchronous SRAMs use them. Hell, even old-school parallel PCI is exactly this, albeit with the overhead of BARs and such. But PCI cores are still provided in most current FPGA families so ...

Anyway: TI TM4C Tiva parts and MSP432 parts have a synchronous parallel EBI.

Anyway: if you're using an XMOS part, do you need the FPGA? That's application-dependent, of course.

[tggzzz]

Hello,

I'm looking for some Cortex-M MCU which would be ideal to feed fast DAC through a parallel interface.

1. I don't want any DSP or FPGA, just a regular ARM MCU.
2. I don't have any strict minimal speeds in mind just as fast as it can be.. getting some parallel interface that could run close to 50-100Mhz would be nice.

I'm in a process of reading up on various MCUs and going over my options but if there is somebody who has used some ARM for something similar I would be glad to hear it.

Hardware and bus interfaces are usually the easy bit. The more difficult bit is guaranteeing by design hard realtime timing in software, especially if the processor has caches and uses interrupts. Naturally doing anything other than feeding the i/o significantly complicates matters, but that is not insuperable.

There is only one family of processors that I am aware of that directly addresses and solves those issues: the XMOS xCORE processors. Buy those at DigiKey. FFI, see my other posts on the subject.

... but what if my application is not hard real-time? I just want a fast synchronous parallel bus. The bus fits somewhere in the micro's memory map and provides address (of however many bits are interesting), data (same), read/write indication and maybe a chip select just to save pins (we don't need a full 32 bit address). By synchronous I mean that the micro provides a clock synchronous to the bus, and that clock always runs, so my FPGA doesn't need a separate oscillator and there are no synchronization issues. The micro does read and write accesses to that address space and it just works. We've been doing this forever, back when we were using microprocessors and not microcontrollers!

This bus exists: synchronous SRAMs use them. Hell, even old-school parallel PCI is exactly this, albeit with the overhead of BARs and such. But PCI cores are still provided in most current FPGA families so ...

Anyway: TI TM4C Tiva parts and MSP432 parts have a synchronous parallel EBI.

Anyway: if you're using an XMOS part, do you need the FPGA? That's application-dependent, of course.

If you don't need hard realtime then life is much easier and there are many more solutions

XMOS xCORE processors fit into the niche between standard MCUs and FPGAs, offering (within limits!) the advantages of FPGAa with the advantages of standard software development tools. Whether your application's requirements fit xCORE/MCU/FPGA/discrete/etc technology is always an interesting topic. It is a shame that too many people only have a hammer in their toolbox