Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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
--
Chisolm
Republic of Texas
Article: 161076
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
The AM335x CPU on the Beagleon with an FPGA on a module would be better,
since that is a preferred chip.
AP
Article: 161077
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@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?
Article: 161078Den 2019-01-30 kl. 19:53, skrev Gerhard Hoffmann: > Am 30.01.19 um 19:21 schrieb A.P.Richelieu: >> Den 2019-01-30 kl. 18:44, skrev lasselangwadtchristensen@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 >>>> > > The BeagleBoneBlack has at least a 16 bit multiplexed data bus, even > when it shares pins with other stuff. > There is also the integrated solution from Octavo Systems. Beaglebone with eMMC and DDR3 SDRAM + Power in a 400 pin BGA. Adding an FPGA to that, with a high speed bus: Yum, Yum... AP > I'm looking into that because I want a FPGA that has support > for some JESDI204B lanes to connect to some contemporary ADCs and DACs. > > And on-chip CPUs have been a royal pain from Power-PC to Picoblaze. > I like it when I know that at least my Linux runs stable, so bugs > must be in user land or the hardware - and not in my driver that > kills my ssh access. > > It found it quite OK to run the time-critical stuff on a PRU and > just hand the Linux-ARM the time-decoupled data via shared buffers. > There is a C compiler for the PRUs in the standard BBB Linux distribution. > > regards, > GerhardArticle: 161079
Den 2019-01-30 kl. 20:27, skrev lasselangwadtchristensen@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@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.
AP
Article: 161080
onsdag den 30. januar 2019 kl. 20.35.51 UTC+1 skrev A.P.Richelieu:
> Den 2019-01-30 kl. 20:27, skrev lasselangwadtchristensen@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@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
Article: 161081
Den 2019-01-30 kl. 21:05, skrev lasselangwadtchristensen@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@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@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
Article: 161082
onsdag den 30. januar 2019 kl. 21.33.14 UTC+1 skrev A.P.Richelieu:
> Den 2019-01-30 kl. 21:05, skrev lasselangwadtchristensen@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@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@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
Article: 161083
On Wed, 30 Jan 2019 20:27:03 +0100, A.P.Richelieu wrote:
> 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.
>
> 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
Article: 161084
Den 2019-01-30 kl. 22:31, skrev lasselangwadtchristensen@gmail.com:
> onsdag den 30. januar 2019 kl. 21.33.14 UTC+1 skrev A.P.Richelieu:
>> Den 2019-01-30 kl. 21:05, skrev lasselangwadtchristensen@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@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@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
>
> best of luck
>
Article: 161085Hello, I'm looking for a Xilinx Artix-7 SoM (or board..) with at-least 8 x GTP transceivers , preferably 16 , exposed to the connector. Any pointers will be much appreciated. Thanks !Article: 161086
On Wednesday, January 30, 2019 at 11:14:26 AM UTC-6, gnuarm.del...@gmail.co= m wrote: > On Wednesday, January 30, 2019 at 11:24:17 AM UTC-5, kkoorndyk wrote: > > On Tuesday, January 29, 2019 at 7:57:05 PM UTC-5, gnuarm.del...@gmail.c= om wrote: > > > On Monday, January 28, 2019 at 10:49:32 AM UTC-5, kkoorndyk wrote: > > > You may as well take the opportunity to "future proof" the design by = migrating to another vendor that isn't likely to get acquired or axed. Xil= inx has the single core Zynq-7000 devices if you want to go with a more mai= n-stream, ARM processor sub-system (although likely overkill for whatever y= our Nios is doing). Otherwise, the Artix-7 and Spartan-7 would be good tar= gets if you want to migrate to a Microblaze or some other soft core. The S= partan-7 family is essentially the Artix-7 fabric with the transcievers rem= oved and are offered in 6K to 100K logic cell densities. > > >=20 > > > I don't think you actually got my point. Moving to a Spartan by usin= g a MicroBlaze processor isn't "future proofing" anything. It is just shif= ting from one brand to another with the exact same problems. =20 > > >=20 > > > If you want to future proof a soft CPU design you need to drop any FP= GA company in-house processor and use an open source processor design. The= n you can use any FPGA you wish. =20 > > >=20 > > > Here is some info on the J1, an open source processor that was used t= o replace a microblaze when it became unequal to the task at hand. =20 > > >=20 > > > http://www.forth.org/svfig/kk/11-2010-Bowman.pdf > > >=20 > > > http://www.excamera.com/sphinx/fpga-j1.html > > >=20 > > > http://www.excamera.com/files/j1.pdf > > >=20 > > >=20 > > > Rick C. > > >=20 > > > -- Get 6 months of free supercharging > > > -- Tesla referral code - https://ts.la/richard11209 > >=20 > > No, I got your point perfectly, hence the following part of my recommen= dation: "or some other soft core." >=20 > I am making the point that porting from one proprietary processor to anot= her is of limited value. Microblaze is proprietary. I believe there may b= e some open source versions available, but I expect there are open source v= ersions of the NIOS available as well. But perhaps more importantly, they = are far from optimal. That's why I posted the info on the J1 processor. I= t was invented to replace a Microblaze that wasn't up to the task. =20 >=20 >=20 > > If the original Nios was employed, I'm not entirely convinced a soft co= re is necessary (yet). How simple is the software running on it? Can it r= easonably be ported to HDL, thus ensuring portability? I tend to lean that= way unless the SW was simple due to capability limitations in the earlier = technologies (e.g., old Cyclone and Nios) and the desire is to add more fea= tures that are realizable with new generation devices and soft (or hard) co= re capabilities. >=20 > Sometimes soft CPUs are added to reduce the size of logic. Other times t= hey are added because of the complexity of expression. Regardless of how s= imply we can write HDL, the large part of the engineering world perceives H= DL as much more complex than other languages and are not willing to port co= de to an HDL unless absolutely required. So if the code is currently in C,= it won't get ported to HDL without a compelling reason.=20 >=20 > Personally I think Xilinx and Altera are responsible for the present perc= eption that FPGAs are difficult to use, expensive, large and power hungry. = That is largely true if you use their products only. Lattice has been add= ressing a newer market with small, low power, inexpensive devices intended = for the mobile market. Now if someone would approach the issue of ease of = use by something more than throwing an IDE on top of their command line too= ls, the FPGA market can explode into territory presently dominated by MCUs.= =20 >=20 > Does anyone really think toasters can only be controlled by MCUs? We jus= t need a cheap enough FPGA in a suitable package. =20 >=20 >=20 > Rick C. >=20 > +- Get 6 months of free supercharging > +- Tesla referral code - https://ts.la/richard11209 ]>Microblaze is proprietary. I believe there may be some open source versi= ons available, but I expect there are open source versions of the NIOS avai= lable as well. Microblaze clones: aeMB, an-noc-mpsoc, mblite, mb-lite-plus, myblaze, openf= ire_core, openfire2, secretblaze No NIOS clones that I know of ]>But perhaps more importantly, they are far from optimal. Ugh, they have some of the best figure-of-merit numbers available. (Instructions per second per LUT) And are available in many configuration options. There are a large variety of RISC-V cores available some of which have low = LUT counts. Jim BrakefieldArticle: 161087
On Wednesday, January 30, 2019 at 7:42:54 PM UTC-5, jim.bra...@ieee.org wro= te: > On Wednesday, January 30, 2019 at 11:14:26 AM UTC-6, gnuarm.del...@gmail.= com wrote: > > On Wednesday, January 30, 2019 at 11:24:17 AM UTC-5, kkoorndyk wrote: > > > On Tuesday, January 29, 2019 at 7:57:05 PM UTC-5, gnuarm.del...@gmail= .com wrote: > > > > On Monday, January 28, 2019 at 10:49:32 AM UTC-5, kkoorndyk wrote: > > > > You may as well take the opportunity to "future proof" the design b= y migrating to another vendor that isn't likely to get acquired or axed. X= ilinx has the single core Zynq-7000 devices if you want to go with a more m= ain-stream, ARM processor sub-system (although likely overkill for whatever= your Nios is doing). Otherwise, the Artix-7 and Spartan-7 would be good t= argets if you want to migrate to a Microblaze or some other soft core. The= Spartan-7 family is essentially the Artix-7 fabric with the transcievers r= emoved and are offered in 6K to 100K logic cell densities. > > > >=20 > > > > I don't think you actually got my point. Moving to a Spartan by us= ing a MicroBlaze processor isn't "future proofing" anything. It is just sh= ifting from one brand to another with the exact same problems. =20 > > > >=20 > > > > If you want to future proof a soft CPU design you need to drop any = FPGA company in-house processor and use an open source processor design. T= hen you can use any FPGA you wish. =20 > > > >=20 > > > > Here is some info on the J1, an open source processor that was used= to replace a microblaze when it became unequal to the task at hand. =20 > > > >=20 > > > > http://www.forth.org/svfig/kk/11-2010-Bowman.pdf > > > >=20 > > > > http://www.excamera.com/sphinx/fpga-j1.html > > > >=20 > > > > http://www.excamera.com/files/j1.pdf > > > >=20 > > > >=20 > > > > Rick C. > > > >=20 > > > > -- Get 6 months of free supercharging > > > > -- Tesla referral code - https://ts.la/richard11209 > > >=20 > > > No, I got your point perfectly, hence the following part of my recomm= endation: "or some other soft core." > >=20 > > I am making the point that porting from one proprietary processor to an= other is of limited value. Microblaze is proprietary. I believe there may= be some open source versions available, but I expect there are open source= versions of the NIOS available as well. But perhaps more importantly, the= y are far from optimal. That's why I posted the info on the J1 processor. = It was invented to replace a Microblaze that wasn't up to the task. =20 > >=20 > >=20 > > > If the original Nios was employed, I'm not entirely convinced a soft = core is necessary (yet). How simple is the software running on it? Can it= reasonably be ported to HDL, thus ensuring portability? I tend to lean th= at way unless the SW was simple due to capability limitations in the earlie= r technologies (e.g., old Cyclone and Nios) and the desire is to add more f= eatures that are realizable with new generation devices and soft (or hard) = core capabilities. > >=20 > > Sometimes soft CPUs are added to reduce the size of logic. Other times= they are added because of the complexity of expression. Regardless of how= simply we can write HDL, the large part of the engineering world perceives= HDL as much more complex than other languages and are not willing to port = code to an HDL unless absolutely required. So if the code is currently in = C, it won't get ported to HDL without a compelling reason.=20 > >=20 > > Personally I think Xilinx and Altera are responsible for the present pe= rception that FPGAs are difficult to use, expensive, large and power hungry= . That is largely true if you use their products only. Lattice has been a= ddressing a newer market with small, low power, inexpensive devices intende= d for the mobile market. Now if someone would approach the issue of ease o= f use by something more than throwing an IDE on top of their command line t= ools, the FPGA market can explode into territory presently dominated by MCU= s. =20 > >=20 > > Does anyone really think toasters can only be controlled by MCUs? We j= ust need a cheap enough FPGA in a suitable package. =20 > >=20 > >=20 > > Rick C. > >=20 > > +- Get 6 months of free supercharging > > +- Tesla referral code - https://ts.la/richard11209 >=20 > ]>Microblaze is proprietary. I believe there may be some open source ver= sions available, but I expect there are open source versions of the NIOS av= ailable as well. >=20 > Microblaze clones: aeMB, an-noc-mpsoc, mblite, mb-lite-plus, myblaze, ope= nfire_core, openfire2, secretblaze >=20 > No NIOS clones that I know of >=20 > ]>But perhaps more importantly, they are far from optimal. > Ugh, they have some of the best figure-of-merit numbers available. > (Instructions per second per LUT) > And are available in many configuration options. >=20 > There are a large variety of RISC-V cores available some of which have lo= w LUT counts. >=20 > Jim Brakefield Not sure what figures you are talking about. Has anyone compiled a compari= son? =20 Rick C. ++ Get 6 months of free supercharging ++ Tesla referral code - https://ts.la/richard11209Article: 161088
On Wednesday, January 30, 2019 at 7:37:56 PM UTC-6, gnuarm.del...@gmail.com= wrote: > On Wednesday, January 30, 2019 at 7:42:54 PM UTC-5, jim.bra...@ieee.org w= rote: > > On Wednesday, January 30, 2019 at 11:14:26 AM UTC-6, gnuarm.del...@gmai= l.com wrote: > > > On Wednesday, January 30, 2019 at 11:24:17 AM UTC-5, kkoorndyk wrote: > > > > On Tuesday, January 29, 2019 at 7:57:05 PM UTC-5, gnuarm.del...@gma= il.com wrote: > > > > > On Monday, January 28, 2019 at 10:49:32 AM UTC-5, kkoorndyk wrote= : > > > > > You may as well take the opportunity to "future proof" the design= by migrating to another vendor that isn't likely to get acquired or axed. = Xilinx has the single core Zynq-7000 devices if you want to go with a more= main-stream, ARM processor sub-system (although likely overkill for whatev= er your Nios is doing). Otherwise, the Artix-7 and Spartan-7 would be good= targets if you want to migrate to a Microblaze or some other soft core. T= he Spartan-7 family is essentially the Artix-7 fabric with the transcievers= removed and are offered in 6K to 100K logic cell densities. > > > > >=20 > > > > > I don't think you actually got my point. Moving to a Spartan by = using a MicroBlaze processor isn't "future proofing" anything. It is just = shifting from one brand to another with the exact same problems. =20 > > > > >=20 > > > > > If you want to future proof a soft CPU design you need to drop an= y FPGA company in-house processor and use an open source processor design. = Then you can use any FPGA you wish. =20 > > > > >=20 > > > > > Here is some info on the J1, an open source processor that was us= ed to replace a microblaze when it became unequal to the task at hand. =20 > > > > >=20 > > > > > http://www.forth.org/svfig/kk/11-2010-Bowman.pdf > > > > >=20 > > > > > http://www.excamera.com/sphinx/fpga-j1.html > > > > >=20 > > > > > http://www.excamera.com/files/j1.pdf > > > > >=20 > > > > >=20 > > > > > Rick C. > > > > >=20 > > > > > -- Get 6 months of free supercharging > > > > > -- Tesla referral code - https://ts.la/richard11209 > > > >=20 > > > > No, I got your point perfectly, hence the following part of my reco= mmendation: "or some other soft core." > > >=20 > > > I am making the point that porting from one proprietary processor to = another is of limited value. Microblaze is proprietary. I believe there m= ay be some open source versions available, but I expect there are open sour= ce versions of the NIOS available as well. But perhaps more importantly, t= hey are far from optimal. That's why I posted the info on the J1 processor= . It was invented to replace a Microblaze that wasn't up to the task. =20 > > >=20 > > >=20 > > > > If the original Nios was employed, I'm not entirely convinced a sof= t core is necessary (yet). How simple is the software running on it? Can = it reasonably be ported to HDL, thus ensuring portability? I tend to lean = that way unless the SW was simple due to capability limitations in the earl= ier technologies (e.g., old Cyclone and Nios) and the desire is to add more= features that are realizable with new generation devices and soft (or hard= ) core capabilities. > > >=20 > > > Sometimes soft CPUs are added to reduce the size of logic. Other tim= es they are added because of the complexity of expression. Regardless of h= ow simply we can write HDL, the large part of the engineering world perceiv= es HDL as much more complex than other languages and are not willing to por= t code to an HDL unless absolutely required. So if the code is currently i= n C, it won't get ported to HDL without a compelling reason.=20 > > >=20 > > > Personally I think Xilinx and Altera are responsible for the present = perception that FPGAs are difficult to use, expensive, large and power hung= ry. That is largely true if you use their products only. Lattice has been= addressing a newer market with small, low power, inexpensive devices inten= ded for the mobile market. Now if someone would approach the issue of ease= of use by something more than throwing an IDE on top of their command line= tools, the FPGA market can explode into territory presently dominated by M= CUs. =20 > > >=20 > > > Does anyone really think toasters can only be controlled by MCUs? We= just need a cheap enough FPGA in a suitable package. =20 > > >=20 > > >=20 > > > Rick C. > > >=20 > > > +- Get 6 months of free supercharging > > > +- Tesla referral code - https://ts.la/richard11209 > >=20 > > ]>Microblaze is proprietary. I believe there may be some open source v= ersions available, but I expect there are open source versions of the NIOS = available as well. > >=20 > > Microblaze clones: aeMB, an-noc-mpsoc, mblite, mb-lite-plus, myblaze, o= penfire_core, openfire2, secretblaze > >=20 > > No NIOS clones that I know of > >=20 > > ]>But perhaps more importantly, they are far from optimal. > > Ugh, they have some of the best figure-of-merit numbers available. > > (Instructions per second per LUT) > > And are available in many configuration options. > >=20 > > There are a large variety of RISC-V cores available some of which have = low LUT counts. > >=20 > > Jim Brakefield >=20 > Not sure what figures you are talking about. Has anyone compiled a compa= rison? =20 >=20 >=20 > Rick C. >=20 > ++ Get 6 months of free supercharging > ++ Tesla referral code - https://ts.la/richard11209 Altera/Intel: "Nios II Performance Benchmarks Xilinx: appendix of MicroBlaze Processor Reference GuideArticle: 161089
On Wednesday, January 30, 2019 at 8:56:28 PM UTC-5, jim.bra...@ieee.org wrote: > On Wednesday, January 30, 2019 at 7:37:56 PM UTC-6, gnuarm.del...@gmail.com wrote: > > On Wednesday, January 30, 2019 at 7:42:54 PM UTC-5, jim.bra...@ieee.org wrote: > > > On Wednesday, January 30, 2019 at 11:14:26 AM UTC-6, gnuarm.del...@gmail.com wrote: > > > > > > ]>Microblaze is proprietary. I believe there may be some open source versions available, but I expect there are open source versions of the NIOS available as well. > > > > > > Microblaze clones: aeMB, an-noc-mpsoc, mblite, mb-lite-plus, myblaze, openfire_core, openfire2, secretblaze > > > > > > No NIOS clones that I know of > > > > > > ]>But perhaps more importantly, they are far from optimal. > > > Ugh, they have some of the best figure-of-merit numbers available. > > > (Instructions per second per LUT) > > > And are available in many configuration options. > > > > > > There are a large variety of RISC-V cores available some of which have low LUT counts. > > > > > > Jim Brakefield > > > > Not sure what figures you are talking about. Has anyone compiled a comparison? > > > > > > Rick C. > > > > ++ Get 6 months of free supercharging > > ++ Tesla referral code - https://ts.la/richard11209 > > Altera/Intel: "Nios II Performance Benchmarks > Xilinx: appendix of MicroBlaze Processor Reference Guide Not sure what these are about. They certainly don't compare third party implementations of their architectures. Rick C. --- Get 6 months of free supercharging --- Tesla referral code - https://ts.la/richard11209Article: 161090
Am 31.01.19 um 01:42 schrieb jim.brakefield@ieee.org: > On Wednesday, January 30, 2019 at 11:14:26 AM UTC-6, gnuarm.del...@gmail.com wrote: >> On Wednesday, January 30, 2019 at 11:24:17 AM UTC-5, kkoorndyk wrote: > > ]>Microblaze is proprietary. I believe there may be some open source versions available, but I expect there are open source versions of the NIOS available as well. > > Microblaze clones: aeMB, an-noc-mpsoc, mblite, mb-lite-plus, myblaze, openfire_core, openfire2, secretblaze Proprietary maybe; when the re-implementation is clean, it's OK. You might also have to re-implement the assembler & C-compiler for license reasons. I once have changed the register implementation of a PICO-blaze. That was not too hard. Its VHDL representation is compiled with the rest of your FPGA circuit. The problem was, we used picoblazes in an ORIGINAL dinosaur Virtex in a space application, and we had to scrubb the configuration memory every minute or so. That means reloading the configuration memory to fight accumulation of bad bits due to radiation etc. It works just like booting the FPGA at powerup - and killing this process one clock before the before the global reset happens! The icing on the cake was that the reload circuitry was in the FPGA itself. That's much like exchanging the carpet under your feet. I have witten a nice package of triple module redundant standard logic vectors for that, and for other sensitive processing. tmr_sl and tmr_slv could be used almost like standard_logic and the peculiarities were carefully hidden, like avoiding that the ISE proudly optimizes the redundancy away. The Xilinx TMR tool was unavailable for European space projects because of ITER. :-( (Maybe I should do an open source re-implementation in modern VHDL as a WARM THANK YOU. I know now how to make it even better and we could make tamagotchis for the children of Fukushima.) But I disgress. The reason for the picoblaze modification was that picoblaze uses CLB rams for its registers and these are really snippets of the configuration RAM. So, during each scrubbing of the configuration the CPU forgets its register contents. Replacing the rams with arrays of flip-flops increased the resource consumption but it was _not_ much slower. best regards, Gerhard Hoffmann Consulting: ANALOG, RF and DSP Design.Article: 161091
A.P.Richelieu <aprichelieu@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. TheoArticle: 161092
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@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.
Article: 161093On Thursday, January 31, 2019 at 6:25:32 AM UTC-5, Theo wrote: > A.P.Richelieu <aprichelieu@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. >=20 > No, I'm pointing out that your argument on costs doesn't necessarily stac= k > up. >=20 > 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 b= us > interface or a high bandwidth GPIO interface. Basically you're stuck wit= h > PCIe (which ups the FPGA cost a lot) or things with SPI to try and squeez= e > enough bandwidth out. >=20 > 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 t= he > wire protocol, you have to do it all in software). >=20 > That leaves the options as roughly: >=20 > - 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 proto= col > externally. You'd be very much on your own here. >=20 > 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 princip= le > the bandwidth is there. >=20 > 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 wo= nder how they build all those Beagle Bones, etc.) wouldn't an Ethernet inte= rface at 100 Mbps do the job? Ok, I guess you'd need two since the OP want= s one for other use. Are there any ARM CPUs with TWO Ethernet interfaces?= =20 Rick C. -- Get 6 months of free supercharging -- Tesla referral code - https://ts.la/richard11209Article: 161094
gnuarm.deletethisbit@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. > 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? 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. TheoArticle: 161095
torsdag den 31. januar 2019 kl. 17.47.23 UTC+1 skrev gnuarm.del...@gmail.co= m: > On Thursday, January 31, 2019 at 6:25:32 AM UTC-5, Theo wrote: > > A.P.Richelieu <aprichelieu@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. > >=20 > > No, I'm pointing out that your argument on costs doesn't necessarily st= ack > > up. > >=20 > > The reason why the options are so constrained, and why this doesn't exi= st 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 w= ith > > PCIe (which ups the FPGA cost a lot) or things with SPI to try and sque= eze > > enough bandwidth out. > >=20 > > 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). > >=20 > > That leaves the options as roughly: > >=20 > > - 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 i= t was > > slow > > - an FPGA with a soft core running Linux (Microblaze, NIOS-II, RISC-V o= f > > 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 pro= tocol > > externally. You'd be very much on your own here. > >=20 > > Another horrible idea: write a NAND flash interface for the FPGA and us= e > > that to emulate an external bus interface. You'd have to disentangle > > whatever cleverness the CPU's NAND controller tries to do, but in princ= iple > > the bandwidth is there. > >=20 > > Basically you've boxed yourself into a corner here, so all these option= s are > > not very appealing. >=20 > 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 th= em, like the beagle bone also have a general purpose memory interface contr= oller for things like sync and async RAM and FLASH, that's the one you'd wa= nt to use for an FPGA, and some do: https://elinux.org/BeagleBoard/BeagleWi= re=20Article: 161096
Theo <theom+news@chiark.greenend.org.uk> writes: > gnuarm.deletethisbit@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.Article: 161097
Den 2019-01-31 kl. 12:25, skrev Theo:
> A.P.Richelieu <aprichelieu@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.
> 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
> Theo
>
Article: 161098Den 2019-01-31 kl. 22:47, skrev Theo: > gnuarm.deletethisbit@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. > >> 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. > 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 > APArticle: 161099
Den 2019-02-01 kl. 14:18, skrev Anssi Saari: > Theo <theom+news@chiark.greenend.org.uk> writes: > >> gnuarm.deletethisbit@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.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z