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
Some questions about clock blocks, ports (and more)
-
- Member
- Posts: 13
- Joined: Thu Feb 04, 2010 12:45 am
-
- Respected Member
- Posts: 279
- Joined: Fri Dec 11, 2009 1:34 pm
Hi!
I'll try and answer some of these... but someone from XMOS will be more qualified.
Not sure why you'd want to read it at any other time.
I'll try and answer some of these... but someone from XMOS will be more qualified.
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?AkkiSan wrote: Can a serialized port automatically(!) turn a clock signal (attached to a port) on and off synchronous to the output of data?
You can definitely read the port clock when you do an input/output to a port i.e: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"?
Code: Select all
int time;
pin <: 0 @ time;
You can change the rate at which timers are clocked usingAs far as I read, there are "10 timers" available per core. A timer can not be written to and there are no dividers available.
Code: Select all
configure_clock_rate(SPI_CLOCK, 100, 4); // 25MHz clock
I think this is true, however I'm interested what application/protocol you are implementing that needs a bidirectional buffered port?As far as I understood, a bidirectional port can not be buffered and, hence it will lose its powerful (de-) serialization features.
I think it is by default - it only has to output every couple of clock cycles rather than every clock cycle.Can a serialized output port be non-blocking, so one can prefetch the next data?
All instructions take one clock cycle apart from divide. Someone please correct me if I'm wrong.Is there any documentation about the timing of the instruction set or
memory access?
-
- Member
- Posts: 13
- Joined: Thu Feb 04, 2010 12:45 am
Oh yes, I tried this out before. Unfortunately stopping the timer does not seem to be thatAndy wrote: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?AkkiSan wrote: Can a serialized port automatically(!) turn a clock signal (attached to a port) on and off synchronous to the output of data?
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 ;)
Yes, I know this.You can definitely read the port clock when you do an input/output to a port i.e: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"?Not sure why you'd want to read it at any other time.Code: Select all
int time; pin <: 0 @ time;
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
Oh no, I was not talking about the 16 bit port counters but the 32 bit timers...You can change the rate at which timers are clocked usingAs far as I read, there are "10 timers" available per core. A timer can not be written to and there are no dividers available.Code: Select all
configure_clock_rate(SPI_CLOCK, 100, 4); // 25MHz clock
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...
Well, any bidirectional, serial interface?I think this is true, however I'm interested whatAs far as I understood, a bidirectional port can not be buffered and, hence it will lose its powerful (de-) serialization features.
application/protocol you are implementing that needs a bidirectional buffered port?
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...
Mhh, I have to try this out. May be I did something wrong...I think it is by default - it only has to output every couple of clock cycles rather than every clock cycle.Can a serialized output port be non-blocking, so one can prefetch the next data?
Well, I am not so sure about this.All instructions take one clock cycle apart from divide. Someone please correct me if I'm wrong.Is there any documentation about the timing of the instruction set or
memory access?
At least, my scope and analyzer show up something different.
The manual says:
I did not manage to find anything else about this...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.
Axel
-
- XCore Addict
- Posts: 165
- Joined: Wed Feb 10, 2010 2:32 pm
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.
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.
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.AkkiSan wrote:Can a serialized port automatically(!) turn a clock signal (attached to
a port) on and off synchronous to the output of data?
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.
-
- XCore Addict
- Posts: 165
- Joined: Wed Feb 10, 2010 2:32 pm
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.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 noavailable, "blabla" must not have changed in the meantime...Code: Select all
void <: blabla @ time
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.
-
- XCore Addict
- Posts: 165
- Joined: Wed Feb 10, 2010 2:32 pm
Hi Andy,Andy wrote:You can change the rate at which timers are clocked usingAs far as I read, there are "10 timers" available per core. A timer can not be written to and there are no dividers available.Code: Select all
configure_clock_rate(SPI_CLOCK, 100, 4); // 25MHz clock
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.
-
- XCore Addict
- Posts: 165
- Joined: Wed Feb 10, 2010 2:32 pm
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!AkkiSan wrote:Well, any bidirectional, serial interface?
The most well known of this type should be I2C...
FYI. This is implemented in hardware, so it's the same restriction for asm as XC.
-
- Member
- Posts: 13
- Joined: Thu Feb 04, 2010 12:45 am
Oh yes, I agree, this was too much...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.
But thanks for taking the time!
Just one (and last, I promise) comment on this:
Slow like a 480MBit/s USB transfer, right? ;-))its very nature a serial bidirectional interface must be slow
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
-
- XCore Addict
- Posts: 165
- Joined: Wed Feb 10, 2010 2:32 pm
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?AkkiSan wrote:Slow like a 480MBit/s USB transfer, right? ;-))Woody wrote:its very nature a serial bidirectional interface must be slow
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?
-
- Member
- Posts: 13
- Joined: Thu Feb 04, 2010 12:45 am
No matter if it is low, full or high speed, the D+ and D- line form a symmetricalWoody wrote: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?AkkiSan wrote:Slow like a 480MBit/s USB transfer, right? ;-))Woody wrote:its very nature a serial bidirectional interface must be slow
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.
Setting pins to tristate/input takes the same time as changing the driver state...It takes time for such interface signals to change direction from input to output, so that's why a said they are always slow.
Yes, dozens of them. But the time needed for switching over from in- to outputDo you know an interface like this that needs to change direction quickly?
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.
So it shall be...AkkiSan wrote: Just one (and last, I promise) comment on this:
AS