On 2019-06-15 14:14, Michael Kellett wrote:> So fast for me, for the applications I have in mind is: > > round trip < 1us (less than 50ns preferred) - easy to do with FPGA > memory mapped to uP and pretending to be a RAM - but I don't see how > to do it on a Pi. Sustained data transfer rate > 100MiB per second > in both directions simultaneously.100 MiB as in 100 Mi Bytes (rather than bits) per second, full duplex? That does not look realistic without some high speed serial interface. As the rPi does not provide any, maybe other similar boards: - ROCKPro64 (with Rockchip RK3399 SoC) has a PCIe x4 port - Banana Pi M2 (with Allwinner R40 SoC) has a SATA port PCIe x4 should easily do it, even when not using all those 4 lanes. SATA might be somewhat tricky from the controller side, but it can work if the FPGA target can emulate a block device. Depending on controller capabilities, this could mean mostly half-duplex transfers however. That would require SATA 2 with 3 Gb/s minimum (SATA 1 with 1.5Gb/s would be enough if the bulk transfers are full duplex).
bare-metal ZYNQ
Started by ●June 12, 2019
Reply by ●June 15, 20192019-06-15
Reply by ●June 15, 20192019-06-15
As others mentioned: there is 256kByte OCM on Zynq. I assume you want configure the device from flash. Step 1: FSBL Step 2: start u-boot (with fpga configuration support) Step 3: configure u-boot to configure the fpga Step 4: let u-boot load and start your bare metal application Bart Fox
Reply by ●June 16, 20192019-06-16
On 15/06/2019 13:45, Jan Panteltje wrote:> On a sunny day (Sat, 15 Jun 2019 13:14:27 +0100) it happened Michael Kellett > <mk@mkesc.co.uk> wrote in <TOWdnRE_0_exfJnAnZ2dnUU78e_NnZ2d@giganews.com>: > >> On 14/06/2019 10:44, Jan Panteltje wrote: >>> On a sunny day (Fri, 14 Jun 2019 09:11:36 +0100) it happened Michael Kellett >>> <mk@mkesc.co.uk> wrote in <98SdnfMZpZZdy57AnZ2dnUU78LXNnZ2d@giganews.com>: >>> >>>> Jan - do you know of a good, simple and fast way to get the Pi to >>>> exchange data with an adjacent chip (uP or FPGA). >>> >>> >>> >>> Sure, first for FPGA there is this: >>> http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/RaspberryPiFPGA >>> this connects via GPIO. >>> >>> I notice a lot more big names have now FPGA stuff for raspberry.. >>> Just google 'raspberry FPGA board;. >>> >>> >>> Depending on your definition of 'fast' with a micro, >>> the Pi had logic level RS232 via /dev/ttyAMA0, >>> also hardware SPI (or software SPI of course), i2c the same. >>> >>> Here used as a a large LED matrix display driver: >>> http://panteltje.com/panteltje/raspberry_pi_FDS132_matrix_display_driver/index.html >>> >>> >>> You can also use 8 bits from GPIO and do byte level transfers, >>> a typical example of 'fast' is this: >>> http://panteltje.com/panteltje/raspberry_pi_dvb-s_transmitter/ >>> that also uses a FIFO hardware buffer to get a smooth timed data stream >>> even during OS task switching. >>> >>> 8 bits (or more) transfer with handshake will work with most micros. >>> >>> Here the Pi as JTAG programmer: >>> http://panteltje.com/panteltje/raspberry_pi/ >>> >>> Stepper motor driver, lots of other i2c chips.. >>> http://panteltje.com/panteltje/xgpspc/index.html >>> >>> >>>> Using USB or Ethernet >>>> doesn't count as simple (or very fast for small data packets.) >>> >>> USB is slow on my older Raspberries at least, ethernet is OK. >>> I would prefer ethernet in some applications because of the galvanic isolation. >>> >>> What is simple? >>> Everything is simple once you have dunnit. >>> >> >> Thanks for the stuff Jan, I don't think I explained quite what I meant >> by fast (although I did say that Ethernet wasn't fast enough). >> >> So fast for me, for the applications I have in mind is: >> >> round trip < 1us (less than 50ns preferred) - easy to do with FPGA >> memory mapped to uP and pretending to be a RAM - but I don't see how to >> do it on a Pi. >> Sustained data transfer rate > 100MiB per second in both directions >> simultaneously. >> >> You can do this kind of stuff with the Prus on the Beagleboards but it >> would be nice if it were possible on a Pi. >> >> Simple means (in this context) not using lots of other fancy chips over >> and above the FPGA and not needing to use a GHz serial interface. >> (although if the PI had one spare that I don't know about I might have a >> go.) >> >> I had wondered if the the camera or audio interfaces might be re-purposed. >> >> MK > > Audio I do not think is usable for that, but who knows... > AFAIK the camera interface is from camera to board, so one way. > What I meant is if you have 8 or more GPIO pins, say a byte > then there is nothing stopping you from putting a byte on that, > and use a pin as handshake 'new data'. > FPGA would read the handshake and read the byte, and then set a ready pin, > Pi would then output he next byte, > Now you have 10 pins and maximum I/O speed. > Same for 16 bits 18 pins. > The throughput problems is set by the Pi Linux multitasker, it will > interrupt the stream every now and then for a few milliseconds at least, > That is where you need the FIFO. > But that FIFO can be in FPGA RAM, no external logic needed as I do here: > http://panteltje.com/panteltje/raspberry_pi_dvb-s_transmitter/ > I did consider doing that in FPGA, but that seemed a bit of overkill in this case. > > So then maximum speed boils down to hwo fast the Pi can output data really.. > have not tested that, as I never was close to that limit. > It is simple to test, write some I/O pin toggle routine in asm, or even C, > and look at the scope. > loop: > out 0x00 > out 0xff > goto loop > > Pi has DMA, have not used it myself, here some discussion: > https://www.raspberrypi.org/forums/viewtopic.php?t�76 > > Maybe this is of more use to you: > https://github.com/hzeller/rpi-gpio-dma-demo > > They did the pin toggle and: > <quote> > The resulting output wave on the Raspberry Pi 1 of 22.7Mhz, the Raspberry Pi 2 reaches 41.7Mhz and the Raspberry Pi 3 65.8 Mhz. >> end quote> > > Fast enough? >Thanks Jan, The toggle rate is quite good but the downside of using software controlled IO is that at least 1 core is 100% occupied. For things that don't need the full rate and can be block processed it would do. MK --- This email has been checked for viruses by AVG. https://www.avg.com
Reply by ●June 16, 20192019-06-16
On 15/06/2019 14:26, Tom Gardner wrote:> On 15/06/19 13:14, Michael Kellett wrote: >> On 14/06/2019 10:44, Jan Panteltje wrote: >>> On a sunny day (Fri, 14 Jun 2019 09:11:36 +0100) it happened Michael >>> Kellett >>> <mk@mkesc.co.uk> wrote in >>> <98SdnfMZpZZdy57AnZ2dnUU78LXNnZ2d@giganews.com>: >>> >>>> Jan - do you know of a good, simple and fast way to get the Pi to >>>> exchange data with an adjacent chip (uP or FPGA). >>> >>> >>> >>> Sure, first for FPGA there is this: >>> >>> http://www.latticesemi.com/en/Products/DevelopmentBoardsAndKits/RaspberryPiFPGA >>> >>> this connects via GPIO. >>> >>> I notice a lot more big names have now FPGA stuff for raspberry.. >>> � Just google 'raspberry FPGA board;. >>> >>> >>> Depending on your definition of 'fast' with a micro, >>> the Pi had logic level RS232 via /dev/ttyAMA0, >>> also hardware SPI (or software SPI of course), i2c the same. >>> >>> Here used as a a large LED matrix display driver: >>> http://panteltje.com/panteltje/raspberry_pi_FDS132_matrix_display_driver/index.html >>> >>> >>> >>> You can also use 8 bits from GPIO and do byte level transfers, >>> a typical example of 'fast' is this: >>> � http://panteltje.com/panteltje/raspberry_pi_dvb-s_transmitter/ >>> that also uses a FIFO hardware buffer to get a smooth timed data stream >>> even during OS task switching. >>> >>> 8 bits (or more) transfer with handshake will work with most micros. >>> >>> Here the Pi as JTAG programmer: >>> � http://panteltje.com/panteltje/raspberry_pi/ >>> >>> Stepper motor driver, lots of other i2c chips.. >>> � http://panteltje.com/panteltje/xgpspc/index.html >>> >>> >>>> Using USB or Ethernet >>>> doesn't count as simple (or very fast for small data packets.) >>> >>> USB is slow on my older Raspberries at least, ethernet is OK. >>> I would prefer ethernet in some applications because of the galvanic >>> isolation. >>> >>> What is simple? >>> Everything is simple once you have dunnit. >>> >> >> Thanks for the stuff Jan, I don't think I explained quite what I meant >> by fast (although I did say that Ethernet wasn't fast enough). >> >> So fast for me, for the applications I have in mind is: >> >> round trip < 1us (less than 50ns preferred) - easy to do with FPGA >> memory mapped to uP and pretending to be a RAM - but I don't see how >> to do it on a Pi. >> Sustained data transfer rate > 100MiB per second in both directions >> simultaneously. > > You could do that on the XMOS xCORE devices. They are > fast enough to take the 100Mb/s serial ethernet traffic, > and process it in software. *And* be doing other things > at the same time, guaranteed by design (not tests!) :) > > The IDE states the maximum timing between two points, > e.g. two i/o operations, or loop times. That's possible > since there are no caches, no interrupts, and the > latency is <100ns (much less in my experience). > > > >> You can do this kind of stuff with the Prus on the Beagleboards but it >> would be nice if it were possible on a Pi. >> >> Simple means (in this context) not using lots of other fancy chips >> over and above the FPGA and not needing to use a GHz serial interface. >> (although if the PI had one spare that I don't know about I might have >> a go.) > > The xCORE i/o is very nice, easy to use, and is > similar to FPGAs in flexibility (e.g. SERDES, > or strobes, or...) > > >> I had wondered if the the camera or audio interfaces might be >> re-purposed.Thanks for the suggestion. My problem isn't in getting the FPGA to jump through the hoops but in getting the PI or similar Linux running platform to transfer data to it. The Xmos parts could (sometimes) replace the FPGA but not the Linux end. MK --- This email has been checked for viruses by AVG. https://www.avg.com
Reply by ●June 16, 20192019-06-16
On 15/06/2019 19:19, Dimitrij Klingbeil wrote:> On 2019-06-15 14:14, Michael Kellett wrote: > >> So fast for me, for the applications I have in mind is: >> >> round trip < 1us (less than 50ns preferred) - easy to do with FPGA >> memory mapped to uP and pretending to be a RAM - but I don't see how >> �to do it on a Pi. Sustained data transfer rate > 100MiB per second >> in both directions simultaneously. > > 100 MiB as in 100 Mi Bytes (rather than bits) per second, full duplex? > > That does not look realistic without some high speed serial interface. > > As the rPi does not provide any, maybe other similar boards: > > - ROCKPro64 (with Rockchip RK3399 SoC) has a PCIe x4 port > - Banana Pi M2 (with Allwinner R40 SoC) has a SATA port > > PCIe x4 should easily do it, even when not using all those 4 lanes. > > SATA might be somewhat tricky from the controller side, but it can work > if the FPGA target can emulate a block device. > > Depending on controller capabilities, this could mean mostly half-duplex > transfers however. That would require SATA 2 with 3 Gb/s minimum (SATA 1 > with 1.5Gb/s would be enough if the bulk transfers are full duplex).100 mega bytes per second is quite feasible locally (on board) with // 8 bit bus - I've had less trouble getting 1Gbit ethernet PHYs to talk to FPGAs using // connections than serial. The great thing about the Zynq is that the // interface is on chip rather than on board so almost easy. The downside is that an RPi is so much cheaper. An RPI with a free PCie port and OS support - that would be nice. MK --- This email has been checked for viruses by AVG. https://www.avg.com
Reply by ●June 16, 20192019-06-16
On 16/06/19 09:56, Michael Kellett wrote:> My problem isn't in getting the FPGA to jump through the hoops but in getting > the PI or similar Linux running platform to transfer data to it. The Xmos parts > could (sometimes) replace the FPGA but not the Linux end.Exactly so. xCORE/xC are unique and in an interesting niche, but like all other technologies they are not The General Solution. But it is fun trying to (and succeeding) in mixing-and-matching technologies to work around each's limitations :)
