PIK - Pandaboard xM in Kiste

Further to BIK – Beagleboard xM in Kiste, the PIK is now out of the bag. Note that the board itself is subsidised by TI, so I guess anything could happen to prices.

[Edit: Sorry, that’s not xM of course! If any admins feel like correcting this, please go ahead.]

I can confirm the existence, one of those is on my desk, running nicely at 1600’er resolution at 60 Hz on a 24inch screen :-)

So far !Netsurf runs great surfing the web, also the VFP Basic Extension works. The only problem I got with my Example code for the VFP extension is the routines that detect the CPU clock rate don’t work and crash (derived from Jeffreys opp.bas code), as TI changed a lot where this information can be found in memory compared to the OMAP3530. I got to dig in the TRM’s to fix that and update my example code.

I’ll try to publish some more benchmark results. It seems the major benefit is the speed up on the VFP unit. The first tests with some integer stuff are almost the same compared to the Beagle Board…either for that code the out-of-order enhancements are no good or it doesn’t help much on integer in general.

…anyway, so far I’m quite happy with the PIK, of course no idea which of the other software runs or not.

OK, so I have been to the website, but I didn’t see a pin-up of the PIK. It would be nice to see a photo of it.
It would be interesting to know what software runs on it.
Does it have a battery for the rtc?

nice to see a photo

Maybe there’ll be some on ArcSite some time…

Does it have a battery for the rtc

It doesn’t look like it.

I can post some pictures of mine in the evening. I didn’t look at the Pandaboard in detail, but as a4com recommended me to attach the PIK to the network when booting as it derives it’s date and time from the internet (what works fine) I would guess there’s no battery…googleing about rtc and pandaboard seems to confirm that. Some people talk about adding a microcontroller or something…Link

@ Kuemmel
Schön, wenn Du zufrieden bist ;-)

I have some pictures of your (?) PIK and also pictures of the production of the plates (watercut). Maybe the pictures can be seen Thursday on my website.
If I understand correctly the Pandaboard Manual, there’s no way in the basic version to install a rtc battery but the Beagleboard work also well without if you have a network and nettime and you don’t need a portable ;-)

Ok. Erledigt.
Look at http://home.arcor.de/raik_fischer/ [Bilder] [Hardware]

I can confirm the existence, one of those is on my desk, running nicely at 1600’er resolution at 60 Hz on a 24inch screen

Great. :) Does that mean that this problem has been solved?

What’s the highest resolution you can get, and what version of RISC OS is it using?

The board should be able to do full HD if the OS handles it.

@Terje: Actually I didn’t play around with MDF’s, as I’m happy with the 1600×1200×60Hz (currently maximum with the MDF that was supplied with the PIK). The basic problem seems to be solved. There is a special HDMI-Port also but only got a blank screen. I got to check that more someday. According to the TRM’s of course you’re right. It should do 1980×1080 without any problem. The Risc OS version that is running is the one from Willi Theiss also found for download on RiscOSOpen.

Meanwhile I did some more intense benchmarking, with the benchmarks found on my webpage. Here’s the results graph showing some interesting things.

As one can see the benefit compared to the BeagleBoard is basically mostly due to the partly huge speed up of the VFP. Regarding speed up of integer routines the picture is a bit different. As I assume that the FPEmulator is truly integer based there seems a benefit, too. Though on my integer fractal there’s no difference at all. So that seems to be very different from application to application.

Surprisingly my !FireBench showed a slightly superior BeagleBoard. To find out why this happened I thought I should check the memory speed as this benchmark relies a lot on that. I compiled my findings in the two following graphs:

One can see that the OMAP4430 has a huge speed increase on first level cache activity when it comes to RAM→RAM copying. On the other hand when it comes to RAM→VRAM copying the OMAP3530 on the BeagleBoard is superior. That explains the !FireBench result. Strangely copying VRAM to RAM the OMAP4430 is far better. Besides that also the cache configuration can be clearly seen.

So overall a huge improvement for VFP applications. As I guess most software is integer based overall the Pandaboard should be faster also, but each application has to be checked separately. If somebody wants me to test some other software just tell me.

I also can confirm that my Pandaboard works fine at 1 GHz (thanks to Willi Theiss). I managed to write some small code to least also detect the OMAP version and clock rate. One obstacle at the moment is that only the two “back” USB-Ports are working, but I can live with that for now.

@Kuemmel:

Thanks for your comprehensive information. I’ve now ordered my PandaBoard. :) (Only the board, not the PIK version, as I already have the other components, like the USB hub.)

@Terje: Okay, hope you get yours soon !

Meanwhile I did some more experiments regarding the results for my Fractal Integer benchmark with some quite interesting findings. As seen above there was no speed gain, what left me astonished, as the C-A9 has features that should make him faster clock by clock…

…so I played around with reordering instructions in the time critical loop (mostly SMULL/ADD/MOV/ORR instructions)…and surprsingly it showed a big effect (Pandaboard now 33% faster). But on the other hand the C-A8 on the Beagleboard got a bit slower (3%). I’ll post the different code later.

I’m not sure why that is…may be the pipeline (C-A8: 13 stages, C-A9: 9 stages)…it seems to be more difficult to “dig out” the performance gains on the C-A9…I just thought an out-of-order CPU-design would do that easily by itself ;-) I hope the current C-compilers have “knowledge” of that things, if so that would promise more speed in “normal” applications.

So here’s the code I was talking about. It’s the inner loop of the standard Mandelbrot set for fixed point math, calculating 2 iterations per loop, while saving the bailout value. First my old version that run’s exactly at the same speed on Beagle and Panda:

.inner_loop
    SMULL R3,R9,R1,R1         ;" y%*y%
    SMULL R5,R6,R0,R0         ;" x%*x%
    SMULL R8,R2,R0,R1         ;" y%*x%
    MOV   R3,R3,LSR#(fl%)
    MOV   R5,R5,LSR#(fl%)
    MOV   R8,R8,LSR#(fl%-1)   ;" to multiply by 2"
    ORR   R9,R3,R9,LSL#(fh%)
    ORR   R6,R5,R6,LSL#(fh%)
    ORR   R2,R8,R2,LSL#(fh%+1);" to multiply by 2"
    SUB   R0,R6,R9            ;" x_new = x%*x% - y%*y%
    ADD   R4,R6,R9            ;" x*x% + y%*y%
    ADD   R0,R0,R10           ;" x_new = x_new + a%
    ADD   R1,R2,R11           ;" y_new _ y_new + b%
    ADD   R12,R12,#2          ;" add 2 iterations to counter
    SMULL R3,R9,R1,R1         ;" y%*y%
    SMULL R5,R6,R0,R0         ;" x%*x%
    SMULL R8,R2,R0,R1         ;" y%*x%
    MOV   R3,R3,LSR#(fl%)
    MOV   R5,R5,LSR#(fl%)
    MOV   R8,R8,LSR#(fl%-1)   ;" to multiply by 2"
    ORR   R9,R3,R9,LSL#(fh%)
    ORR   R6,R5,R6,LSL#(fh%)
    ORR   R2,R8,R2,LSL#(fh%+1);" to multiply by 2"
    SUB   R0,R6,R9            ;" x_new = x%*x% - y%*y%
    ADD   R3,R6,R9            ;" x*x% + y%*y%
    ADD   R0,R0,R10           ;" x_new = x_new + a%
    ADD   R1,R2,R11           ;" y_new _ y_new + b%
    ;***" Test if (r%+i%)<=4 OR n%>nmax%, if not -> loop "***
    CMP   R12,#(nm%)
    CMPLS R3,R7               ;" (r%+i%)>(4<<24)
BLS inner_loop

.inner_loop
    SMULL R3,R9,R1,R1         ;" y%*y%
    ADD   R12,R12,#2          ;" add 2 iterations to counter
    SMULL R5,R6,R0,R0         ;" x%*x%
    MOV   R3,R3,LSR#(fl%)
    SMULL R8,R2,R0,R1         ;" y%*x%
    MOV   R5,R5,LSR#(fl%)
    ORR   R9,R3,R9,LSL#(fh%)
    MOV   R8,R8,LSR#(fl%-1)   ;" to multiply by 2"
    ORR   R6,R5,R6,LSL#(fh%)
    SUB   R0,R6,R9            ;" x_new = x%*x% - y%*y%
    ORR   R2,R8,R2,LSL#(fh%+1);" to multiply by 2"
    ADD   R4,R6,R9            ;" x*x% + y%*y%
    ADD   R1,R2,R11           ;" y_new _ y_new + b%
    ADD   R0,R0,R10           ;" x_new = x_new + a%
    SMULL R3,R9,R1,R1         ;" y%*y%
    SMULL R5,R6,R0,R0         ;" x%*x%
    MOV   R3,R3,LSR#(fl%)
    SMULL R8,R2,R0,R1         ;" y%*x%
    MOV   R5,R5,LSR#(fl%)
    ORR   R9,R3,R9,LSL#(fh%)
    MOV   R8,R8,LSR#(fl%-1)   ;" to multiply by 2"
    ORR   R6,R5,R6,LSL#(fh%)
    SUB   R0,R6,R9            ;" x_new = x%*x% - y%*y%
    ORR   R2,R8,R2,LSL#(fh%+1);" to multiply by 2"
    ADD   R3,R6,R9            ;" x*x% + y%*y%
    ADD   R0,R0,R10           ;" x_new = x_new + a%
    ADD   R1,R2,R11           ;" y_new _ y_new + b%
    ;***" Test if (r%+i%)<=4 OR n%>nmax%, if not -> loop "***
    CMP   R12,#(nm%)
    CMPLS R3,R7               ;" (r%+i%)>(4<<24)
BLS inner_loop

Meanwhile I did some more experiments regarding the results for my Fractal Integer benchmark with some quite interesting findings. As seen above there was no speed gain, what left me astonished, as the C-A9 has features that should make him faster clock by clock…

…so I played around with reordering instructions in the time critical loop (mostly SMULL/ADD/MOV/ORR instructions)…and surprsingly it showed a big effect (Pandaboard now 33% faster). But on the other hand the C-A8 on the Beagleboard got a bit slower (3%). I’ll post the different code later.

Yeah, you’d think the processor would handle this kind of instruction reordering itself. Thanks for the info

With the help of Chris I got some more “real world” benchmark comparisons for you. He gave me his GCC 4.6 compiled versions for POV-Ray and LAME (MP3 de/encoder). I also added my tuned Fractal Integer benchmark mentioned above.

You can see a huge speed gain of the Pandaboard for POV-Ray and LAME, for LAME especially when the RAM disc was used to convert the WAV file. Here may be the cache/memory speed enhancements together with the VFP stuff pushes through…and may be my USB memory stick is quite slow…

out of curiosity, does the gcc 4.6 compile with -mfloat-abi=hard or does it use softfloat?
I have been looking into the armhf distro for Debian and that seems to give a substantial performance boost on FP. Both my pandaboard and snowball board seem to show impressive figures for floating point when compiled with hardfloat.

I compiled them with -mfloat-abi=softfp.

@Chris: is there a place to download gcc 4.6? i could not (yet) find it.

Chris, is your PDF compiled with hardware floating point available for download anywhere? It would be nice to try this on the Beagleboard now we have hardware floating point at last. (And any other apps you might have tried, of course.)

I think a PIK or BIK is what I am looking for, the price difference is neither here nor there, so my instinct is to get the PIK. However, should I consider getting the BIK as the BeagleBoard, rather than the PandaBoard gets more development attention?

All I need really is video, network and sound, I’m not even all that bothered about the RTC, if NTP can be used to get the right time. Any big difference I should be wary of?

@Gary: Sound is not yet there on the PIK, but Willi is working on that. Of course I think the BIK will still have the edge as most development seems to be done there first.

On the other hand Willi incorporates most of the ‘normal’, more hardware independent enhancements pretty fast, and the ROM releases are almost up to date. And also one big benefit for me is that the screen resolution works fine at up to 1920×1080/1200 with 60Hz. The BIK does only 30Hz at that resolution, so you would need a special TV-style monitor.

Hi Kuemmel,
Thanks for the reply, in this application as a sound system, sound is important and screen resolution is not really, so I think a BIK suits me. I normally really like high-res screens, but in this case I don’t need one. Perhaps if I find myself getting back into RISC OS, then I’ll get a PIK then.

Hi Kuemmel,
I don’t suppose you have an email address for the guys at a4com.de? I tried one on their site, and not had a reply.

Cheers!

Garry

Hi Gary, you should try http://www.a4com.de/kontakt.html
…there’s also Detlef Thielsch’s e-mail address.

Will do, I’ll try one of the other addresses.

Thanks

Garry