bare-metal ZYNQ

[Phil Hobbs]

On 6/14/19 1:15 PM, Rick C wrote:

On Friday, June 14, 2019 at 5:44:58 AM UTC-4, Jan Panteltje wrote:

What is simple? Everything is simple once you have dunnit.

I worked at a company where I designed a board with a Xilinx FPGA on
it. This company had a separate FPGA group under software. The
software and FPGA people were trying to boot the FPGA and couldn't
make it work. My boss told me to go down and help them.

When I got there there was an FPGA guy who had been a disti FAE for
Xilinx before this job, his newbie FPGA person, a much more senior
FPGA consultant, a manager and a software guy writing the code to
download the chip. I had to rather butt my way in to get them to
talk to me rationally since there was a certain level of frustration
at this point.

I told them there was a short list of things you had to do right to
get the chip configured and there would be no symptoms to tell you
what was wrong. So do those few things right and it will give you a
DONE flag and work. We went through the list and they said they had
tried all of those things... I asked if they had done them all at
one time. They hadn't... so they did them all together and it
worked. I asked if that was everything they needed, they said yes so
I left. The manager was flat out floored that I had fixed it so
quickly. But anyone who had actually worked at the board level to
configure a Xilinx part would have known this.

So the whole group, including the former Xilinx FAE had never
actually brought up a board before.

Later the software guy made a huge stink because of the 100 kHz noise
on the output of the class-D amplifier. In reality his voice
compression wasn't working and he never even tried running a simple
audio output to test that everything other than the vocoder was
working.

People who haven't done much find very simple things complicated.

I tend to regard things I learned long ago as being simple, even when
they aren't. I have to watch that tendency when explaining things.

Cheers

Phil Hobbs

(Who is working on how to explain things to a jury in 10 days or so.)

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

 

[Michael Kellett]

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



---
This email has been checked for viruses by AVG.
https://www.avg.com

 

[Jan Panteltje]

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=8376

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?

 

[Tom Gardner]

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.

 

[Dimitrij Klingbeil]

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

 

[Michael Kellett]

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

 

[Michael Kellett]

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

 

[Michael Kellett]

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=8376

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

 

[Tom Gardner]

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