I'm looking for a Cortex-A class processor that has reasonably quick parallel I/O that might be hooked up to an FPGA. I'm aware of the existing Zynq and Altera SoC FPGAs, but looking for something different. By 'parallel I/O' I mean ideally a memory interface - either bidirectional eg 64-bits or separate 32-bit tx and 32-bit rx. GPIO with data valid signals/strobes is another possibility. By 'quick' I mean hundreds of MHz, ideally with low latency. I know there are things like the TI PRU in eg the OMAP family, but they seem to have a limited number of pins (16 bit tx/rx). Can anyone suggest anything else in this space? Thanks Theo
Application processor with fast parallel I/O
Started by ●September 9, 2016
Reply by ●September 9, 20162016-09-09
On 9/9/2016 10:34 AM, Theo Markettos wrote:> I'm looking for a Cortex-A class processor that has reasonably quick > parallel I/O that might be hooked up to an FPGA. I'm aware of the existing > Zynq and Altera SoC FPGAs, but looking for something different. > > By 'parallel I/O' I mean ideally a memory interface - either bidirectional > eg 64-bits or separate 32-bit tx and 32-bit rx. GPIO with data valid > signals/strobes is another possibility. By 'quick' I mean hundreds of MHz, > ideally with low latency. > > I know there are things like the TI PRU in eg the OMAP family, but they seem > to have a limited number of pins (16 bit tx/rx). > > Can anyone suggest anything else in this space?I think you are not going to find anything other than the memory interface. What's wrong with that? I assume you are referring to a processor that runs in the GHz range, but even then it would be hard for it to push data out of parallel I/O at "hundreds of MHz". Since this would be a very atypical use of parallel I/Os, I can't imagine a chip maker who would put the I/O pins on the fast local bus. Rather they are typically connected through a slower bus for the peripherals. Can I ask why you don't want to use high speed serial I/Os (which are intended for this) or a combined FPGA/CPU chip? Is using the memory interface too obvious or is there a reason to not use that? -- Rick C
Reply by ●September 9, 20162016-09-09
rickman <gnuarm@gmail.com> wrote:> I think you are not going to find anything other than the memory > interface. What's wrong with that? I assume you are referring to a > processor that runs in the GHz range, but even then it would be hard for > it to push data out of parallel I/O at "hundreds of MHz". Since this > would be a very atypical use of parallel I/Os, I can't imagine a chip > maker who would put the I/O pins on the fast local bus. Rather they are > typically connected through a slower bus for the peripherals. > > Can I ask why you don't want to use high speed serial I/Os (which are > intended for this) or a combined FPGA/CPU chip? Is using the memory > interface too obvious or is there a reason to not use that?I don't have a problem with using a memory interface, just would rather avoid something like PCIe - I don't have a transceiver interface to receive it. I just wasn't aware of anything that exported a 'simple' high speed memory interface. The reason for not using a combined FPGA/CPU chip is that I'll be using a dev board rather than making my own board (buying serious FPGAs in small quantities isn't fun and I'd rather not have to do the DDR3/etc layout). On the other side of my bridge CPLD/FPGA is a 1.5V parallel interface: most ARM FPGA dev boards hardwire their pins to something other than 1.5v, so I can't simply use the FPGA on the combined chip. I'm also physically constrained which rules out a lot of dev boards. Theo
Reply by ●September 9, 20162016-09-09
On Fri, 09 Sep 2016 15:34:23 +0100, Theo Markettos wrote:> I'm looking for a Cortex-A class processor that has reasonably quick > parallel I/O that might be hooked up to an FPGA. I'm aware of the > existing Zynq and Altera SoC FPGAs, but looking for something different. > > By 'parallel I/O' I mean ideally a memory interface - either > bidirectional eg 64-bits or separate 32-bit tx and 32-bit rx. GPIO with > data valid signals/strobes is another possibility. By 'quick' I mean > hundreds of MHz, ideally with low latency. > > I know there are things like the TI PRU in eg the OMAP family, but they > seem to have a limited number of pins (16 bit tx/rx). > > Can anyone suggest anything else in this space?Have you looked at data sheets? The last time I looked it seemed like there were ones out there that came with built-in SDRAM interfaces. That may not be ideal ('cuz you'd have to make your FPGA that pretend to be SDRAM), but it should support the bandwidth you'd want. I have to admit I didn't look hard -- I wanted a microcontroller with a Cortex A core; I basically stopped looking when I saw that I'd need to deal with external memory and whatnot if I wanted that core. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●September 9, 20162016-09-09
On Fri, 09 Sep 2016 15:14:50 -0500, Tim Wescott wrote:> On Fri, 09 Sep 2016 15:34:23 +0100, Theo Markettos wrote: > >> I'm looking for a Cortex-A class processor that has reasonably quick >> parallel I/O that might be hooked up to an FPGA. I'm aware of the >> existing Zynq and Altera SoC FPGAs, but looking for something >> different. >> >> By 'parallel I/O' I mean ideally a memory interface - either >> bidirectional eg 64-bits or separate 32-bit tx and 32-bit rx. GPIO >> with data valid signals/strobes is another possibility. By 'quick' I >> mean hundreds of MHz, ideally with low latency. >> >> I know there are things like the TI PRU in eg the OMAP family, but they >> seem to have a limited number of pins (16 bit tx/rx). >> >> Can anyone suggest anything else in this space? > > Have you looked at data sheets? The last time I looked it seemed like > there were ones out there that came with built-in SDRAM interfaces. > That may not be ideal ('cuz you'd have to make your FPGA that pretend to > be SDRAM), but it should support the bandwidth you'd want. > > I have to admit I didn't look hard -- I wanted a microcontroller with a > Cortex A core; I basically stopped looking when I saw that I'd need to > deal with external memory and whatnot if I wanted that core.Here. Poof -- first one I looked at. Has high speed "conventional" memory interfaces as well as SDRAM interfaces. Some shopping should get you some hits. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●September 9, 20162016-09-09
On 09.9.2016 г. 23:14, Tim Wescott wrote:> On Fri, 09 Sep 2016 15:34:23 +0100, Theo Markettos wrote: > >> I'm looking for a Cortex-A class processor that has reasonably quick >> parallel I/O that might be hooked up to an FPGA. I'm aware of the >> existing Zynq and Altera SoC FPGAs, but looking for something different. >> >> By 'parallel I/O' I mean ideally a memory interface - either >> bidirectional eg 64-bits or separate 32-bit tx and 32-bit rx. GPIO with >> data valid signals/strobes is another possibility. By 'quick' I mean >> hundreds of MHz, ideally with low latency. >> >> I know there are things like the TI PRU in eg the OMAP family, but they >> seem to have a limited number of pins (16 bit tx/rx). >> >> Can anyone suggest anything else in this space? > > Have you looked at data sheets? The last time I looked it seemed like > there were ones out there that came with built-in SDRAM interfaces. That > may not be ideal ('cuz you'd have to make your FPGA that pretend to be > SDRAM), but it should support the bandwidth you'd want. > > I have to admit I didn't look hard -- I wanted a microcontroller with a > Cortex A core; I basically stopped looking when I saw that I'd need to > deal with external memory and whatnot if I wanted that core. >Hi Tim, not having fpga experience (though I have designed plenty of logic, used cpld-s, written a logic compiler for cpld-s and another for GAL-s back in the day etc.) I wonder if it would not be easier to use PCIe than pretend to be DDRAM. I have seen fpga-s (soon I may have to use one with DDR etc. if I want to have a display controller which I seem to do...) advertising PCI-e which looks somehow "readily available" to the customer, perhaps this could be a way? I have also seen them having DDR but it seems to be the wrong way around for this task (not for mine with the display though). Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●September 9, 20162016-09-09
On Fri, 09 Sep 2016 23:48:22 +0300, Dimiter_Popoff wrote:> On 09.9.2016 г. 23:14, Tim Wescott wrote: >> On Fri, 09 Sep 2016 15:34:23 +0100, Theo Markettos wrote: >> >>> I'm looking for a Cortex-A class processor that has reasonably quick >>> parallel I/O that might be hooked up to an FPGA. I'm aware of the >>> existing Zynq and Altera SoC FPGAs, but looking for something >>> different. >>> >>> By 'parallel I/O' I mean ideally a memory interface - either >>> bidirectional eg 64-bits or separate 32-bit tx and 32-bit rx. GPIO >>> with data valid signals/strobes is another possibility. By 'quick' I >>> mean hundreds of MHz, ideally with low latency. >>> >>> I know there are things like the TI PRU in eg the OMAP family, but >>> they seem to have a limited number of pins (16 bit tx/rx). >>> >>> Can anyone suggest anything else in this space? >> >> Have you looked at data sheets? The last time I looked it seemed like >> there were ones out there that came with built-in SDRAM interfaces. >> That may not be ideal ('cuz you'd have to make your FPGA that pretend >> to be SDRAM), but it should support the bandwidth you'd want. >> >> I have to admit I didn't look hard -- I wanted a microcontroller with a >> Cortex A core; I basically stopped looking when I saw that I'd need to >> deal with external memory and whatnot if I wanted that core. >> >> > Hi Tim, > not having fpga experience (though I have designed plenty of logic, used > cpld-s, written a logic compiler for cpld-s and another for GAL-s back > in the day etc.) I wonder if it would not be easier to use PCIe than > pretend to be DDRAM. I have seen fpga-s (soon I may have to use one with > DDR etc. if I want to have a display controller which I seem to do...) > advertising PCI-e which looks somehow "readily available" to the > customer, perhaps this could be a way? I have also seen them having DDR > but it seems to be the wrong way around for this task (not for mine with > the display though).I did think that, and should have commented. One of the features of life in a world with big FPGAs is that you can just go out and buy IP to do things like talk to SDRAM or PCI. The last time that I was involved in such a project the PCI in question was "plain old", but there has to be PCI-e cores out there for sale. "Reverse" SDRAM would be more rare, but the actual core should be simpler (and answers the OP's question more closely). Were it me, I'd certainly leave PCI-e on the table until I'd done some design studies. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●September 9, 20162016-09-09
Dimiter_Popoff <dp@tgi-sci.com> wrote:> not having fpga experience (though I have designed plenty of logic, > used cpld-s, written a logic compiler for cpld-s and another for GAL-s > back in the day etc.) I wonder if it would not be easier to use PCIe > than pretend to be DDRAM. I have seen fpga-s (soon I may have to use one > with DDR etc. if I want to have a display controller which I seem to > do...) advertising PCI-e which looks somehow "readily available" to > the customer, perhaps this could be a way? I have also seen them having > DDR but it seems to be the wrong way around for this task (not for mine > with the display though).PCIe is relatively easy to use, but does involve a much more heavyweight stack at both ends - needs a full PCIe root complex and an FPGA that supports high speed transceivers. Everything ends up much larger/more expensive - both for the FPGA and for the CPU. Many ARM application processor SoCs don't have PCIe, for instance, which means you end up having an Atom-class SoC or larger. I hadn't thought about pretending to be SDRAM - will think about that. Which CPU did you find, Tim? I suspect finding a dev board that exposes SDRAM pins but wires DDR3 internally is going to be tricky. Theo
Reply by ●September 9, 20162016-09-09
Tim Wescott <seemywebsite@myfooter.really> wrote:> Were it me, I'd certainly leave PCI-e on the table until I'd done some > design studies.In this specific case: I have no FPGA transceivers I can interface to. Space constrains me to a physically small FPGA with a limited number of pins. PCIe latency (~500ns) is too high for small messages Theo
Reply by ●September 9, 20162016-09-09
On 10.9.2016 г. 00:34, Theo Markettos wrote:> Dimiter_Popoff <dp@tgi-sci.com> wrote: >> not having fpga experience (though I have designed plenty of logic, >> used cpld-s, written a logic compiler for cpld-s and another for GAL-s >> back in the day etc.) I wonder if it would not be easier to use PCIe >> than pretend to be DDRAM. I have seen fpga-s (soon I may have to use one >> with DDR etc. if I want to have a display controller which I seem to >> do...) advertising PCI-e which looks somehow "readily available" to >> the customer, perhaps this could be a way? I have also seen them having >> DDR but it seems to be the wrong way around for this task (not for mine >> with the display though). > > PCIe is relatively easy to use, but does involve a much more heavyweight > stack at both ends - needs a full PCIe root complex and an FPGA that > supports high speed transceivers. Everything ends up much larger/more > expensive - both for the FPGA and for the CPU. Many ARM application > processor SoCs don't have PCIe, for instance, which means you end up having > an Atom-class SoC or larger.I have used and programmed PCI a few times and assuming that PCIe is very similar from a programmers point of view I'd say you can do it without too much pain. If your two sides will be aware of each other (i.e. not discover what is there on the bus, things allowed to do, set address range etc.) you can do it quite easily, you will only need the bus handshakes. And if you restrict them to a known size (say, 32 bit) it becomes even easier.> > I hadn't thought about pretending to be SDRAM - will think about that. > Which CPU did you find, Tim? I suspect finding a dev board that > exposes SDRAM pins but wires DDR3 internally is going to be tricky.Should be doable, they do put 2 DIMMS per board after all (still so?). But you are likely to get yourself into a nightmare of problems, trial and error etc. - whereas the PCIe link will just work unless you abuse it too much (not so long ago I switched from ATA to SATA - well, the SATA part were just 4 signal wires and connecting them in a decent way it just worked for me). You might want to look at the Freescale (now NXP) QorIQ parts, like the t1040 or the t1042, large and not really cheap things but I think they had smaller and cheaper there, too. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/