Jesse,

The performance counter is very usefull. I used it already in Nios1, with a
custom peripheral just counting clock cycles. The point in my design was
that I use a 64 bit counter. So it is expected to never roll over. The
counter part of this is that you have to do two read actions to it to get
the time.

If you then add some classes, you can define a kind of PseudoTimer class.
Each instance keeps track of when it is started and stopped.
Finde code below.

Hope this can be of any use for someone

Stefaan.



Verilog code for counter :

module never_ending_timer(Clk, Reset, Out, A, nRD, CS);

input Clk, Reset;
input A, nRD, CS;
output [31:0] Out;

parameter bits = 64;

reg [bits-1:0] cnt;
reg [bits - 32 - 1 : 0] temp;

always @(posedge Clk or posedge Reset)
    if (Reset)
        begin
            cnt <= 0;
            temp <= 0;
        end
    else
        begin
            cnt <= cnt + 1;
            if (CS && !nRD && !A) // read action on lowest DWORD
                temp <= cnt[bits-1:32]; // = store highest part
        end

    assign Out = A ? temp : cnt[31:0];

endmodule


C++ code :  (paste in some editor to see colors!)

//standard types
typedef unsigned char  BYTE;
typedef unsigned short  WORD;
typedef unsigned long  DWORD;
typedef unsigned long long QWORD;

class STick
{
private:
 volatile struct never_ending_counter
 {
  DWORD counter_lo;
  DWORD counter_hi;
 } * hw;

 DWORD Lo() {return hw->counter_lo;};
 DWORD Hi() {return hw->counter_hi;};  // ! first read the lower part for
latching the value!!


public:
 STick(void* hw_address) { hw = (never_ending_counter*) hw_address |
(1<<31);};
 ~STick() { };

 QWORD Ticks() {
//       DISABLE_USED_HERE
//       DISABLE_INTERRUPTS
      DWORD lo = Lo();
      DWORD hi = Hi();
//       ENABLE_INTERRUPTS
      return lo + (((QWORD) hi) << 32);
     };
};

extern STick Tick;

class PseudoTimer
{
private :
 STick* hw;
 DWORD Running;
 QWORD start;
 QWORD delta;

public :
 PseudoTimer() { hw = (STick*) &Tick;  Running = 0;  start = hw->Ticks(); };
 PseudoTimer(void* hw_address) {hw = (STick*) hw_address;  Running = 0;
start = hw->Ticks();};
 ~PseudoTimer() {};

 //start timing measurement at zero
 void Start() {  start = hw->Ticks(); Running = 1;};

 //restart time measurement (adds time to previous interval)
 void Restart() { start = hw->Ticks() - delta; Running = 1;};

 DWORD StopDWORD() {  //you can use stop as a brand new starting point
     QWORD t = hw->Ticks();
     delta = t - start;
     start = t;
     if (delta > 0xFFFFFFFFFFFFFFFFL)
      return 0xFFFFFFFF;
     Running = 0;
     return (DWORD) delta;
    };

 DWORD PeekDWORD() { //peak doesn't affect timer operation
      if (Running)
      {
       QWORD t = hw->Ticks();
       delta = t - start;
      }
      if (delta > 0xFFFFFFFFFFFFFFFFL)
       return 0xFFFFFFFF;
      return (DWORD) delta;
     };

 QWORD Peek() { //peak doesn't affect timer operation
     if (Running)
     {
      QWORD t = hw->Ticks();
      delta = t - start;
     }
     return delta;
    };


 QWORD Stop()
    {  //you can use stop as a brand new starting point
     QWORD t = hw->Ticks();
     delta = t - start;
     start = t;
     Running = 0;
     return delta;
    };
};










"Jesse Kempa" <kempaj@yahoo.com> wrote in message
news:95776079.0407131023.1266b496@posting.google.com...
> steven derrien <steven_derrien@yahoo.fr> wrote in message
news:<ccu7n3$acg$1@python.ifsic.univ-rennes1.fr>...
> > Hi,
> >
> > Has anybody been trying to use gprof within the NIOS II IDE ?
> > We have some problems regarding the profiling data that is
> > send through the jtag interface directly to the IDE console window.
> >
> > We had a look to the documentation but there is little information
> > regarding the use of the profiler with the NIOS II.
> >
> > It seems that, to the difference of NIOS I, the profiling data
> > is sent as binary data, resulting in the following stdout trace :
> >
> > < Here the program standard output >
> > **gmon.out data follows**
> > < non readable binary data >
> > nios2-terminal: exiting due to ^D on remote
> >
> > Does anybody knows how to solve this issue ?
> >
> > Thank you in advance,
> >
> > Steven
>
> Hi Steven,
>
> Here are the basic steps to using GPROF in Nios II:
>
> (In the IDE):
> 1. Add a compiler switch, "-pg", for your src code project (in the
> C/C++ build area of the project properties). This is standard fare for
> using GPROF regardless of processor.
> 2. Add the same "-pg" switch for the compiler in your system library
> project.
> 3. Check the "use profiling library" checkbox in syslib properties.
>
> (From the SDK Shell):
> 4. Run your program: Use nios2-terminal's "--gmon" switch which will
> automatically capture the profiling data into a 'gmon.out' file after
> your program finishes execution. This has to be done from the command
> line, not the IDE.
>
> Note: nios2-terminal must be started with the processor in a paused
> state. You can do this by opening two SDK shell windows, downloading
> your program using "nios2-download <elf file>" (which downloads your
> code and leaves the processor paused), then running "nios2-terminal
> --gmon" in the second window, and finally running "nios2-download -g"
> in the first to start execution.
>
> More notes: Your application must return from main() because the
> profiling library's data dump is triggered by reaching atexit().
>
> Also, the above notes assume that you're using the JTAG UART for
> STDIO; for the conventional UART we cannot support GPROF with the
> above flow just yet (this is scheduled for the next release)
>
> 5. Place the "gmon.out" file (generated in step 4) into the same dir
> as your .elf file
> 6. Run nios2-elf-gprof <elf file name> gmon.out > <output file name>
> 7. Examine the output file for results.
>
> The above flow was actually easier than I had expected given my GPROF
> experience with other processors :) However, I am sending an
> enhancement request to our engineering team to make the above flow all
> happen from within the IDE so that the SDK shell business isn't
> necessary.
>
> Also, I'll see to it that this is looked at for a relevant app note
> when the time comes; in addition to GPROF there is a performance
> counter peripheral (which is documented in the Nios II kit) which is
> useful for profiling sections of code -- such an app note will likely
> describe the use of both tools.
>
> Jesse Kempa
> Altera Corp.
> jkempa at altera dot com

Thank you for your help.

Steven

Jesse Kempa wrote:
> steven derrien <steven_derrien@yahoo.fr> wrote in message news:<ccu7n3$acg$1@python.ifsic.univ-rennes1.fr>...
> 
>>Hi,
>>
>>Has anybody been trying to use gprof within the NIOS II IDE ?
>>We have some problems regarding the profiling data that is
>>send through the jtag interface directly to the IDE console window.
>>
>>We had a look to the documentation but there is little information 
>>regarding the use of the profiler with the NIOS II.
>>
>>It seems that, to the difference of NIOS I, the profiling data
>>is sent as binary data, resulting in the following stdout trace :
>>
>>< Here the program standard output >
>>**gmon.out data follows**
>>< non readable binary data >
>>nios2-terminal: exiting due to ^D on remote
>>
>>Does anybody knows how to solve this issue ?
>>
>>Thank you in advance,
>>
>>Steven
> 
> 
> Hi Steven,
> 
> Here are the basic steps to using GPROF in Nios II:
> 
> (In the IDE):
> 1. Add a compiler switch, "-pg", for your src code project (in the
> C/C++ build area of the project properties). This is standard fare for
> using GPROF regardless of processor.
> 2. Add the same "-pg" switch for the compiler in your system library
> project.
> 3. Check the "use profiling library" checkbox in syslib properties.
> 
> (From the SDK Shell):
> 4. Run your program: Use nios2-terminal's "--gmon" switch which will
> automatically capture the profiling data into a 'gmon.out' file after
> your program finishes execution. This has to be done from the command
> line, not the IDE.
> 
> Note: nios2-terminal must be started with the processor in a paused
> state. You can do this by opening two SDK shell windows, downloading
> your program using "nios2-download <elf file>" (which downloads your
> code and leaves the processor paused), then running "nios2-terminal
> --gmon" in the second window, and finally running "nios2-download -g"
> in the first to start execution.
> 
> More notes: Your application must return from main() because the
> profiling library's data dump is triggered by reaching atexit().
> 
> Also, the above notes assume that you're using the JTAG UART for
> STDIO; for the conventional UART we cannot support GPROF with the
> above flow just yet (this is scheduled for the next release)
> 
> 5. Place the "gmon.out" file (generated in step 4) into the same dir
> as your .elf file
> 6. Run nios2-elf-gprof <elf file name> gmon.out > <output file name>
> 7. Examine the output file for results.
> 
> The above flow was actually easier than I had expected given my GPROF
> experience with other processors :) However, I am sending an
> enhancement request to our engineering team to make the above flow all
> happen from within the IDE so that the SDK shell business isn't
> necessary.
> 
> Also, I'll see to it that this is looked at for a relevant app note
> when the time comes; in addition to GPROF there is a performance
> counter peripheral (which is documented in the Nios II kit) which is
> useful for profiling sections of code -- such an app note will likely
> describe the use of both tools.
> 
> Jesse Kempa
> Altera Corp.
> jkempa at altera dot com

steven derrien <steven_derrien@yahoo.fr> wrote in message news:<ccu7n3$acg$1@python.ifsic.univ-rennes1.fr>...
> Hi,
> 
> Has anybody been trying to use gprof within the NIOS II IDE ?
> We have some problems regarding the profiling data that is
> send through the jtag interface directly to the IDE console window.
> 
> We had a look to the documentation but there is little information 
> regarding the use of the profiler with the NIOS II.
> 
> It seems that, to the difference of NIOS I, the profiling data
> is sent as binary data, resulting in the following stdout trace :
> 
> < Here the program standard output >
> **gmon.out data follows**
> < non readable binary data >
> nios2-terminal: exiting due to ^D on remote
> 
> Does anybody knows how to solve this issue ?
> 
> Thank you in advance,
> 
> Steven

Hi Steven,

Here are the basic steps to using GPROF in Nios II:

(In the IDE):
1. Add a compiler switch, "-pg", for your src code project (in the
C/C++ build area of the project properties). This is standard fare for
using GPROF regardless of processor.
2. Add the same "-pg" switch for the compiler in your system library
project.
3. Check the "use profiling library" checkbox in syslib properties.

(From the SDK Shell):
4. Run your program: Use nios2-terminal's "--gmon" switch which will
automatically capture the profiling data into a 'gmon.out' file after
your program finishes execution. This has to be done from the command
line, not the IDE.

Note: nios2-terminal must be started with the processor in a paused
state. You can do this by opening two SDK shell windows, downloading
your program using "nios2-download <elf file>" (which downloads your
code and leaves the processor paused), then running "nios2-terminal
--gmon" in the second window, and finally running "nios2-download -g"
in the first to start execution.

More notes: Your application must return from main() because the
profiling library's data dump is triggered by reaching atexit().

Also, the above notes assume that you're using the JTAG UART for
STDIO; for the conventional UART we cannot support GPROF with the
above flow just yet (this is scheduled for the next release)

5. Place the "gmon.out" file (generated in step 4) into the same dir
as your .elf file
6. Run nios2-elf-gprof <elf file name> gmon.out > <output file name>
7. Examine the output file for results.

The above flow was actually easier than I had expected given my GPROF
experience with other processors :) However, I am sending an
enhancement request to our engineering team to make the above flow all
happen from within the IDE so that the SDK shell business isn't
necessary.

Also, I'll see to it that this is looked at for a relevant app note
when the time comes; in addition to GPROF there is a performance
counter peripheral (which is documented in the Nios II kit) which is
useful for profiling sections of code -- such an app note will likely
describe the use of both tools.

Jesse Kempa
Altera Corp.
jkempa at altera dot com