bare-metal ZYNQ

On a sunny day (Sat, 15 Jun 2019 13:14:27 +0100) it happened Michael Kellett wrote in :

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:

formatting link
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:

formatting link

Maybe this is of more use to you:

formatting link

They did the pin toggle and: 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.

Fast enough?

Reply to
Jan Panteltje
Loading thread data ...

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 You can do this kind of stuff with the Prus on the Beagleboards but it would be

The xCORE i/o is very nice, easy to use, and is similar to FPGAs in flexibility (e.g. SERDES, or strobes, or...)

Reply to
Tom Gardner

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).

Reply to
Dimitrij Klingbeil

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 to
Michael Kellett

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 to
Michael Kellett

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 to
Michael Kellett

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 :)

Reply to
Tom Gardner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.