Copying an input signal

[dimitris]

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();
	}
}

[sethu_jangala]

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]

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?

[segher]

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?

[Ross]

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]

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]

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.

[segher]

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]

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?

[segher]

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.