XCore Architecture Block Diagram

[Heater]

Very interesting MaxFlashrom. However I think for the near future all my xcore programming will remain "in the spirit" of XC and it's rules. I guess many other will feel the same.

In which case my statement about fact that pins are not shared between threads is pretty much true. At least from the perspective of someone coming from the Propeller device where all pins are accessible from all cores at any time.

[rubenc]

I have written code to successfully share port32A on the L1-128 between multiple threads. As you observe, lines cannot be individually programmed as input or output. I imagine it's possible to have one thread use a whole port as input while another uses the whole port as output, but a far more likely case is that you will use groups of lines independently from multiple threads, either all as inputs or all as outputs. The XS1-L1 does not like resource sharing much: the XS1 Architecture manual says

Resources are owned and used by a single thread. If multiple threads attempt to access the same resource within 4 cycles of each other, a Resource Dependency exception will be raised.

When ET RESOURCE DEP is raised et will be set to 9.
In general, trying to guess timing dependency between threads such that a concurrent case of port access doesn't occur is a recipe for failure. It appears that port accesses separated by enough time between them do, indeed, work. If one is doing only reads, each thread need only do a read from the port and ignore any lines it's not interested in.

But what if both Threads use the same port as Input?
Can both threads acces it concurrently or with a small amount of time in between?
Will it also raise a Resource Dependency exeption?

Resources are owned and used by a single thread. If multiple threads attempt to access the same resource within 4 cycles of each other, a Resource Dependency exception will be raised.

This 4 cycles is talking about the 400Mhz clock cycles of the processor right?

[MaxFlashrom]

But what if both Threads use the same port as Input?
Can both threads acces it concurrently or with a small amount of time in between?
Will it also raise a Resource Dependency exeption?

Resources are owned and used by a single thread. If multiple threads attempt to access the same resource within 4 cycles of each other, a Resource Dependency exception will be raised.

This 4 cycles is talking about the 400Mhz clock cycles of the processor right?

Yes, as I said in my post:

I have written code to successfully share port32A on the L1-128 between multiple threads.
I used hardware locks to enable exclusive atomic read-write access to the port.

Perhaps, I need to highlight key points, as they get buried in the detail!
My code was a success, as I said, and this means that it didn't randomly throw exceptions. Yes, threads can access ports with a delay in between, both reading and writing(read-modify-write). Even if one could just sort out the timing, this is not good enough for partial port updates, one needs to: read port; modify the value read; write out new value. These 3 operations must be carried out as one indivisible operation.
Using a hardware lock sorts out both the timing problem and the atomicity problem; a thread exclusively acquires the hardware lock, performs a port access and releases the lock. Any thread attempting to acquire a lock already acquired by another thread will sleep pending the release of that lock.

Concurrent access to a port (here defined as within 4 cycles) throws an exception. If one ensures more than than amount of time it does not. My understanding is that "4 cycles" is 4 of the 400MHz(Or 500MHz on faster parts) cycles, so 10ns or 1 instruction cycle, as far as I understand it. As the hardware scheduler time-slices after each instruction I'm guessing that this amounts to a port access in one thread being followed immediately by a port access in another thread when the hardware scheduler moves on to it. In any case I was never going to approach this level of nearness ,as lock acquisition takes an instruction etc.

I am somewhat reluctant to advocate this method as a general solution as it suffers from timing inter-dependance between threads and is not in line with the "XS1 Way" . Having one thread own a port and having it perform all actions on it has advantages. If despite this you're hell bent on breaking all the rules, I can provide code

Max.

[rubenc]

If despite this you're hell bent on breaking all the rules, I can provide code

Hell yeah! I like breaking the rules. :twisted: ... in a good way. :idea:

In fact I need that both threads read"-only" the same port, no writing is involved. so if you handle it allredy maybe my approach will also work.

It would be great if you can show me your code.


Regards
rubenbendtherules!