microZed adventures

On a sunny day (Fri, 22 Nov 2013 08:57:12 -0800) it happened John Larkin wrote in :

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:

Without any defined spec for the application who knows? Ad Jim says: You are about as vague as it gets on that,

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.

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.

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

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.

There is a perfectly good, detailed spec. You can't see it.

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.

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.

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

But you still need external SDRAM with or without Linux.

Quark or PIC32MZ both have 2M flash and 512K SRAM on-chip.

Yes, it's a AMBA problem. It's good for high volume data transfer, not for single bit.

We're running the Linux that comes installed on the uZed.

There's probably some way to make Linux run the realtime app on the second ARM core. I guess we could even force that to run bare-metal code if we had to. The current application will probably run fine if we do nothing special. We'll have some FIFOs in the FPGA to buffer stuff, so the occasional millisecond or so timeout won't break anything.

I have been pressured for some time now to run C apps inside an FPGA, in a soft core processor, microBlaze or whatever. That never made sense to me, eating all those FPGA resources to get a pokey CPU with a tiny memory space. The new FPGA chips with hard ARM cores, cache, ram, and DRAM controllers mean it's time to do it.

It's looking that the Linux that comes with the uZed will work fine for the current application. Is Linux "a bag of unknown software"?

We need to do TCP/IP stuff, and manage waveform data files, run BIST, things like that, and using Linux sure makes that part easy. A lot of the functionality could be in ARM code or might be in the FPGA, but I'm moving as much as possible into the ARM. C is a lot easier to code and compile than VHDL.

Den fredag den 22. november 2013 17.57.12 UTC+1 skrev John Larkin:

where did you find the board? I've been looking for one to play with but I haven't seen it in stock anywhere

the ~6MHz sound reasonable for the simplest PL interface, there's synchronization etc. going in to get off and one the fast bus, The datasheet says ~25Mbyte/s expected

afaikt configuring the fpga in linux is as simple as generating a binary bit file and copy it to /dev/xdevcfg

-Lasse

So, that's around 200MHz BW with the internal 32 bit bus. A PIC32MZ can do it with 4 bits at 50MHz or possibly 2 bits at 100Mhz. PIC32MX I/O clock peak at 80Mhz, perhaps MZ can do better.

On a sunny day (Fri, 22 Nov 2013 10:58:58 -0800) it happened John Larkin wrote in :

Well you state 120 ns, I dunno, but I can flip 10M Hz that makes 50 nS on 50 nS off on the Raspi, without any FPGA, using GPIO. I posted about those test results here, maybe it was actually 12 MHz, That allows me to send real time DVB-S signals from GPIO. because of the kernel task switching that you noticed, I added 8kx9 FIFO to get a constant output stream.

I know the value of saying 'Look We Have The Latest ZZZZZZZ' and that _could_ impress a customer, IF he knows something, but usually they do not care how you do it if it contained horse s*it and beats their expectations fine, I think that those were Kennedy's ('s OK now? hehe) words,

Nothing to argue, It is your show. There are many channels. I have heard Monty Python wants to do a come back, I have never even watched the stuff ever.

So, I will spend some time playing with Wolfram Language (never used that) and Mathematica on my Raspi. Very nice if him to make it available for free.

Or, as in my case about am ARM controller and a few instances before, ST did not answer at all. So they flew out of the design.

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

you are comparing a car and a bus, move two people fast take the car, move 100 people use a bus

something like an stm32f4 has set/reset IO on the AHB bus, so it should be able to toggle 32 pins at 84MHz, when running at 168MHz

how is a cpu32 designed and made only by microchip more neutral than ARM made by pretty much every manufacturer out there?

-Lasse

The uZed has a gigabyte of DDR3 on-board, all done and working.

Maybe one could implement a dual-port memory that's faster on the ARM side. As-is, I have to move two 32-bit words to keep a waveform FIFO full, and I can do that in 340 ns, good enough.

I am comparing the fastest way to move data from A (CPU) to B (FPGA).

But the MicroZed and many other ARMs doesn't. I reserve any judgement on the STM32M4 until i have a chance to check it, or someone can prove it.

If Xilinx can't do it right, i can guess how the others do.