cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
grando
Observer
Observer
3,230 Views
Registered: ‎09-15-2009

Time measurements with xps_timer resulting cyclic values

Hi everybody,

 

I'm currently using a board with Virtex5 (XUPV5-LX110T) and XPS 12.1

I'm implementing some systems with 1, 2 and 4 Microblazes, with and without cache, and measuring the execution time of a sample program using xps_timer (one for each microblaze). The values are outputed in the terminal at the end of the overall execution.

For all cases, the program is located in DRAM.

 

The program kern was generated from a simulink model, where for 2 and 4 processors the same model is divided in 2 and 4 parts, respectively. Then I repeat this code n times and measure each of them to get a mean.

 

The problem I'm facing, or at least it sounds strange to me, is that in some cases the measurements are cyclic after some iterations.

Like this.

369077
369522
369077
369522

 

or

481045
481011
480959
480841
481045
481011
480959
480841

 

I could accept this results for a single core system, but this also occurs in a system with 4 processors acessing the memory through a shared PLB and passing values to each other (the output of one processor is input for another - uses shared bram or fsl).

 

Here is the code snippet related to this:

 

/* Sampling Loop     */
    for (i = 0; i < SAMPLES; i++){
        XTmrCtr_Start(&timer,0);
        t0 = XTmrCtr_GetValue(&timer,0);
        
        core1_processInputs();      // inputs get constant values (1st processor) or reads from memory (others)
        core1_step();                        // step procedure from simulink
        core1_processOutputs();  // do nothing (last processor) or write values to memory (others)
                
        t1 = XTmrCtr_GetValue(&timer,0);
        XTmrCtr_Stop(&timer,0);
        timesamples[i] = t1 - t0;
    }

 

I wonder why that happens, if there's something not correctly configured in the system or in the programs/routines.

can anyone figure out what could be causing this behaviour?

 

Thank you in advance,

 

Carmela

0 Kudos
2 Replies
austin
Scholar
Scholar
3,227 Views
Registered: ‎02-27-2008

Carmela,

Regular behavior is certainly preferred over random results! I suspect that the cyclic behavior is related to what the counter-timer counts (probably MicroBlaze clocks?). Some instructions may have to wait for memory accesses, and the contention may be cyclical in the memory controller (assignes priority on a round-robin basis). Check the memory controller for how it assigns the ports, and if you can choose other priority schemes.
Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
grando
Observer
Observer
3,207 Views
Registered: ‎09-15-2009

Hi Austin,

 

thanks for your reply.

Your assumptions are right: the counter-timer counts processor clocks, the memory controller uses round-robin for priority, and I do prefer regular behaviour :)

 

Actually, most of time I get a regular behaviour. In these cases, the clock count of each iteration is not the same, but quite close to each other. Since there are up to 4 processor acessing the memory through the same PLB, I expect that variances caused by traffic show up.

 

Furthermore, I don't know how far the round-robin priority would affect when only one port of the  memory controller is used. Maybe the PLB priority schema (also round robin), but then I would have to assume that the processors requests to PLB follow the same pattern....?

 

Maybe I expect things to behave in a way they don't. It's just that I was not able to justify the correctness of such regular and cyclic measurements.

This is mainly happening in configurations where the programs communicate and no cache is available. So I'm checking and re-checking my in-/output functions and the communication ressources (fsl/shared bram). It's quite posible that I'm overlooking something there, but I still didn't want to exclude other possibilities...

 

Many thanks,

Carmela

 

 

 

 

0 Kudos