host to epiphany multicast, and wand/sync

[notzed]

I was looking at trying the multicast stuff but I can't seem to find any reference to how it works from the host. Andreas alluded to a write-register in the post below but I looked through e-hal and even the hdl but with no luck (not that i really know what i'm looking at in the hdl). e-hal doesn't even define the MULTICAST snoop register ($F0704) so it's pretty safe to assume it isn't used in e-hal anywhere. I see no example for it in epiphany-examples, and the only reference seems to be defining the reg in e-server.

All I can think of is just using a dma channel of a core either setup via the host or via an on-core routine. This may be what I go with anyway (seems silly wasting arm cycles on a memcpy) but i'm curious nonetheless.

said post: viewtopic.php?f=9&t=650&p=4087&hilit=multicast#p4087

FWIW the 4.13.x version of the arch reference manual is gone from it's original location:
http://www.adapteva.com/docs/epiphany_a ... .09.29.pdf

On a related note: wand/sync

How do you define the 'group' that wand waits on? Is this just defined implicitly by the *EDGE propagation bits in MESHCONFIG? I can't see any other way but it seems that would lead to a complex hardware solution (i.e. to count the number of cores in this workgroup). If so, are there restrictions on the shape of the workgroup (i.e. does it have to be rectilinear) and when it needs to be configured. Again it's something i haven't tried yet but hopefully will get time to look at soon.

[notzed]

So I tried getting wand to do something but i'm having no luck.

I'm trying a 2x2 workgroup (also tried 4x4)

I'm setting the meshconfig edge bits as:

row=0,col=0 value=$5000 = WESTEDGE | NORTHEDGE
row=0,col=1 value=$6000 = EASTEDGE | NORTHEDGE
row=1,col=0 value=$9000 = WESTEDGE | SOUTHEDGE
row=1,col=1 value=$a000 = EASTEDGE | SOUTHEDGE

(i also tried all combinations of flipping the bits incase my compass was up-ended)

I do some stuff then:
wand
idle

The cores set the WAND bit and clear the ACTIVE bit in the CONFIG register as they should. But they never continue.

I installed an ISR into IVT offset 0x20 which clears the WAND bit and increments a counter in external memory and returns. It doesn't seem to run - counter is never incremented. I unmasked the interrupt and also dump the registers and see no ipend show up.

So ... what's the secret?

edit
I don't know how i missed the hardware barrier example ... but I just found it. But it is not doing anything special.

I tried just not setting the MESHCONFIG at all and running it across the whole chip. Well that seems to work at least. But I can't get a sub-set of the chip to work.

So I have I just misunderstood the feature and it only works across the whole chip? So then the routing bits are just for propagating the signal to other chips?

[ysapir]

@notzed, one of the example programs in epiphany-examples shows how to use the multicast feature.

[aolofsson]

notzed,

Glad to see that you are trying some of these features!

We scrubbed the site of old docs, b/c we had lots of people using outdated versions. Here is the definitive list of docs:
viewtopic.php?f=23&t=980

In terms of the wand:
-Using the WAND interrupt and an ISR, we did find a possible bug in the C compiler related to alignment. Not sure if this is related to the issues you are having. If so, you would see an unaligned software exception.
-We'll put together an example for the mesh edge..looking through the code now, I found a "WTF was I thinking" kind of bugs related to the synbc/mbkpt mesh config!!! Unfortunately since many of the experimental "LABS" features never underwent heavy usage/testing some truly stupid bugs made it into the chip.
-Summary: until further notice...consider the MESHCONFIG edge feature broken:-(

In terms of multicast:
-Not implemented in e-hal yet. Multicast was tested last summer, but apparently a example never made it into the rep. I will check on the status.

Andreas

[notzed]

Ok cheers on the docs link. By default I use google rather than scanning forum topics, but that proved to be useless (again).

I'm using assembly. I wouldn't consider anything else even if only because it's a legitimate chance to use it. I subsequently got a whole-chip wand working so i think that was ok.

Disappointing that it's broken as it looked really interesting. Whole chip-mode should still be useful for some code I guess as that seems to work (perhaps). If edge routing works for sync it might be useful (although it's a bit of a bummer sync is also the soft-reset interrupt). Is there a way to initiate a broadcast sync from arm?

I did some experiments and it does affect the propagation (in some way) but doesn't seem to affect the barrier size - you still need all cores to wand before any will continue. But yeah if it's broken it's broken.

I tried the multicast stuff last night by using a dma channel on a core which is possibly the way i will use it anyway. Unfortunately it was one of those days where only frustrating dumb things happened and after crashing the system i spent a couple of hours trying to work out why it wouldn't boot to a ssh login only to remember at bedtime that I'd edited the sshd config. Oops.

Obviously the labs stuff is experimental but it wouldn't be there if it wasn't interesting.

[notzed]