Some questions about clock blocks, ports (and more)

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
Post Reply
User avatar
AkkiSan
Member
Posts: 13
Joined: Thu Feb 04, 2010 12:45 am

Some questions about clock blocks, ports (and more)

Post by AkkiSan »

Hi all,

I would appreciate any help, comments or whatever on the following
topics. I am still on day 7 of my XMOS experienece, so I might have
missed the one or other thing in the docs...


Can a serialized port automatically(!) turn a clock signal (attached to
a port) on and off synchronous to the output of data?
The clock output on the pin should only be present if data is shifted
out but the internal clock signal will still be needed for timing,
so it can not be turned off.


Can I read the value of a port clock without making use of the
IN or OUT instructions, like I can do with timers, e.g.: "t1 :> time"?


As far as I read, there are "10 timers" available per core.
A timer can not be written to and there are no dividers available.
Well, in this case they would all contain the same values all the time.
Possibly we are talking about only 1 timer but 10 different capture
registers for using the "AFTER" mode, here?


The bidirectional capabilities of the XMOS architechture seem to be
very weak. As far as I understood, a bidirectional port can not be
buffered and, hence it will lose its powerful (de-) serialization features.
So, obviously there is no other way but coding this all manually and
losing a lot of performance because a clock block can operate up
to 50MHz (assuming 100MHz core clock).


Can a serialized output port be non-blocking, so one can prefetch the
next data?


Is there any documentation about the timing of the instruction set or
memory access?



I guess this is enough for today ;)
Thanks in advance for any answer...

Axel


User avatar
Andy
Respected Member
Posts: 279
Joined: Fri Dec 11, 2009 1:34 pm

Post by Andy »

Hi!

I'll try and answer some of these... but someone from XMOS will be more qualified.
AkkiSan wrote: Can a serialized port automatically(!) turn a clock signal (attached to a port) on and off synchronous to the output of data?
I don't believe so... you need to manually start and stop the clock with start_clock() and stop_clock(). I assume this feature is absent because most protocols don't rely on when the clock starts/stops but rather when a separate data enable signal goes active (hence the presence of configure_out_port_strobed_master). Any particular reason why it has to be automatic?
Can I read the value of a port clock without making use of the IN or OUT instructions, like I can do with timers, e.g.: "t1 :> time"?
You can definitely read the port clock when you do an input/output to a port i.e:

Code: Select all

int time;
pin <: 0 @ time;
Not sure why you'd want to read it at any other time.
As far as I read, there are "10 timers" available per core. A timer can not be written to and there are no dividers available.
You can change the rate at which timers are clocked using

Code: Select all

configure_clock_rate(SPI_CLOCK, 100, 4); // 25MHz clock
As far as I understood, a bidirectional port can not be buffered and, hence it will lose its powerful (de-) serialization features.
I think this is true, however I'm interested what application/protocol you are implementing that needs a bidirectional buffered port?
Can a serialized output port be non-blocking, so one can prefetch the next data?
I think it is by default - it only has to output every couple of clock cycles rather than every clock cycle.
Is there any documentation about the timing of the instruction set or
memory access?
All instructions take one clock cycle apart from divide. Someone please correct me if I'm wrong.
User avatar
AkkiSan
Member
Posts: 13
Joined: Thu Feb 04, 2010 12:45 am

Post by AkkiSan »

Andy wrote:
AkkiSan wrote: Can a serialized port automatically(!) turn a clock signal (attached to a port) on and off synchronous to the output of data?
I don't believe so... you need to manually start and stop the clock with start_clock() and stop_clock(). I assume this feature is absent because most protocols don't rely on when the clock starts/stops but rather when a separate data enable signal goes active (hence the presence of configure_out_port_strobed_master). Any particular reason why it has to be automatic?
Oh yes, I tried this out before. Unfortunately stopping the timer does not seem to be that
accurate/synchronous for fast clocks (e.g. 50MHz).
Additionally, one will lose the capability of using the port counter as a timer while no data
is transfered.
Another option would probably be switching the clock pin to tristate (if possible???) or
detaching the pin from the clock.
Hasn't anybody tried this?

And yes, there are good reasons for doing so ;)
Can I read the value of a port clock without making use of the IN or OUT instructions, like I can do with timers, e.g.: "t1 :> time"?
You can definitely read the port clock when you do an input/output to a port i.e:

Code: Select all

int time;
pin <: 0 @ time;
Not sure why you'd want to read it at any other time.
Yes, I know this.
But imagine you have
a) no input port
b) and 2 threads are involved
c) and the variable was already changed by another thread

Because there is no

Code: Select all

void <: blabla @ time
available, "blabla" must not have changed in the meantime...
As far as I read, there are "10 timers" available per core. A timer can not be written to and there are no dividers available.
You can change the rate at which timers are clocked using

Code: Select all

configure_clock_rate(SPI_CLOCK, 100, 4); // 25MHz clock
Oh no, I was not talking about the 16 bit port counters but the 32 bit timers...
As far as I read through the manual and tried several things out, there seems
to be no way of changing a timers value or its frequency, right?
This is why I assumed 1 timer and 10 capture registers...
As far as I understood, a bidirectional port can not be buffered and, hence it will lose its powerful (de-) serialization features.
I think this is true, however I'm interested what
application/protocol you are implementing that needs a bidirectional buffered port?
Well, any bidirectional, serial interface?
The most well known of this type should be I2C...
If the port is set to bidirectional mode, it can not be buffered and hence you
are losing the capability of serialization, right? The manual(s) is/are not very
clear on this.
And for every limitation, I discovered, it is not completely clear to me if this
is "caused" by XC or the silicon. May be one could do more in asm than XC?

There is a lot of information missing in the docs...
Can a serialized output port be non-blocking, so one can prefetch the next data?
I think it is by default - it only has to output every couple of clock cycles rather than every clock cycle.
Mhh, I have to try this out. May be I did something wrong...

Is there any documentation about the timing of the instruction set or
memory access?
All instructions take one clock cycle apart from divide. Someone please correct me if I'm wrong.
Well, I am not so sure about this.
At least, my scope and analyzer show up something different.
The manual says:
Typically over 80% of instructions executed are 16-bit, so that the XS1 processors fetch
two instructions every cycle. As typically less than 30% of instructions require a memory
access, each processor can run at full speed using a unified memory system.
I did not manage to find anything else about this...


Axel
User avatar
Woody
XCore Addict
Posts: 165
Joined: Wed Feb 10, 2010 2:32 pm

Post by Woody »

This is turning into a monster thread. I'm finding it a bit hard to work out which replies correspond to which questions. If you have any follow up questions please put them on a separate thread so it's easier to read.
AkkiSan wrote:Can a serialized port automatically(!) turn a clock signal (attached to
a port) on and off synchronous to the output of data?
Have you looked at using a 'ready_in' strobe? This basically only clocks data in(or out) of a port when another pin is asserted. Look at 'Programming in XC on XMOS Devices' http://www.xmos.com/system/files/xcuser_en.pdf section 6.3. I'm not sure exactly what' you're doing, but this may well address the issue you want.

Correction to this post.
I first stated "The port timer does not increase when 'ready_in' is negated." However this is not true, the port timer does in fact increase for each clock it receives whether or not 'ready_in' is negated. Sorry for the confusion.
Last edited by Woody on Tue Feb 23, 2010 2:12 pm, edited 1 time in total.
User avatar
Woody
XCore Addict
Posts: 165
Joined: Wed Feb 10, 2010 2:32 pm

Post by Woody »

AkkiSan wrote:
But imagine you have
a) no input port
b) and 2 threads are involved
c) and the variable was already changed by another thread

Because there is no

Code: Select all

void <: blabla @ time
available, "blabla" must not have changed in the meantime...
You rightly pointed out that there are 10 timers which all read exactly the same time. Threads can therefore use different timers, but be able to output at exact times relative to each other.

Do you mean a 'variable' shared between threads? The best way of achiving this is to pass the informations (presumably timing information) between separate threads using channels.

Please create a different thread if you want to discuss this issue further.
User avatar
Woody
XCore Addict
Posts: 165
Joined: Wed Feb 10, 2010 2:32 pm

Post by Woody »

Andy wrote:
As far as I read, there are "10 timers" available per core. A timer can not be written to and there are no dividers available.
You can change the rate at which timers are clocked using

Code: Select all

configure_clock_rate(SPI_CLOCK, 100, 4); // 25MHz clock
Hi Andy,

This is incorrect actually. You are confusing clock_blocks with timers.

Timers all have the same time and have no dividers. The current time can be read from a timer, or a thread can use a timer to wait for a specific time.

Clock blocks are used to drive a clock to a port. (All ports require an active clock to work.) The clock block can divide down the 100MHz reference clock to use as the clock it drives to the ports. Alternatively a 1 bit port can be used as the clock source which is then routed through the clock block to other ports which then use it as their clock.
User avatar
Woody
XCore Addict
Posts: 165
Joined: Wed Feb 10, 2010 2:32 pm

Post by Woody »

AkkiSan wrote:Well, any bidirectional, serial interface?
The most well known of this type should be I2C...
You're right that a bidirectional port cannot be buffered. This shouldn't be a restriction because by its very nature a serial bidirectional interface must be slow, so shifting in software rather than hardware will be fine. This is what the XCores are all about!

FYI. This is implemented in hardware, so it's the same restriction for asm as XC.
User avatar
AkkiSan
Member
Posts: 13
Joined: Thu Feb 04, 2010 12:45 am

Post by AkkiSan »

Woody wrote:This is turning into a monster thread. I'm finding it a bit hard to work out which replies correspond to which questions. If you have any follow up questions please put them on a separate thread so it's easier to read.
Oh yes, I agree, this was too much...
But thanks for taking the time!

Just one (and last, I promise) comment on this:
its very nature a serial bidirectional interface must be slow
Slow like a 480MBit/s USB transfer, right? ;-))

Well, the serialization is not limited to 1 bit serial lines.
Transceiving 32bit over an 8bit bidirectional interface would "require"
the same... (require -> benefit from hardware serialization).


Axel
User avatar
Woody
XCore Addict
Posts: 165
Joined: Wed Feb 10, 2010 2:32 pm

Post by Woody »

AkkiSan wrote:
Woody wrote:its very nature a serial bidirectional interface must be slow
Slow like a 480MBit/s USB transfer, right? ;-))
I meant a port that itself changes directions between being an output then switching around to being an input. USB doesn't do that at 480MBit/s does it?

XCores can reach quite high serial bit rates (not quite 480MBits/s though) without a phy, on interfaces which have data paths in both directions so long as the ports themselves are not required to switch between being an input at one point to being an output at another time like I2C. It takes time for such interface signals to change direction from input to output, so that's why a said they are always slow. Do you know an interface like this that needs to change direction quickly?
User avatar
AkkiSan
Member
Posts: 13
Joined: Thu Feb 04, 2010 12:45 am

Post by AkkiSan »

Woody wrote:
AkkiSan wrote:
Woody wrote:its very nature a serial bidirectional interface must be slow
Slow like a 480MBit/s USB transfer, right? ;-))
I meant a port that itself changes directions between being an output then switching around to being an input. USB doesn't do that at 480MBit/s does it?
No matter if it is low, full or high speed, the D+ and D- line form a symmetrical
transmission line which indeed is bidirectional.
But only a few will hook it up to the processor's pins directly ;)
Actually I was referring to the speed of serial transmission systems/lines.
It takes time for such interface signals to change direction from input to output, so that's why a said they are always slow.
Setting pins to tristate/input takes the same time as changing the driver state...
Do you know an interface like this that needs to change direction quickly?
Yes, dozens of them. But the time needed for switching over from in- to output
is not a problem.
I only wondered about the fact that the powerful feature of serialization is
lost if you make a port bidirectional, and if my assumption is right.
Additionally (but I may be wrong on that), it requires at least two threads to
keep up a constant high speed data stream with data on every clock cycle.

At a glance, a XCore seems to be pretty fast. And at least this is true for the
software-only part (although the instruction set does not seem to be fully optimized
for (X)C...).

The innovation seems "to stop" (I'm heavily exaggerating here ;-) at the hardware part
or the interface core <-> pins respectively.
Even the fastest processor is worth nothing if you lose computing power
for trivial tasks like shifting out/in bits, high speed UART sampling, and, and, and...

It would be unfair to compare XMOS with highly optimized DSP CPUs/MCUs,
but their included hardware state machines and DMA capabilities don't eat
up "a single cycle" (...). And these days, even the smallest, low-cost dsPIC
comes with features like this...

For XMOS, the clock blocks are the ones that make things fast...
Every additional instruction will slow things down "dramatically".
(Just imagine a toggling pin in pure software:
Others can do (symbolic) "XOR pin" in a single cycle. A XCore needs at least 2...)

Now, just to avoid others calling me names or accuse me of "XMOS bashing":
Yes, I still like it ;-)

But I must admit that I expected a little more (speed, speed, speed...).
A DMA clock block and a little more flexibility/programmability would really rock the house...
(And this is only one of the missing features. At least "missing" whilst thinking about
our products...)

I switched over to ASM a week ago, because I was (or still am) unsure about what
problems/limitations are caused by XC and which of them are in the silicon.
AkkiSan wrote: Just one (and last, I promise) comment on this:
So it shall be...

AS
Post Reply