Port I/O Slowdown

[monk_is_batman]

I have been trying to time extremely short pulses in rapid succession to be able to read data of a fairly fast line (12 MHz). That means the pulses are only 83 ns wide. I have so far been successful at reading these for the most part, but it seems that having i/o operations on other threads occurring it slows it down and the fastest I can time is increased from around 80 ns to around 100 ns.

Is this behavior that other people get and just deal with or is there some sort of way to work around it in software?

[Andy]

You can run up to 4 threads at the full 100 MIPS and any additional may run as slow as 1/n * 400 MIPS, where n is the number of threads.

Is this consistent with the slow down you're experiencing?

[monk_is_batman]

I don't believe so as I only had 3 threads running on that core, and the issue seemed to go away when I removed the section of code in another thread that was talking to the i/o. I am using a statement like below to do the timing.

rcv_pin when pinsneq(pin_state) :> pin_state @ time1;
rcv_pin when pinsneq(pin_state) :> pin_state @ time2;

I thought maybe when you are doing i/o on another thread in the core it somehow slows down its ability to respond.

[JohnR]

Hi,

For what it's worth, I have posted on xcore a project (Measuring nanosecond delays) describing my attempts at measuring very short intervals between two pulses, 'start' and 'stop'. This project used separate threads for each pulse. The minimum time difference measured was around 15 nsec but this was limited by the minimum delay of my dual pulse generator.

More related to your project, I also tested a version of my timer code using a pulse generator that combined the start and stop pulses in an XOR chip, generating a pulse that was high for the period between start and stop. In this case I used only one thread for the front end but the minimum pulse width that I could measure was around 65 nsecs, so I have reverted to the dual input thread approach.

John

[Woody]

For timing short pulses on a signal, I would use timestamping. I'd also send the signal to two ports so that both edges can be timed without the need for instructions to execute between detecting one edge and detecting the other. This will also mean that you use two threads: one for setting up and then measuring the positive edge's time, the other for the negative edge. You'll need to send the times through a channel to compare them.

If you use the reference clock then you will have a resolution of 10ns (since the reference clock is 100MHz). However if you want to have better resolution, you can increase the reference clock to 500MHz on an XS1-L device and get a resolution of 2ns. However be careful if you decide to do this because the timer clock also changes if you do this, so all of your absolute times will need to be scaled.

Code: Select all

// Use code something like this within the timing threads
posPort when pinseq (0) :> void; // Make sure that it is an edge that is detected
posPort when pinseq (1) :> void @ posEdgeTime;
posEdgeTimeChannel <: posEdgeTime;