EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

ARM + FPGA CPU Module running Yocto Linux?

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - FPGA - ARM + FPGA CPU Module running Yocto Linux?

Goto page Previous  1, 2, 3  Next

A.P.Richelieu
Guest

Wed Jan 30, 2019 9:45 pm   



Den 2019-01-30 kl. 21:05, skrev lasselangwadtchristensen_at_gmail.com:
Quote:
onsdag den 30. januar 2019 kl. 20.35.51 UTC+1 skrev A.P.Richelieu:
Den 2019-01-30 kl. 20:27, skrev lasselangwadtchristensen_at_gmail.com:
onsdag den 30. januar 2019 kl. 19.28.43 UTC+1 skrev A.P.Richelieu:
Den 2019-01-30 kl. 18:28, skrev gnuarm.deletethisbit_at_gmail.com:
On Wednesday, January 30, 2019 at 12:13:34 PM UTC-5, A.P.Richelieu wrote:
Is there any ARM + FPGA CPU Module running linux using any of:

* NXP i.MX6/7/...
* Texas Instrument Sitara AM335x or better
* Microchip SAMA5
* Renesas RZ/xxx

It needs to be connected to a low price FPGA, Intel or Xilinx.

* Zynq or Intel SoC solutions need not apply.

Other vendors will be difficult to accept.

=====================

The CPU Module needs at least
* 128 MB RAM
* 128 MB Flash.
Connector will have
* 100 Mbps Ethernet
* 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
* 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
* SD-Card
* A few custom protocol LVDS channels
=====================
The processor has to be connected to an FPGA on a suitable
interface providing 5-10 MB/second transfer rate.
The FPGA needs to have 80-100 free I/O, not including the
interface to the CPU to implement SPIs, UARTs and other custom signals
=====================
The CPU should be able to load the FPGA after reset.
Preferably right after loading the U-Boot (during the BOOTDELAY timer).
=====================
Preferably, the processor should be able to access the internals
of the FPGA like it was on the memory bus.

Putting the FPGA on a 16 bit memory interface will work

Some chip support a transparent mode where you do a memory read/write
which gets translated to a Quad SPI access, or a NAND flash controller
access.

I.E:
You can write to a register over SPI by:
FPGA_REGISTER = value;
instead of

spi_packet = {
.cmd = SPI_WRITE,
.addr = FPGA_REGISTER,
.size = sizeof(value),
.data = &value
}
spi_transfer(&spi_packet);


We plan to use Yocto for developing Linux, so any Yocto solution
would be appreciated.

Looking forward to ideas.

AP

I am not familiar with modules (i.e. boards) that contain an ARM and an FPGA unless they are in the same devices which you have an unstated reason to avoid. Care you share the rational for not using those obvious solutions?

You don't indicate what your outline size requirements are. Would you consider a daughter board mounted on something like a Beagle board? What sort of quantities would you be expecting to buy?


We will do a base board, for which we need a CPU+FPGA module, so no
adding two boards together.

We are looking for an existing board for some prototyping.
Not having someone design it for us. A few boards will be OK.


if you only need a few for prototyping why does it matter if it
is stacked boards?


It will be mounted on a low volume test board, to test the functionality
outside the module. There is a maximum height restriction.
The real motherboard can have a different module connector.

if you are doing a board anyway just put the FPGA on that


Not going to happen.

Please everyone.
I know what I plan to do and I am not going to explain why.

I want a CPU module.
That CPU module has those restrictions I have mentioned.

That means
* no Zync
* No SoC
* no FPGA outside the module
* no CPU outside the module
* Not two PCBs
* No Marvell CPU, No CPU which is not delivered by NXP,TI, or MicroChip.
* No SPI interface between CPU and FPGA.
* Not anything that will deviate from what I described so far.

AP


Guest

Wed Jan 30, 2019 9:45 pm   



onsdag den 30. januar 2019 kl. 20.35.51 UTC+1 skrev A.P.Richelieu:
Quote:
Den 2019-01-30 kl. 20:27, skrev lasselangwadtchristensen_at_gmail.com:
onsdag den 30. januar 2019 kl. 19.28.43 UTC+1 skrev A.P.Richelieu:
Den 2019-01-30 kl. 18:28, skrev gnuarm.deletethisbit_at_gmail.com:
On Wednesday, January 30, 2019 at 12:13:34 PM UTC-5, A.P.Richelieu wrote:
Is there any ARM + FPGA CPU Module running linux using any of:

* NXP i.MX6/7/...
* Texas Instrument Sitara AM335x or better
* Microchip SAMA5
* Renesas RZ/xxx

It needs to be connected to a low price FPGA, Intel or Xilinx.

* Zynq or Intel SoC solutions need not apply.

Other vendors will be difficult to accept.

=====================

The CPU Module needs at least
* 128 MB RAM
* 128 MB Flash.
Connector will have
* 100 Mbps Ethernet
* 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
* 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
* SD-Card
* A few custom protocol LVDS channels
=====================
The processor has to be connected to an FPGA on a suitable
interface providing 5-10 MB/second transfer rate.
The FPGA needs to have 80-100 free I/O, not including the
interface to the CPU to implement SPIs, UARTs and other custom signals
=====================
The CPU should be able to load the FPGA after reset.
Preferably right after loading the U-Boot (during the BOOTDELAY timer).
=====================
Preferably, the processor should be able to access the internals
of the FPGA like it was on the memory bus.

Putting the FPGA on a 16 bit memory interface will work

Some chip support a transparent mode where you do a memory read/write
which gets translated to a Quad SPI access, or a NAND flash controller
access.

I.E:
You can write to a register over SPI by:
FPGA_REGISTER = value;
instead of

spi_packet = {
.cmd = SPI_WRITE,
.addr = FPGA_REGISTER,
.size = sizeof(value),
.data = &value
}
spi_transfer(&spi_packet);


We plan to use Yocto for developing Linux, so any Yocto solution
would be appreciated.

Looking forward to ideas.

AP

I am not familiar with modules (i.e. boards) that contain an ARM and an FPGA unless they are in the same devices which you have an unstated reason to avoid. Care you share the rational for not using those obvious solutions?

You don't indicate what your outline size requirements are. Would you consider a daughter board mounted on something like a Beagle board? What sort of quantities would you be expecting to buy?


We will do a base board, for which we need a CPU+FPGA module, so no
adding two boards together.

We are looking for an existing board for some prototyping.
Not having someone design it for us. A few boards will be OK.


if you only need a few for prototyping why does it matter if it
is stacked boards?


It will be mounted on a low volume test board, to test the functionality
outside the module. There is a maximum height restriction.
The real motherboard can have a different module connector.


if you are doing a board anyway just put the FPGA on that


Guest

Wed Jan 30, 2019 10:45 pm   



onsdag den 30. januar 2019 kl. 21.33.14 UTC+1 skrev A.P.Richelieu:
Quote:
Den 2019-01-30 kl. 21:05, skrev lasselangwadtchristensen_at_gmail.com:
onsdag den 30. januar 2019 kl. 20.35.51 UTC+1 skrev A.P.Richelieu:
Den 2019-01-30 kl. 20:27, skrev lasselangwadtchristensen_at_gmail.com:
onsdag den 30. januar 2019 kl. 19.28.43 UTC+1 skrev A.P.Richelieu:
Den 2019-01-30 kl. 18:28, skrev gnuarm.deletethisbit_at_gmail.com:
On Wednesday, January 30, 2019 at 12:13:34 PM UTC-5, A.P.Richelieu wrote:
Is there any ARM + FPGA CPU Module running linux using any of:

* NXP i.MX6/7/...
* Texas Instrument Sitara AM335x or better
* Microchip SAMA5
* Renesas RZ/xxx

It needs to be connected to a low price FPGA, Intel or Xilinx.

* Zynq or Intel SoC solutions need not apply.

Other vendors will be difficult to accept.

=====================

The CPU Module needs at least
* 128 MB RAM
* 128 MB Flash.
Connector will have
* 100 Mbps Ethernet
* 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
* 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
* SD-Card
* A few custom protocol LVDS channels
=====================
The processor has to be connected to an FPGA on a suitable
interface providing 5-10 MB/second transfer rate.
The FPGA needs to have 80-100 free I/O, not including the
interface to the CPU to implement SPIs, UARTs and other custom signals
=====================
The CPU should be able to load the FPGA after reset.
Preferably right after loading the U-Boot (during the BOOTDELAY timer).
=====================
Preferably, the processor should be able to access the internals
of the FPGA like it was on the memory bus.

Putting the FPGA on a 16 bit memory interface will work

Some chip support a transparent mode where you do a memory read/write
which gets translated to a Quad SPI access, or a NAND flash controller
access.

I.E:
You can write to a register over SPI by:
FPGA_REGISTER = value;
instead of

spi_packet = {
.cmd = SPI_WRITE,
.addr = FPGA_REGISTER,
.size = sizeof(value),
.data = &value
}
spi_transfer(&spi_packet);


We plan to use Yocto for developing Linux, so any Yocto solution
would be appreciated.

Looking forward to ideas.

AP

I am not familiar with modules (i.e. boards) that contain an ARM and an FPGA unless they are in the same devices which you have an unstated reason to avoid. Care you share the rational for not using those obvious solutions?

You don't indicate what your outline size requirements are. Would you consider a daughter board mounted on something like a Beagle board? What sort of quantities would you be expecting to buy?


We will do a base board, for which we need a CPU+FPGA module, so no
adding two boards together.

We are looking for an existing board for some prototyping.
Not having someone design it for us. A few boards will be OK.


if you only need a few for prototyping why does it matter if it
is stacked boards?


It will be mounted on a low volume test board, to test the functionality
outside the module. There is a maximum height restriction.
The real motherboard can have a different module connector.

if you are doing a board anyway just put the FPGA on that


Not going to happen.

Please everyone.
I know what I plan to do and I am not going to explain why.


so you are firmly committed to a plan that involves a board you can't
find and might not even exist

best of luck

Joe Chisolm
Guest

Wed Jan 30, 2019 10:45 pm   



On Wed, 30 Jan 2019 20:27:03 +0100, A.P.Richelieu wrote:

Quote:
Den 2019-01-30 kl. 20:18, skrev Joe Chisolm:
On Wed, 30 Jan 2019 18:13:26 +0100, A.P.Richelieu wrote:

Is there any ARM + FPGA CPU Module running linux using any of:

* NXP i.MX6/7/...
* Texas Instrument Sitara AM335x or better * Microchip SAMA5 * Renesas
RZ/xxx

It needs to be connected to a low price FPGA, Intel or Xilinx.

* Zynq or Intel SoC solutions need not apply.

Other vendors will be difficult to accept.

=====================

The CPU Module needs at least * 128 MB RAM * 128 MB Flash.
Connector will have * 100 Mbps Ethernet * 12 x 10 Mbps SPI channels
(most will be implemented in the FPGA)
* 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
* SD-Card * A few custom protocol LVDS channels =====================
The processor has to be connected to an FPGA on a suitable interface
providing 5-10 MB/second transfer rate.
The FPGA needs to have 80-100 free I/O, not including the interface to
the CPU to implement SPIs, UARTs and other custom signals
=====================
The CPU should be able to load the FPGA after reset.
Preferably right after loading the U-Boot (during the BOOTDELAY
timer).
=====================
Preferably, the processor should be able to access the internals of
the FPGA like it was on the memory bus.

Putting the FPGA on a 16 bit memory interface will work

Some chip support a transparent mode where you do a memory read/write
which gets translated to a Quad SPI access, or a NAND flash controller
access.

I.E:
You can write to a register over SPI by:
FPGA_REGISTER = value;
instead of

spi_packet = {
.cmd = SPI_WRITE, .addr = FPGA_REGISTER,
.size = sizeof(value),
.data = &value
}
spi_transfer(&spi_packet);


We plan to use Yocto for developing Linux, so any Yocto solution would
be appreciated.

Looking forward to ideas.

AP

Goggle cpu module with fpga you will get lots of hits

A couple that might work http://www.myirtech.com/list.asp?id=583
https://www.embeddedarm.com/products/TS-4740





Thanks, but the myirtech uses the Zync, and the TS-4740 uses a Marvell
CPU.

This might work:
http://teso.rs/arm-fpga-platforms.php

NXP ARM Cortex-A5 with Cortex-M controllers and an 80 MHz memory bus to
an Artix-7


It will be interesting to see what they think "low cost" is. Please post
back here if you get a price from them.

Quote:

The AM335x CPU on the Beagleon with an FPGA on a module would be better,
since that is a preferred chip.

AP


--
Chisolm
Republic of Texas

A.P.Richelieu
Guest

Wed Jan 30, 2019 11:45 pm   



Den 2019-01-30 kl. 22:31, skrev lasselangwadtchristensen_at_gmail.com:
Quote:
onsdag den 30. januar 2019 kl. 21.33.14 UTC+1 skrev A.P.Richelieu:
Den 2019-01-30 kl. 21:05, skrev lasselangwadtchristensen_at_gmail.com:
onsdag den 30. januar 2019 kl. 20.35.51 UTC+1 skrev A.P.Richelieu:
Den 2019-01-30 kl. 20:27, skrev lasselangwadtchristensen_at_gmail.com:
onsdag den 30. januar 2019 kl. 19.28.43 UTC+1 skrev A.P.Richelieu:
Den 2019-01-30 kl. 18:28, skrev gnuarm.deletethisbit_at_gmail.com:
On Wednesday, January 30, 2019 at 12:13:34 PM UTC-5, A.P.Richelieu wrote:
Is there any ARM + FPGA CPU Module running linux using any of:

* NXP i.MX6/7/...
* Texas Instrument Sitara AM335x or better
* Microchip SAMA5
* Renesas RZ/xxx

It needs to be connected to a low price FPGA, Intel or Xilinx.

* Zynq or Intel SoC solutions need not apply.

Other vendors will be difficult to accept.

=====================

The CPU Module needs at least
* 128 MB RAM
* 128 MB Flash.
Connector will have
* 100 Mbps Ethernet
* 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
* 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
* SD-Card
* A few custom protocol LVDS channels
=====================
The processor has to be connected to an FPGA on a suitable
interface providing 5-10 MB/second transfer rate.
The FPGA needs to have 80-100 free I/O, not including the
interface to the CPU to implement SPIs, UARTs and other custom signals
=====================
The CPU should be able to load the FPGA after reset.
Preferably right after loading the U-Boot (during the BOOTDELAY timer).
=====================
Preferably, the processor should be able to access the internals
of the FPGA like it was on the memory bus.

Putting the FPGA on a 16 bit memory interface will work

Some chip support a transparent mode where you do a memory read/write
which gets translated to a Quad SPI access, or a NAND flash controller
access.

I.E:
You can write to a register over SPI by:
FPGA_REGISTER = value;
instead of

spi_packet = {
.cmd = SPI_WRITE,
.addr = FPGA_REGISTER,
.size = sizeof(value),
.data = &value
}
spi_transfer(&spi_packet);


We plan to use Yocto for developing Linux, so any Yocto solution
would be appreciated.

Looking forward to ideas.

AP

I am not familiar with modules (i.e. boards) that contain an ARM and an FPGA unless they are in the same devices which you have an unstated reason to avoid. Care you share the rational for not using those obvious solutions?

You don't indicate what your outline size requirements are. Would you consider a daughter board mounted on something like a Beagle board? What sort of quantities would you be expecting to buy?


We will do a base board, for which we need a CPU+FPGA module, so no
adding two boards together.

We are looking for an existing board for some prototyping.
Not having someone design it for us. A few boards will be OK.


if you only need a few for prototyping why does it matter if it
is stacked boards?


It will be mounted on a low volume test board, to test the functionality
outside the module. There is a maximum height restriction.
The real motherboard can have a different module connector.

if you are doing a board anyway just put the FPGA on that


Not going to happen.

Please everyone.
I know what I plan to do and I am not going to explain why.

so you are firmly committed to a plan that involves a board you can't
find and might not even exist


If we cannot find the module, then we will design it ourselves.
Right now, I prefer getting something which is as close
to our final solution as possible, but fits from a physical point of view.

AP

Quote:

best of luck


Theo
Guest

Thu Jan 31, 2019 1:25 pm   



A.P.Richelieu <aprichelieu_at_gmail.com> wrote:
Quote:
You are trying to convince me to look at Zynq and SoC.
That is what I explicitly said I was not going to do.


No, I'm pointing out that your argument on costs doesn't necessarily stack
up.

The reason why the options are so constrained, and why this doesn't exist as
a popular product, is that not many Linux-capable CPUs have an external bus
interface or a high bandwidth GPIO interface. Basically you're stuck with
PCIe (which ups the FPGA cost a lot) or things with SPI to try and squeeze
enough bandwidth out.

Things like the OMAP PRUs might do it, but I'm not sure what useful
bandwidth you can get at the end of the day (since there's no help with the
wire protocol, you have to do it all in software).

That leaves the options as roughly:

- Zynq/Intel SoC parts (on-chip FPGA)
- some Microsemi parts with a hard Cortex M (not Linux capable)
- OMAP PRU
- I think I saw a single iMX part with an external bus interface, but it was
slow
- an FPGA with a soft core running Linux (Microblaze, NIOS-II, RISC-V of
some kind). These have a myriad of sharp edges, as the
core/kernel/drivers/compiler/distro is often not very polished
- PCIe
- a few parts (eg Cavium ThunderX) which expose the cache coherency protocol
externally. You'd be very much on your own here.

Another horrible idea: write a NAND flash interface for the FPGA and use
that to emulate an external bus interface. You'd have to disentangle
whatever cleverness the CPU's NAND controller tries to do, but in principle
the bandwidth is there.

Basically you've boxed yourself into a corner here, so all these options are
not very appealing.

Theo

Anssi Saari
Guest

Fri Feb 01, 2019 2:45 pm   



Theo <theom+news_at_chiark.greenend.org.uk> writes:

Quote:
gnuarm.deletethisbit_at_gmail.com wrote:
I was thinking about his bandwidth requirement. While you say there
aren't many ARMs running Linux with external memory interfaces (which
makes me wonder how they build all those Beagle Bones, etc.)

There are external DDR3 / NAND flash / (E)MMC / QSPI interfaces, but nothing
that looks like a regular bus. You can pretend to be a flash chip, but it
isn't very pleasant.

An SoC with a NOR flash interface would be easiest, but I haven't seen one
of those for a while. Not that I've been looking for one, I admit.


I did find one, only checked what AP listed. Turns out Atmel nee
Microchip has ARM processors with SRAM-like external memory interfaces
in the SAMA5 family. I don't know if it's fast or easy to use from a
software point of view.

A Belgian company has apparently designed a router based on one of
these,
http://dab-embedded.com/en/cases/openwrt-atmel-sama5d3-and-max10-fpga-board/

It has an FPGA (Intel's Max 10) connected to the ARM via this external
memory interface.

A.P.Richelieu
Guest

Fri Feb 01, 2019 8:45 pm   



Den 2019-02-01 kl. 14:18, skrev Anssi Saari:
Quote:
Theo <theom+news_at_chiark.greenend.org.uk> writes:

gnuarm.deletethisbit_at_gmail.com wrote:
I was thinking about his bandwidth requirement. While you say there
aren't many ARMs running Linux with external memory interfaces (which
makes me wonder how they build all those Beagle Bones, etc.)

There are external DDR3 / NAND flash / (E)MMC / QSPI interfaces, but nothing
that looks like a regular bus. You can pretend to be a flash chip, but it
isn't very pleasant.

An SoC with a NOR flash interface would be easiest, but I haven't seen one
of those for a while. Not that I've been looking for one, I admit.

I did find one, only checked what AP listed. Turns out Atmel nee
Microchip has ARM processors with SRAM-like external memory interfaces
in the SAMA5 family. I don't know if it's fast or easy to use from a
software point of view.

A Belgian company has apparently designed a router based on one of
these,
http://dab-embedded.com/en/cases/openwrt-atmel-sama5d3-and-max10-fpga-board/

It has an FPGA (Intel's Max 10) connected to the ARM via this external
memory interface.


Thank You.
That is the type of answer I am looking for.
The Max 10, is most likely too small.
Cyclone 10, Spartan 6 or better in terms of logic.
Need internal SRAM for buffers as well.
No need for Gigabit transceivers though.

AP.

A.P.Richelieu
Guest

Fri Feb 01, 2019 8:45 pm   



Den 2019-01-31 kl. 22:47, skrev Theo:
Quote:
gnuarm.deletethisbit_at_gmail.com wrote:
I was thinking about his bandwidth requirement. While you say there
aren't many ARMs running Linux with external memory interfaces (which
makes me wonder how they build all those Beagle Bones, etc.)

There are external DDR3 / NAND flash / (E)MMC / QSPI interfaces, but nothing
that looks like a regular bus. You can pretend to be a flash chip, but it
isn't very pleasant.

An SoC with a NOR flash interface would be easiest, but I haven't seen one
of those for a while. Not that I've been looking for one, I admit.


The AM335x on the Beaglebone has two buses. One for DDR3 memory,
and then a second bus which can either be
* A normal non-multiplexed bus A[2x..0], D[15..0]
* A Multiplexed bus with A[2x..16], AD[15:0]
* A double Multiplexed bus with AAD[15:0].
The Adress is sent over two cycles.
Unfortunately, one of the write strobes is in conflict with a
peripheral I need, so I can only do word access, not byte access to
the FPGA.

Quote:

wouldn't an Ethernet interface at 100 Mbps do the job? Ok, I guess you'd
need two since the OP wants one for other use. Are there any ARM CPUs
with TWO Ethernet interfaces?

Plenty of them, but we are not going to run Ethernet to the FPGA...
I doubt a CPU module would do that as well.

Quote:
Yes, this something we do - use point-to-point (switchless) ethernet as
essentially a bit-pipe, with the MAC at each end doing minimal framing.

It would, I suppose, be plausible to implement a minimal ethernet switch in
the FPGA - FPGA has one ethernet MAC/PHY hardwired to the ARM SoC, another on
the output, and a piece of FPGA logic pulls off packets to/from a magic MAC
address that are going to the internal logic.

An existing board that does this is Microsoft's Catapult - FPGA logic that
sits on both PCIe and interposes between the in-box 40G NIC and the rack
switch. Of a completely different league of course, and you can't buy the
boards.

I don't have latency numbers for our 10G ethernet approach, but it might be
OK if you have enough space for buffering.

I can't think of an off the shelf board wired in this configuration though.

Theo

AP


A.P.Richelieu
Guest

Fri Feb 01, 2019 8:45 pm   



Den 2019-01-31 kl. 12:25, skrev Theo:
Quote:
A.P.Richelieu <aprichelieu_at_gmail.com> wrote:
You are trying to convince me to look at Zynq and SoC.
That is what I explicitly said I was not going to do.

No, I'm pointing out that your argument on costs doesn't necessarily stack
up.

The reason why the options are so constrained, and why this doesn't exist as
a popular product, is that not many Linux-capable CPUs have an external bus
interface or a high bandwidth GPIO interface. Basically you're stuck with
PCIe (which ups the FPGA cost a lot) or things with SPI to try and squeeze
enough bandwidth out.

Things like the OMAP PRUs might do it, but I'm not sure what useful
bandwidth you can get at the end of the day (since there's no help with the
wire protocol, you have to do it all in software).

That leaves the options as roughly:

- Zynq/Intel SoC parts (on-chip FPGA)
- some Microsemi parts with a hard Cortex M (not Linux capable)
- OMAP PRU
- I think I saw a single iMX part with an external bus interface, but it was
slow
- an FPGA with a soft core running Linux (Microblaze, NIOS-II, RISC-V of
some kind). These have a myriad of sharp edges, as the
core/kernel/drivers/compiler/distro is often not very polished
- PCIe
- a few parts (eg Cavium ThunderX) which expose the cache coherency protocol
externally. You'd be very much on your own here.

Another horrible idea: write a NAND flash interface for the FPGA and use
that to emulate an external bus interface. You'd have to disentangle
whatever cleverness the CPU's NAND controller tries to do, but in principle
the bandwidth is there.


I need 5-10 MByte per second, which I do not see as a problem if I
design a module myself.
I have found three acceptable ways of interfacing the FPGA.

1. A separate 8/16 bit memory bus
2. NAND Flash interface
3. QSPI interface which is memory mapped. You write to the Address
range, and the H/W will generate an SPI read or write access
automatically.

There are several parts which has a Memory Bus and a Secondary bus,
and that is useful.
That includes the AM335x, AM437x, AM65x, SAMA5, Renesas RZ/xxx and some
NXP iMX parts.
The AMxxxx until the AM65xx has deficiencies we do not like, but the
AM65xx is just sampling. Might be too late.

I am pretty sure however, I can do the job with a simple ARM9 and a NAND
flash interface to the FPGA.

So there are plenty of options.

Quote:
Basically you've boxed yourself into a corner here, so all these options are
not very appealing.

There are no corners. Any CPU from the list above combined with an FPGA
is probably useable (we prefer something else than Renesas though)

AP

Quote:
Theo


A.P.Richelieu
Guest

Fri Feb 01, 2019 9:45 pm   



Den 2019-01-31 kl. 22:57, skrev lasselangwadtchristensen_at_gmail.com:
Quote:
torsdag den 31. januar 2019 kl. 17.47.23 UTC+1 skrev gnuarm.del...@gmail.com:
On Thursday, January 31, 2019 at 6:25:32 AM UTC-5, Theo wrote:
A.P.Richelieu <aprichelieu_at_gmail.com> wrote:
You are trying to convince me to look at Zynq and SoC.
That is what I explicitly said I was not going to do.

No, I'm pointing out that your argument on costs doesn't necessarily stack
up.

The reason why the options are so constrained, and why this doesn't exist as
a popular product, is that not many Linux-capable CPUs have an external bus
interface or a high bandwidth GPIO interface. Basically you're stuck with
PCIe (which ups the FPGA cost a lot) or things with SPI to try and squeeze
enough bandwidth out.

Things like the OMAP PRUs might do it, but I'm not sure what useful
bandwidth you can get at the end of the day (since there's no help with the
wire protocol, you have to do it all in software).

That leaves the options as roughly:

- Zynq/Intel SoC parts (on-chip FPGA)
- some Microsemi parts with a hard Cortex M (not Linux capable)
- OMAP PRU
- I think I saw a single iMX part with an external bus interface, but it was
slow
- an FPGA with a soft core running Linux (Microblaze, NIOS-II, RISC-V of
some kind). These have a myriad of sharp edges, as the
core/kernel/drivers/compiler/distro is often not very polished
- PCIe
- a few parts (eg Cavium ThunderX) which expose the cache coherency protocol
externally. You'd be very much on your own here.

Another horrible idea: write a NAND flash interface for the FPGA and use
that to emulate an external bus interface. You'd have to disentangle
whatever cleverness the CPU's NAND controller tries to do, but in principle
the bandwidth is there.

Basically you've boxed yourself into a corner here, so all these options are
not very appealing.

I was thinking about his bandwidth requirement. While you say there aren't many ARMs running Linux with external memory interfaces (which makes me wonder how they build all those Beagle Bones, etc.)

they "all" have external memory but it is dedicated for DDR RAM, some of them, like the beagle bone also have a general purpose memory interface controller for things like sync and async RAM and FLASH, that's the one you'd want to use for an FPGA, and some do: https://elinux.org/BeagleBoard/BeagleWire



That is more like it, unfortunately, it is not a single module, and the
Lattice FPGA is not on the accepted list.

Might look at it for some homebrew stuff though.
AP.

A.P.Richelieu
Guest

Fri Feb 01, 2019 9:45 pm   



Den 2019-01-31 kl. 16:00, skrev kkoorndyk:
Quote:
On Wednesday, January 30, 2019 at 1:21:30 PM UTC-5, A.P.Richelieu wrote:
Den 2019-01-30 kl. 18:44, skrev lasselangwadtchristensen_at_gmail.com:
onsdag den 30. januar 2019 kl. 18.13.34 UTC+1 skrev A.P.Richelieu:
Is there any ARM + FPGA CPU Module running linux using any of:

* NXP i.MX6/7/...
* Texas Instrument Sitara AM335x or better
* Microchip SAMA5
* Renesas RZ/xxx

It needs to be connected to a low price FPGA, Intel or Xilinx.

* Zynq or Intel SoC solutions need not apply.

Other vendors will be difficult to accept.

=====================

The CPU Module needs at least
* 128 MB RAM
* 128 MB Flash.
Connector will have
* 100 Mbps Ethernet
* 12 x 10 Mbps SPI channels (most will be implemented in the FPGA)
* 5 x 921,200 BAUD serial ports (some in FPGA perhaps)
* SD-Card
* A few custom protocol LVDS channels
=====================
The processor has to be connected to an FPGA on a suitable
interface providing 5-10 MB/second transfer rate.
The FPGA needs to have 80-100 free I/O, not including the
interface to the CPU to implement SPIs, UARTs and other custom signals
=====================
The CPU should be able to load the FPGA after reset.
Preferably right after loading the U-Boot (during the BOOTDELAY timer).
=====================
Preferably, the processor should be able to access the internals
of the FPGA like it was on the memory bus.

Putting the FPGA on a 16 bit memory interface will work

Some chip support a transparent mode where you do a memory read/write
which gets translated to a Quad SPI access, or a NAND flash controller
access.

I.E:
You can write to a register over SPI by:
FPGA_REGISTER = value;
instead of

spi_packet = {
.cmd = SPI_WRITE,
.addr = FPGA_REGISTER,
.size = sizeof(value),
.data = &value
}
spi_transfer(&spi_packet);


We plan to use Yocto for developing Linux, so any Yocto solution
would be appreciated.

Looking forward to ideas.

AP

why not Zynq? it has everything you ask for and the same ARM-9 as the NXP


Because it is way too expensive.

You can get a better ARM chip for $6-7 in 1k qty.
A Cyclone 10 FPGA is $8-9.
Can You get a Zynq for $14-16 in 1k volume?
Digikey shows one off pricing for the cheapest Zynq to be $46.
If they can give 40% discount at 1k, it is still $30 = 2x price.


Another thing is that the onboard peripherals generally suck.
At least when I looked at them the last time.
I do not care to waste my time on why.

This means that we have to spend time doing peripherals in the FPGA.
They need to be supported by Linux drivers.
We do not want to add that development effort.

AP

If you're purchasing in the 1000+ qty annually, you should NOT be using Digikey for pricing. That should be a negotiation with your Avent rep. In higher volumes, I've seen pretty significant prices negotiated for our customers.

You mentioned in a more recent response that you use Zynqs in other products, so you might consider trying to design in common parts to increase your total corporate purchase qty of the same part to help negotiate better prices.



We know what the Zynq is all about and it has been rejected for this
project.
You don't have access to all our decision criteria,
but you are free to beat a dead horse if you want to.

AP


Guest

Sat Feb 02, 2019 4:45 am   



Not much of a thread really. Some guy demanding that others here do his work for him while being a bit surly about questions he considers irrelevant.

I guess beggars can't be choosers. This conversation is still better than religious tirades. c.a.f is pretty light on topics these days.


Rick C.

-+ Get 6 months of free supercharging
-+ Tesla referral code - https://ts.la/richard11209

A.P.Richelieu
Guest

Sat Feb 02, 2019 6:45 am   



Den 2019-02-02 kl. 04:27, skrev gnuarm.deletethisbit_at_gmail.com:
Quote:
Not much of a thread really. Some guy demanding that others here do his work for him while being a bit surly about questions he considers irrelevant.

I guess beggars can't be choosers. This conversation is still better than religious tirades. c.a.f is pretty light on topics these days.


I specify already in my first entry what I am looking for.
I also specify what I am not looking for.

And no, I am not asking anyone to do work for me.
I am asking people to share knowledge which they might have.
That is what Newsgroups are for.

You expect me to be pleased when anyone comes with a suggestion
which directly violates the small list of requirements,
and starts nagging, when I explain that things like the Zynq
has been rejected.

There are other reasons than I mentioned why the Zynq
is rejected, but those reasons are not for public knowledge.
AP

Quote:
Rick C.

-+ Get 6 months of free supercharging
-+ Tesla referral code - https://ts.la/richard11209



Guest

Sat Feb 02, 2019 6:45 am   



On Friday, February 1, 2019 at 11:54:58 PM UTC-5, A.P.Richelieu wrote:
Quote:
Den 2019-02-02 kl. 04:27, skrev gnuarm.deletethisbit_at_gmail.com:
Not much of a thread really. Some guy demanding that others here do his work for him while being a bit surly about questions he considers irrelevant.

I guess beggars can't be choosers. This conversation is still better than religious tirades. c.a.f is pretty light on topics these days.


I specify already in my first entry what I am looking for.
I also specify what I am not looking for.

And no, I am not asking anyone to do work for me.
I am asking people to share knowledge which they might have.
That is what Newsgroups are for.

You expect me to be pleased when anyone comes with a suggestion
which directly violates the small list of requirements,
and starts nagging, when I explain that things like the Zynq
has been rejected.


No one expects you to like anything. You just come across as rude. I'm not sure what you expected of this thread. If your tone had been a bit more pleasant and willing to discuss things rather than sounding very irritated, the thread would have been more interesting to read and participate in.

When someone offers a suggestion you don't like, it is perfectly acceptable to not respond at all rather than berate them. Like this one. Rather than come back with more rudeness, you could have just ignored the post. I suppose I am be a bit clueless, thinking that my post will have any impact. People on the Internet are what they are. Silly to expect them to be any different on such a limited medium.

BTW, you might try asking on comp.arch.embedded. Since the board you are looking for is as much CPU as FPGA their might be more knowledge of the available modules in that group.


Rick C.

+- Tesla referral code - https://ts.la/richard11209

Goto page Previous  1, 2, 3  Next

elektroda.net NewsGroups Forum Index - FPGA - ARM + FPGA CPU Module running Yocto Linux?

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map