Forums

microZed adventures

Started by John Larkin November 22, 2013

We're into this signal processing project, using a microZed/ZYNQ thing as the
compute engine.

After a week or so of work by an FPGA guy and a programmer, we can now actually
read and write an FPGA register from a C program, and wiggle a bit on a
connector pin. Amazingly, the uZed eval kit does not include a demo of this, and
the default boot image does not configure the FPGA!

We're using their build tools to embed the FPGA config into the boot image. We'd
really like to be able to have a C program read a bitstream file and reconfigure
the FPGA, but we haven't been able to figure that out.

If we run a C program that wiggles a pin as fast as it can, we can do a write to
the FPGA register about every 170 ns. Without any attempts at optimization (like
dedicating the second ARM core to the loop) we see stutters (OS stealing our
CPU) that last tens or hundreds of microseconds, occasionally a full
millisecond. That might get worse if we run TCP/IP sessions or host web pages or
something, so dedicating the second ARM to realtime stuff would be good.


-- 

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME  analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
On a sunny day (Fri, 22 Nov 2013 08:57:12 -0800) it happened John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in
<jj2v8997iq6amci40mr1t2g5l2e040ojgu@4ax.com>:

>We're into this signal processing project, using a microZed/ZYNQ thing as the >compute engine. > >After a week or so of work by an FPGA guy and a programmer, we can now actually >read and write an FPGA register from a C program, and wiggle a bit on a >connector pin. Amazingly, the uZed eval kit does not include a demo of this, and >the default boot image does not configure the FPGA! > >We're using their build tools to embed the FPGA config into the boot image. We'd >really like to be able to have a C program read a bitstream file and reconfigure >the FPGA, but we haven't been able to figure that out. > >If we run a C program that wiggles a pin as fast as it can, we can do a write to >the FPGA register about every 170 ns. Without any attempts at optimization (like >dedicating the second ARM core to the loop) we see stutters (OS stealing our >CPU) that last tens or hundreds of microseconds, occasionally a full >millisecond. That might get worse if we run TCP/IP sessions or host web pages or >something, so dedicating the second ARM to realtime stuff would be good.
In my view FPGA should be used for - or used as hardware solution. Putting a processor in a FPGA will work. and a multitasker will constantly see I?O interruped. use the procssor for what the processor is good for, and do the rest in hardware. If you want I/O speed... Or any speed. Else you are just building an other _slow_ mobo. and then may as well use this: http://www.bugblat.com/products/pif/ Without any defined spec for the application who knows? Ad Jim says: You are about as vague as it gets on that,
> If we run a C program that wiggles a pin as fast as it can, we can do a write to > the FPGA register about every 170 ns. Without any attempts at optimization (like > dedicating the second ARM core to the loop) we see stutters (OS stealing our > CPU) that last tens or hundreds of microseconds, occasionally a full > millisecond. That might get worse if we run TCP/IP sessions or host web pages or > something, so dedicating the second ARM to realtime stuff would be good.
That's only 5 to 6 MHz, which is really slow compare to the 800MHz clock. PIC32 can do at least 4 clock cycles, or 50MHz on a 200Mhz MZ.
On Fri, 22 Nov 2013 08:57:12 -0800, John Larkin wrote:

> We're into this signal processing project, using a microZed/ZYNQ thing > as the compute engine. > > After a week or so of work by an FPGA guy and a programmer, we can now > actually read and write an FPGA register from a C program, and wiggle a > bit on a connector pin. Amazingly, the uZed eval kit does not include a > demo of this, and the default boot image does not configure the FPGA! > > We're using their build tools to embed the FPGA config into the boot > image. We'd really like to be able to have a C program read a bitstream > file and reconfigure the FPGA, but we haven't been able to figure that > out. > > If we run a C program that wiggles a pin as fast as it can, we can do a > write to the FPGA register about every 170 ns. Without any attempts at > optimization (like dedicating the second ARM core to the loop) we see > stutters (OS stealing our CPU) that last tens or hundreds of > microseconds, occasionally a full millisecond. That might get worse if > we run TCP/IP sessions or host web pages or something, so dedicating the > second ARM to realtime stuff would be good.
There's not nearly enough information there, but if you're serious about real time you don't just throw a bag of unknown software at something and expect it to work. Operating systems don't steal CPU time -- programmers steal CPU time, sometimes by choosing the wrong OS. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On 11/22/2013 11:57 AM, John Larkin wrote:
> > > We're into this signal processing project, using a microZed/ZYNQ thing as the > compute engine. > > After a week or so of work by an FPGA guy and a programmer, we can now actually > read and write an FPGA register from a C program, and wiggle a bit on a > connector pin. Amazingly, the uZed eval kit does not include a demo of this, and > the default boot image does not configure the FPGA! > > We're using their build tools to embed the FPGA config into the boot image. We'd > really like to be able to have a C program read a bitstream file and reconfigure > the FPGA, but we haven't been able to figure that out. > > If we run a C program that wiggles a pin as fast as it can, we can do a write to > the FPGA register about every 170 ns. Without any attempts at optimization (like > dedicating the second ARM core to the loop) we see stutters (OS stealing our > CPU) that last tens or hundreds of microseconds, occasionally a full > millisecond. That might get worse if we run TCP/IP sessions or host web pages or > something, so dedicating the second ARM to realtime stuff would be good. > >
That is amazing, especially since so many manufacturers (*cough*ST*cough*) respond to any query by saying "Hack up the sample code." Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC Optics, Electro-optics, Photonics, Analog Electronics 160 North State Road #203 Briarcliff Manor NY 10510 hobbs at electrooptical dot net http://electrooptical.net
On Fri, 22 Nov 2013 08:57:12 -0800, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

> > >We're into this signal processing project, using a microZed/ZYNQ thing as the >compute engine. > >After a week or so of work by an FPGA guy and a programmer, we can now actually >read and write an FPGA register from a C program, and wiggle a bit on a >connector pin. Amazingly, the uZed eval kit does not include a demo of this, and >the default boot image does not configure the FPGA! > >We're using their build tools to embed the FPGA config into the boot image. We'd >really like to be able to have a C program read a bitstream file and reconfigure >the FPGA, but we haven't been able to figure that out. > >If we run a C program that wiggles a pin as fast as it can, we can do a write to >the FPGA register about every 170 ns. Without any attempts at optimization (like >dedicating the second ARM core to the loop) we see stutters (OS stealing our >CPU) that last tens or hundreds of microseconds, occasionally a full >millisecond. That might get worse if we run TCP/IP sessions or host web pages or >something, so dedicating the second ARM to realtime stuff would be good.
Hi, John:- What OS is it running? Can you set the granularity of the task switching to something reasonable like low double-digit microseconds? This is a very interesting chip, especially with a bit bigger FPGA than the 7010.
On Fri, 22 Nov 2013 17:35:52 GMT, Jan Panteltje
<pNaonStpealmtje@yahoo.com> wrote:

>On a sunny day (Fri, 22 Nov 2013 08:57:12 -0800) it happened John Larkin ><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in ><jj2v8997iq6amci40mr1t2g5l2e040ojgu@4ax.com>: > >>We're into this signal processing project, using a microZed/ZYNQ thing as the >>compute engine. >> >>After a week or so of work by an FPGA guy and a programmer, we can now actually >>read and write an FPGA register from a C program, and wiggle a bit on a >>connector pin. Amazingly, the uZed eval kit does not include a demo of this, and >>the default boot image does not configure the FPGA! >> >>We're using their build tools to embed the FPGA config into the boot image. We'd >>really like to be able to have a C program read a bitstream file and reconfigure >>the FPGA, but we haven't been able to figure that out. >> >>If we run a C program that wiggles a pin as fast as it can, we can do a write to >>the FPGA register about every 170 ns. Without any attempts at optimization (like >>dedicating the second ARM core to the loop) we see stutters (OS stealing our >>CPU) that last tens or hundreds of microseconds, occasionally a full >>millisecond. That might get worse if we run TCP/IP sessions or host web pages or >>something, so dedicating the second ARM to realtime stuff would be good. > >In my view FPGA should be used for - or used as hardware solution. >Putting a processor in a FPGA will work. and a multitasker will constantly see I?O interruped. >use the procssor for what the processor is good for, and do the rest in hardware. >If you want I/O speed... Or any speed. >Else you are just building an other _slow_ mobo. >and then may as well use this: > http://www.bugblat.com/products/pif/ > >Without any defined spec for the application who knows?
There is a perfectly good, detailed spec. You can't see it.
>Ad Jim says: You are about as vague as it gets on that,
I'm building a box that accepts an analog input, crunches it in complex ways, and makes an analog output. ZED is an ideal platform. All that nasty DRAM and flash and power supply stuff is done, and it boots Linux out of the box. Having the dual-core ARM and the FPGA on the same chip is cool, because it avoids a lot of interconnect between two chips on a board. Unfortunately, ARM-FPGA transactions still cross a clock boundary, so aren't blindingly fast. -- John Larkin Highland Technology, Inc jlarkin at highlandtechnology dot com http://www.highlandtechnology.com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser drivers and controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulation
On Fri, 22 Nov 2013 09:53:39 -0800 (PST), edward.ming.lee@gmail.com
wrote:

> >> If we run a C program that wiggles a pin as fast as it can, we can do a write to >> the FPGA register about every 170 ns. Without any attempts at optimization (like >> dedicating the second ARM core to the loop) we see stutters (OS stealing our >> CPU) that last tens or hundreds of microseconds, occasionally a full >> millisecond. That might get worse if we run TCP/IP sessions or host web pages or >> something, so dedicating the second ARM to realtime stuff would be good. > >That's only 5 to 6 MHz, which is really slow compare to the 800MHz clock. > >PIC32 can do at least 4 clock cycles, or 50MHz on a 200Mhz MZ.
Yes. Doing it the obvious way, using the internal whatever-they-call-it bus clocked at 100 MHz, it looks like we're crossing a clock boundary every ARM-to-FPGA read or write. 170 ns (17 clocks!) is OK now, but does waste a lot of cycles on an 800 MHz ARM. -- John Larkin Highland Technology, Inc jlarkin at highlandtechnology dot com http://www.highlandtechnology.com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser drivers and controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulation
On Fri, 22 Nov 2013 13:33:14 -0500, Spehro Pefhany wrote:

> On Fri, 22 Nov 2013 08:57:12 -0800, John Larkin > <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > > >> >>We're into this signal processing project, using a microZed/ZYNQ thing >>as the compute engine. >> >>After a week or so of work by an FPGA guy and a programmer, we can now >>actually read and write an FPGA register from a C program, and wiggle a >>bit on a connector pin. Amazingly, the uZed eval kit does not include a >>demo of this, and the default boot image does not configure the FPGA! >> >>We're using their build tools to embed the FPGA config into the boot >>image. We'd really like to be able to have a C program read a bitstream >>file and reconfigure the FPGA, but we haven't been able to figure that >>out. >> >>If we run a C program that wiggles a pin as fast as it can, we can do a >>write to the FPGA register about every 170 ns. Without any attempts at >>optimization (like dedicating the second ARM core to the loop) we see >>stutters (OS stealing our CPU) that last tens or hundreds of >>microseconds, occasionally a full millisecond. That might get worse if >>we run TCP/IP sessions or host web pages or something, so dedicating the >>second ARM to realtime stuff would be good. > > Hi, John:- > > What OS is it running? Can you set the granularity of the task switching > to something reasonable like low double-digit microseconds?
What programming model are you assuming? The RTOS's that I'm used to using make it very easy to make RTOS tasks event-driven off of interrupts, so the critical timing parameter for the OS is how rapidly it can reschedule a task after such an interrupt. Note that for every RTOS I've ever worked with, a programmer can cut the RTOS off at the knees by turning off interrupts and doing some lengthly process, or by doing lengthly processing in an ISR on a processor that automatically turns off interrupts on interrupt. No interrupts means the RTOS has no way of getting its hands on the processor. This "interrupt off" time can be essential if you have something that absolutely, positively must be done without interrupts, and it can be a valuable way to make an operation atomic if it happens to create less latency than using the OS's mutex scheme. But in the hands of a lazy programmer, it can absolutely kill real-time capability (as, for that matter, can misuse of mutexes or any number of other OS features). -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
> I'm building a box that accepts an analog input, crunches it in > complex ways, and makes an analog output. ZED is an ideal platform. > All that nasty DRAM and flash and power supply stuff is done, and it
But you still need external SDRAM with or without Linux. Quark or PIC32MZ both have 2M flash and 512K SRAM on-chip.
> boots Linux out of the box. Having the dual-core ARM and the FPGA on > the same chip is cool, because it avoids a lot of interconnect between > two chips on a board. Unfortunately, ARM-FPGA transactions still cross > a clock boundary, so aren't blindingly fast.
Yes, it's a AMBA problem. It's good for high volume data transfer, not for single bit.
> > > > > > -- > > > > John Larkin Highland Technology, Inc > > > > jlarkin at highlandtechnology dot com > > http://www.highlandtechnology.com > > > > Precision electronic instrumentation > > Picosecond-resolution Digital Delay and Pulse generators > > Custom laser drivers and controllers > > Photonics and fiberoptic TTL data links > > VME thermocouple, LVDT, synchro acquisition and simulation