how to synchronize clocks ?

[matrix]

Hi,

I am wondering how to start 2 (or more) clocks at the same time.
Apparently the simulator indicates that attached code fragment
does not synchronize the clocks, or is it a simulator issue ?

Thanks for replies.

Code: Select all

.
.
configure_clock_rate (clk1 , 100 , 4);
configure_clock_rate (clk2 , 100 , 4);
.
. 

par
{
start_clock (clk1);
start_clock (clk2);
}
.
.

[ale500]

I was asking myself sort of the same... how to achieve synchronism between threads on the same core.

This rises another point: we can configure the clocks on one thread and use them in another... that may solve the problem, indirectly, because we can synchronize them in one thread and use them in another.. can't we ?... needs some testing.

[matrix]

Hi Ale500,

Interesting idea to solve the problem that way.
Another thing to do is to figure out how the par function is implemented, but since
I am new to the XMOS platform I did not take it so far, yet.

The XC language manual says that par will start tasks at the same time, there is no differentiation
between different cores and hardware threads on the same core.

So the situation is still not quite clear to me, but anyway thanks for your suggestions.

[MaxFlashrom]

Hi,

I am wondering how to start 2 (or more) clocks at the same time.
Apparently the simulator indicates that attached code fragment
does not synchronize the clocks, or is it a simulator issue ?

Thanks for replies.

Code: Select all

.
.
configure_clock_rate (clk1 , 100 , 4);
configure_clock_rate (clk2 , 100 , 4);
.
. 

par
{
start_clock (clk1);
start_clock (clk2);
}
.
.

Presumably the idea is that you want the 2 clocks of the same frequency to have zero phase shift between them. This doesn't really make sense on one core: why not just use one clock? Perhaps if one wanted to implement a mult-phase clock(with same frequencies) or one where one clock was s a multiple of the other this might be useful. Usually what one does is clock several ports from the same clock; this keeps their I/O exactly in phase, as I/O operations wait for the common clock edge. One could synthetically generate clocks of appropriate phase by clocking out appropriate patterns on (one or more, possibly buffered) ports from a shared clock.

Where the clocks are on different cores and one wishes to do synchronous I/O across cores then one could generate the master clock on one core for the others. The ports offer strobed modes which would help with this. There may be an issue with a few ns of jitter, but this may not matter in many cases.

Inter-thread synchronisation/rendezvous can be achieved through the use of channels. Usually cycle-accurate matching is not what's required/ more a barrier operation where several threads must wait for a start signal before continuing. On a single core, slave threads can be synchronised to a master thread. The slave threads are created via a common thread synchroniser and are started on a signal from the master thread owning the synchroniser. This is how XC par is implemented. As for how par works across cores, I can only guess that channels are somehow used(I'll have to disassemble a multi-core example to find out.)

Using an in-out pair in XC achieves inter-thread synchronisation i.e

Code: Select all

chan cout, cin;
par {
    { unsigned int x;
        cout <: x }

    { unsigned int x;
        x :> cin }
}

This is achieved by sending and checking CT_END tokens between threads.

See section 9 in the Xcore XS1 Architecture Tutorial and section 11 "Concurrency and Thread Synchronisation" in the Xcore XS1 Architecture manual.

Max.

[matrix]

Hi Max,

Thanks for the detailed info.
Yes, my idea was to have on of the clocks as a multiple of the other on,
sorry for the mistake in the code.

matrix

[ale500]

It did make sense if the same clock couldn't be used among threads (I may have mis-read the manual), Of course two clocks with the same frequency does not bring much on the same core. Now, among cores... is something else entirely. The point of it would be to capture at high speed,I mean in the >50 MHz range, where a bit of phase-whift means quite a bit of time.