Peculiar "if" Statement

[Aladeen]

All,

I have been using the SliceKIT Core Board to output a pulse with a 50% duty cycle. The frequency I need can be as high as about 360 kHz, which I have no problem achieving. However, I need to add a feature to my program that does a kind of "frequency sweep." The user communicates to the device over serial through a terminal and tells the program how long the sweep should be, and what the starting and ending frequencies should be. The frequency change begins in this section of the code (the actual math to change the freq comes later):

Code: Select all

								if (periods_per_rpm_counter == periods_per_rpm)
								{
									port_4d_bits |= d_8_bit; //set d 8 bit
									port_4d_out <: port_4d_bits; //output to pin
									if (rpm_counter < rpm_sweep_end_num_user)
									{
										port_4d_bits &= ~d_8_bit;  //clear d 5 bit
										port_4d_out <: port_4d_bits; //output to port_4d_out

I have two if conditions that, when the frequency is supposed to change, will evaluate to true. The output to the pins shown in the code is being used here as a form of "diagnostic pulse," which the chip outputs and I can see the pulse on an o-scope, and can thus fairly accurately evaluate how long that particular statement takes to run in my code. I have also placed this diagnostic pulse around the first if condition in other "test runs," which is shown in the following code:

Code: Select all

								port_4d_bits |= d_8_bit; //set d 8 bit
								port_4d_out <: port_4d_bits; //output to pin
								///////////////////BEGIN SECTION TO CREATE RPM SWEEP//////////////////////
								if (periods_per_rpm_counter == periods_per_rpm)
								{
									port_4d_bits &= ~d_8_bit;  //clear d 5 bit
									port_4d_out <: port_4d_bits; //output to port_4d_out
									if (rpm_counter < rpm_sweep_end_num_user)
									{

The first if is run in about 150 ns, which will work fine with my program. However, the second if take about 700-750 ns, which is too long and causes my frequency change to be skewed. I have tried interchanging these two statements, thinking that I could prove that one of them was the condition that consistently took longer to evaluate. However, I noticed that whichever condition was placed second took longer to evaluate, which I found quite strange. Then I removed one of the conditions (the one with the < comparison, because the code could still run without this condition for my diagnostic purposes), thinking that with only one if this section of code would move more quickly. But the result was that the single condition took about as long as the sum of the two if's took (about 850-900 ns). I'm rather confused as to why my program is behaving in such a manner. I know that my debugging methods are fairly primitive and perhaps confusing, but if any of you could afford me some ideas/advice I would sincerely appreciate.

Regards,

Alex

[Aladeen]

Bump.

[srinivas]

Hi,
The timing analyzer tool integrated with xTIMEcomposer studio should come in handy for timing analysis.
Please check the below link to know some details on its usage:
https://www.xmos.com/published/xmos-tim ... zer-manual

regards,
Srini

[JasonWhiteman]

You could also take two different versions of the code that have confusing timing relationships and inspect how the assembly code rolls out from C. Once you lock in on an "easy" assembly region which matches a portion of C code walk through your assembly mapping to C - you may be able to become more informed of how many instructions are between critical timing paths for each sets of code.

I'm not very far into XMOS architecture to consult on the relationship of clock counts per instruction (and differences in # clocks, if any). However, the XMOS assembly reference should have this information.

Other more sophisticated tools may either help get there faster - or provide a barrier. Depends on how you generally relate to hardware. Same goes for this method. Ultimately, I would think that gaining an understanding of assembly would be advantageous for success in timing critical projects.


Regards,
Jason Whiteman