microZed adventures

This is more true for desktop-y Linux than it is for embedded, but sometimes it pays to recompile the kernel and customize it to your needs. There are some choices in the scheduler that can be tweaked this way. This can also be a good way to get a kernel that just doesn't work at all, so make sure you have a way to go back to stock.

The kernel configuration for plain old x86 is pretty good about dependencies: if you turn on kernel feature X, it will tell you that you need to turn on Y and Z as well to get X to work, and maybe even do it for you. Linux for embedded CPUs varies - sometimes it's like x86, and sometimes there is precisely one (undocumented) combination of kernel build options that actually works. Sometimes the documentation exists, but it's on the wrong side of an E[STF]L barrier.

Back to your original point, sometimes the lack of sample code is down to the vendor being clueless. Sometimes there is another reason - if you get the hard sell for using their approved development partners, that's a hint.

taskset(1) from the command line if they gave you that, sched_setaffinity(2) if they didn't.

I am pretty sure that you can tell Linux at boot time to not use some of the cores, but I'm not sure how you would then get something else to run on the cores that Linux isn't suing.

I heard this too, and my objection (from the software side) was that in my experience, the hardware guys I worked with tended to be pretty bad at revision control for FPGAs. Part of this was down to the FPGA tools, and part of it was down to an "it's hardware and we'll never have to change it" attitude, so they wouldn't leave a way to update the soft core over the phone. I think I have ranted about this before. :)

I like the hard core idea better, as long as the stuff that runs on the hard core loads up like normal, and is not embedded in some huge binary blob puked out by the FPGA tools.

Matt Roberds

We got two from Avnet. Maybe luck, maybe they did it because we buy a lot of parts from tham.

That's about what we are seeing for 32-bit transfers.

We'll try that. By software guy mumbled about hearing something about that crashing Linux.

it is the simplest way, not the fastest it is not meant to be fast

ARM is many things, you cannot compare an ARM9 made to run a full desktop OS with a fast embedded MCU like cortex M4, they are meant for different things and excel in different things

an x86 can't toggle a gpio at 10MHz, but it runs calculations at GHz and have extreme data rates to the graphics card, ethernet etc.

toggle pins controlling the world and crunching data running a desktop it is two different things

-Lasse

Please remove your white spaces ...

We are talking about transfer rates between CPU and FPGA. It doesn't matter how fast the CPU can crunch garbage. If it can't collect/dump them fast enough to the FPGA, calculation speed means nothing.

In this case, MicroZed with internal FPGA will not be any better than PIC32MZ with external FPGA, linked with 2 to 4 I/O pins.

The PIC32 is a pokey 80MHz (maximum now available) single core licensed from MIPS rather than a 667 MHz dual-core ARM9 with double-precision FPU. I believe none of the PIC32s even have FPUs. No comparison- the ARM is probably 1,000 times faster doing FP math. Is there even a Linux port available for the PIC32? Without an MMU or the ability to deal with a gig of RAM, I'd guess not.

They're not remotely in the same league.

Hey, a 555 can put out a cleaner square wave than a DDS (maybe) but if you need a DDS, the 555 isn't going to cut it.

--sp

From the perspective of someone who needs an RTOS, Linux is a bag of very dubious software, indeed.

The fact that you were trying to work around Linux certainly explains the large and variable delays.

I agree that Linux makes the "complicated" stuff easier. If you really have a need for real-time, and you don't really need that other processor for your "big box" stuff, then put an RTOS on it and run your timing- critical stuff there.

Or, research the state of real time Linux -- it kind of dropped off my radar screen about five years ago, so either it's a done deal and no one's excited about it any more, or it never quite worked right and everyone who was excited about it is now too embarrassed to speak up.

Den fredag den 22. november 2013 22.36.21 UTC+1 skrev snipped-for-privacy@gmail.com:

it has several interfaces, it can move more data to the fpga faster than the cpu can come with it

on one of the interfaces, the one interface that is simple and low on resources meant to be used mostly for setup and such the Zynq can keep up with a PIC32 that use 100% of its time toggling pins

-Lasse

It looks like the Linux speed is fine for this application.

There is a huge advantage to running the Linux that comes installed in the uZed. No Linux to recompile!

If we have realtime problems (which I don't think we will) the second ARM core is available. We could ask Linux to run the signal processing app on it, or even run the app bare metal on the second core. So we have a bailout if we ever need it.

Hey, don't talk bad about the 555, them are fighting words!

Jamie

I can confirm that it is quite possible to reconfigure the FPGA from a C program after the OS is running.

You removed the FPGA config step from the bootloader, and now it doesn't work?

My first guess would be that the (so-called) voltage translation buffers between the ARM and the FPGA have not been enabled. There's a magic register somewhere that you need to write to before anything will work.

Get Rob to look through the (massive) TRM one more time...

Allan

I got my full Zedboard from

Regards, Mikko

My guys are building the whole boot image using the Xilinx tools, which combine the OS and the FPGA and boot-load it all, and that works. My customer would like to be able to upload separate files that are the application program and the FPGA image, so I'd like to figure out how to do that.

Rob has been busy on a couple of other projects, and I'm busy on the signal processing architecture and the host board hardware design, so Paul (my embedded programmer) and Blaine (our FPGA consultant) have been doing the serious work on this. The secondary FPGA load thing hasn't been first priority... talking to an FPGA register was, and now the signal processing is the next step.

Someone should write a book, Zed For Dummies. I'd buy one.

If anybody knows the details of reloading the FPGA live, I'd appreciate any hints or references that I could pass on to the boys.

Den lørdag den 23. november 2013 18.08.44 UTC+1 skrev John Larkin:

rote:

ombine

ld like

the

al

mbedded

work on

to an

ny

scroll down to appendix B, "How to In-System Reconfigure the Zynq's FPGA Fa bric with a New FPGA Bit File"

-Lasse

Very cool. Thanks. I'll pass that on to the boys.

Lots of info. This may be the important piece:

While the financial industry was once a hotbed for interest in realtime, that seems to have cooled somewhat. The traders are more interested in throughput and are willing to allow Linux to miss some latency deadlines in the interests of throughput, Hart said. The embedded use cases for realtime seem to be where the "action" is today, Gleixner and others said, but there has been little effort to fund realtime development coming from that community.

Fabric with a New FPGA Bit File"

You already said that /dev/xdevcfg crashed the kernel. My guess is that th ere are timing or semaphore issues with the driver. The driver is nothing m ore than loading the FPGA in SPI slave mode. However, for a big bin file, you might have to break it in pieces so the kernel watchdog module won't co me in and crash it.

If you can find the kernel source or at least the xdevcfg driver, we can ta ke a look at it. But knowing Xilinx, it might not be open sourced. In tha t case, you might have to write your own user-mode SPI slave driver. I hav e done something similar before.

Not exactly. I said that one of my guys thought it might or heard that it did or something. They are sort of dragging their feet on supporting live FPGA config (because they have so much else to do, to get the application working, lazy bums) and I've been prodding them to do it. Now I can say "see, other people are getting it to work!"

I'm designing the PC boards, the easy part.

Then its just a matter of cp, dd or cat into /dev/xdevcfg. Or perhaps some ioctl options to set.

Den søndag den 24. november 2013 16.22.08 UTC+1 skrev snipped-for-privacy@gmail.co m:

GA Fabric with a New FPGA Bit File"

there are timing or semaphore issues with the driver. The driver is nothing more than loading the FPGA in SPI slave mode. However, for a big bin file , you might have to break it in pieces so the kernel watchdog module won't come in and crash it.

take a look at it. But knowing Xilinx, it might not be open sourced. In t hat case, you might have to write your own user-mode SPI slave driver. I h ave done something similar before.

it's all on github

-Lasse