Copying an input signal

New to XMOS and XCore? Get started here.
dimitris
Active Member
Posts: 37
Joined: Tue Feb 19, 2013 5:07 pm

Copying an input signal

Postby dimitris » Thu Apr 18, 2013 4:03 pm

Hi there community,

My set up is
-> a pulse generator
->XMOS SliceKit
->High-Freq Oscilloscope

I am trying a very simple thing. To input a pulse on a pin and output it on another. Seems trivial.
However what I am getting is

input:..............|""""""""|..............|""""""""|..............|""""""""|..............|""""""""|..............|""""etc
output:..............|"|..................................................|"|........................|"|.............................etc

which is not even stable for every pulse. I tried various frequencies from 50Hz to 3MHz.
Obviously I am doing something terribly wrong...any suggestions?

Code: Select all

#include <platform.h>
#include <xs1.h>

on stdcore[1]: in port inPort = XS1_PORT_1A;
on stdcore[1]: out port outPort = XS1_PORT_1B;

void toggleThread(){
	int x=0;
	while(1){
		inPort :> x;
		outPort <: x;
	}
}
int main(void) {
	par {
		on stdcore[1]: toggleThread();
	}
}
User avatar
sethu_jangala
XCore Expert
Posts: 589
Joined: Wed Feb 29, 2012 10:03 am

Postby sethu_jangala » Fri Apr 19, 2013 9:29 am

Hope this helps.

Code: Select all

#include <platform.h>
#include <xs1.h>

on stdcore[1]: in port inPort = XS1_PORT_1A;
on stdcore[1]: out port outPort = XS1_PORT_1B;

void toggleThread(){
   int x=0;
   inPort :> x;
   while(1){
      inPort when pinsneq(x):>x;   
      outPort <: x;
   }
}
int main(void) {
   par {
      on stdcore[1]: toggleThread();
   }
}

dimitris
Active Member
Posts: 37
Joined: Tue Feb 19, 2013 5:07 pm

Postby dimitris » Fri Apr 19, 2013 10:48 am

Dear Sethu,
thank you for your reply. I have tried your solution before and it still gives the same results. Here are some images taken from the oscilloscope. The first is an example at 800KHz and the second at 2MHz.
You can see that the output(yellow) reacts to the input(red) but not copying it. This is where my question focuses.

On the bottom left you can also see that the delay between the signals is the same on both occasions. Also the pulse width of the output (yellow) signal is always the same ~110ns too.
My idea is that the output should follow the input with a small delay. However the output rises with a delay of 80ns and then after 110ns it falls back to zero. Instead of copying the signal, this code is doing clock edge detection. Which is useful but not for what i need. :-)

PS: The ~90ns delay between input and output is by far more than expected since these actions are single instruction ones. So I see another task here. How fast does the XMOS react to input after all?
You do not have the required permissions to view the files attached to this post.
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Fri Apr 19, 2013 8:28 pm

dimitris wrote:Dear Sethu,
thank you for your reply. I have tried your solution before and it still gives the same results.
Sethu's code is better for slow signals (like you have), since the thread
will go to sleep while waiting for the input to change, saving power.
It however will take an extra thread cycle for the thread to wake up,
which is fine for slow signals.
Here are some images taken from the oscilloscope. The first is an example at 800KHz and the second at 2MHz.
You can see that the output(yellow) reacts to the input(red) but not copying it. This is where my question focuses.
Yes, that is very curious. Both pieces of code should copy the input
(with some delay and some jitter).

For a slow signal like yours, the rise/fall of the output isn't nearly as
steep as expected, and the input isn't exactly clean either. I would
suspect the measurement setup and the circuitry in general.
On the bottom left you can also see that the delay between the signals is the same on both occasions. Also the pulse width of the output (yellow) signal is always the same ~110ns too.
My idea is that the output should follow the input with a small delay. However the output rises with a delay of 80ns and then after 110ns it falls back to zero. Instead of copying the signal, this code is doing clock edge detection. Which is useful but not for what i need. :-)

PS: The ~90ns delay between input and output is by far more than expected since these actions are single instruction ones. So I see another task here. How fast does the XMOS react to input after all?
First, the signal is synchronised to the system clock (2.5ns, assuming
a 400MHz clock). The I/O block normally processes things on the
reference clock (100MHz, so 10ns). Your code will have at least four
core cycles between instructions (more if more than four threads are
running), so that's 10ns per instruction. For the output, you have
pretty much the same thing (in the opposite order). This doesn't add
up to 90ns. My first suspect is your code is too slow -- did you do an
unoptimised build?
User avatar
Ross
XCore Expert
Posts: 768
Joined: Thu Dec 10, 2009 9:20 pm

Postby Ross » Mon Apr 22, 2013 11:17 pm

Something strange going on there. Can you post the compiler output (use -S)?

The loop should compile to only 3 instructions... in, out, branch.

Sethu, that code is functionally the same.
dimitris
Active Member
Posts: 37
Joined: Tue Feb 19, 2013 5:07 pm

Postby dimitris » Tue Apr 23, 2013 8:55 am

As segher implied there was a problem in the setup since the pulse generator was set at 2.5V. I suspect that what was measured and copied was the overshoot of the pulse generator (that got the voltage instantly a little bit above 2.5). The code is indeed compiled without any optimizations.
I won't have access to the setup until Wednesday. I will check again and also send the compiler output results.
Thank you once again and I will come back to this on Wednesday.

Regards,
Dimitris


EDIT: I checked the compiled code via the debugger and it does minimize down to three instructions (i will measure the delay with a scope when i regain access to the setup). However, i am expecting the -S flag to produce .s files and I can't find those. I have tried with -O0 -S -g.
dimitris
Active Member
Posts: 37
Joined: Tue Feb 19, 2013 5:07 pm

Postby dimitris » Fri Apr 26, 2013 9:50 am

I assume that, to accurately copy an input clock with one thread, the minimum clock width must be longer or equal than the copying delay. Now, xCore issues two commands to copy a signal (in, out) and the frequency for single-thread use is 125MHz(C5 device). That means, that the in-out-branch will take twelve cycles thus 12*8ns, 96ns. So, every 96ns an "in" instruction is being issued. Meaning, i should be able to securely copy a signal of 1/(96*2)=5,2MHz

Do you find these assumptions correct? Strangely it looks like I have managed to copy faster signals of up to 6.2MHz and if my pulse generator has a steeper output maybe I could measure even faster.
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Fri Apr 26, 2013 12:11 pm

dimitris wrote:I assume that, to accurately copy an input clock with one thread, the minimum clock width must be longer or equal than the copying delay.
The delay doesn't matter; all that matters is that your clock pulses
are long enough for your code to never miss one.
Now, xCore issues two commands to copy a signal (in, out) and the frequency for single-thread use is 125MHz(C5 device). That means, that the in-out-branch will take twelve cycles thus 12*8ns, 96ns.
Not twelve, just three -- you already divided to 125MHz.

So, assuming your code is the minimal in-out-branch, one loop
of that code takes 24ns. So your clock has to stay high for 24ns,
and low for 24ns. So the maximum clock frequency you can do
this way is about 20MHz.

You can go faster if you use more of the hardware features of the
I/O ports, of course.
dimitris
Active Member
Posts: 37
Joined: Tue Feb 19, 2013 5:07 pm

Postby dimitris » Fri Apr 26, 2013 3:09 pm

segher wrote: So the maximum clock frequency you can do
this way is about 20MHz.
You can go faster if you use more of the hardware features of the
I/O ports, of course.
Yes, you are absolutely right. However I do lose the input pulse if it goes higher than 6.2MHz. Is it because my pulse generator is not steep enough (probably...) or am i missing something else?
Which "hardware features" do you refer to?
User avatar
segher
XCore Expert
Posts: 843
Joined: Sun Jul 11, 2010 1:31 am

Postby segher » Fri Apr 26, 2013 3:41 pm

dimitris wrote:However I do lose the input pulse if it goes higher than 6.2MHz. Is it because my pulse generator is not steep enough (probably...) or am i missing something else?
Look at the generated code (with xobjdump -d), is it really just the
three instructions?

And yes, the signal is pretty bad :-)
Which "hardware features" do you refer to?
You can process signals faster than 20MHz if you use port clocks,
the shift register, etc.

Who is online

Users browsing this forum: No registered users and 1 guest