thaks nice ideas. scalable would be nice does some know how to synchronise two or more tiles or port clocks from different tiles?
@infiniteimprobability: more tiles is not the problem (I use Gigabit ethernet (1 tile off) and have to spend a second chip xCore-200 eXplorer + self made pcb)
I have to change the phase shift (in worst case) after every period+longest phase shift time.
synchronize Outputs
-
- Member
- Posts: 14
- Joined: Tue Nov 24, 2015 4:33 pm
-
- Member
- Posts: 14
- Joined: Tue Nov 24, 2015 4:33 pm
No ideas? Or does no one read the second Page?^^
-
Verified
- XCore Legend
- Posts: 1142
- Joined: Thu May 27, 2010 10:08 am
Two options - I/O or channel..does some know how to synchronise two or more tiles or port clocks from different tiles?
Channel can be pretty timing deterministic as long as you reserve the route - i.e. streaming channel. Quite wasteful though as you only have 4 circuits available across tiles.
I/O - I would suggest outputting the clock via a 1b port to the other tile, and input it on the other. This would ensure that you get your 40ns periods lined up. You would also need some sort of frame synch - something to get the 100KHz signals line up. This would only need to be done once as long as your code didn't block at any point and met timing - both tiles share the same PLL so they will be frequency locked as long as your ref clock settings were identical.
I/O sounds like a winner to me.
Highly recommend you have a play with this and write a few test programs/feasibility to see if it all works as required. The header file xs1.h is your friend and will help you get the ports and clock blocks into the right modes
-
- Member
- Posts: 14
- Joined: Tue Nov 24, 2015 4:33 pm
I also thought about an trigger signal:
-load the data to the tasks
-output a single rising ore falling edge from a 1b port
-read in the edge to the single tasks
-start "counting"/output after this event
I have to spend one input port (1b) for every task and link them via a physical connection? Or is it possible to share a input pin? Or is it even possible to link them in the chip?
-load the data to the tasks
-output a single rising ore falling edge from a 1b port
-read in the edge to the single tasks
-start "counting"/output after this event
I have to spend one input port (1b) for every task and link them via a physical connection? Or is it possible to share a input pin? Or is it even possible to link them in the chip?
-
- Member
- Posts: 12
- Joined: Tue Oct 13, 2015 11:36 am
Yes, you will need a port. But it can be a 4-bit port; just tie the other pins low with a resistor.
If you use multiple chips, make sure that all chips run of the same 25 MHz oscillator. This will guarantee that both chips have an identical internal clock that is as good as it can be.
Outputting the clock from one tile and using that everywhere works, but there will be some jitter as the clock is resynchronised on the way in.
The method you are thinking of is also fine, you can improve on it by making sure that the input port that you all tasks are waiting for is clocked of the 500 MHz system clock.
You cannot link ports inside the chip.
If you use multiple chips, make sure that all chips run of the same 25 MHz oscillator. This will guarantee that both chips have an identical internal clock that is as good as it can be.
Outputting the clock from one tile and using that everywhere works, but there will be some jitter as the clock is resynchronised on the way in.
The method you are thinking of is also fine, you can improve on it by making sure that the input port that you all tasks are waiting for is clocked of the 500 MHz system clock.
You cannot link ports inside the chip.
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
No, sorry; each chip has its own PLL. The clocks can (and will) diverge.hkr87 wrote:If you use multiple chips, make sure that all chips run of the same 25 MHz oscillator. This will guarantee that both chips have an identical internal clock that is as good as it can be.
-
- Member
- Posts: 12
- Joined: Tue Oct 13, 2015 11:36 am
Are you sure?
It ought to lock itself to the input signal and then generate 20 output clocks per input clock, drifting with the input oscillator.
Lock will be lost if the input oscillator has a sudden change of heart, in which case all bets would be off.
It ought to lock itself to the input signal and then generate 20 output clocks per input clock, drifting with the input oscillator.
Lock will be lost if the input oscillator has a sudden change of heart, in which case all bets would be off.
-
- XCore Expert
- Posts: 844
- Joined: Sun Jul 11, 2010 1:31 am
Diverge is the wrong word, sorry.
The two clocks will not be in synch, not every 20 clocks in your example
either. As long as the PLLs stay locked there will be a maximum difference,
yes. Whether that is good enough for your purpose I don't know.
The two clocks will not be in synch, not every 20 clocks in your example
either. As long as the PLLs stay locked there will be a maximum difference,
yes. Whether that is good enough for your purpose I don't know.