Walk-Through

       .file tut.s
       .arch atmega103
       .global main

       .type main,@function
main:
       push   r1
       push   r2
       push   r3
       push   r4      
       ldi    r20,100
       ldi    ZL, lo(foo)
       ldi    ZH, hi(foo)

loop1:
       st     r20, Z+
       dec    r20
       brne   loop1
       pop    r4
       pop    r3
       pop    r2
       pop    r1
       ret

Run it through Thrint (thrint tut.s), and we get this CDG, which is generated by default.

Thrint’s parser will complain if it doesn’t like the input. The Thrint FAQ and Hints page has a section on Parser Troubleshooting which is useful in this case.

Assuming that the input file was parsed correctly, we would also like to see the assembly code that Thrint reconstructs based on its internal CDG representation of our code. Use the –S switch to turn out assembler source code output.

Original duration -1 -1
Final duration -1 -1
Program terminated normally

Examining the output file tut.int.s shows us that thrint has reorganized some directives, but otherwise the program is the same:

       .file tut.s
.arch atmega103
.global main
       push   r1
       push   r2
       push   r3
       push   r4
       ldi    r20,100
     ldi    ZL,lo(foo)
       ldi    ZH,hi(foo)
loop1:
       st     r20,Z+
       dec    r20
       brne   loop1
loop1_0:
       pop    r4
       pop    r3
       pop    r2
       pop    r1
       ret

2 Control Dependence Graph Generation

If we want to see instructions in the CDG we need to specify the i suboption for graph generation: switch –Gi.

3 Loop Duration Hint

Notice that the duration of the procedure may be undefined (X and -1 indicate this) since the loop count for loop1 is unknown. (if the duration isn't undefined, this means that the data-flow and loop iteration count analyses were successful, and you can skip over this section). This also appears in the CDG. We can provide a hint in the iterations directives file called tut.id. The Procedure and End lines are legacy requirements and must be included.

The CDG also now contains a duration for the loop and start times for the node(s) following it.

4 Host Timing Analysis

Now let’s examine the execution time characteristics of this procedure. Thrint will generate a list of deterministic timing segments if requested with the –Th switch (analyze timing for host procedure). This information is contained in two data files: tut.main.s.dat and tut.main.j.dat. The first file (the segment file) describes the nodes in each segment, and how much cumulative jitter exists when that node begins (what the difference between the earliest and the latest start times could be). Loops are unrolled.

The second (the jitter file) describes how much timing jitter that node incurs. Again, loops are unrolled.

0 0
# Loop loop1: iteration 0 of 100
11 0
14 1
# Loop loop1: iteration 1 of 100
16 0
19 1
# Loop loop1: iteration 2 of 100
21 0
24 1

These files are formatted as input files for gnuplot. Thrint creates two command files for gnuplot (tut.s.gpc and tut.j.gpc) which will create graphs when run through gnuplot.

plot "tut.main.s.dat" with linespoints
pause -1
plot "tut.main.j.dat" with steps
pause -1

5 Adding Guest Code to the Procedure

Now let's add some real-time instructions to our code. We need to add some guest code to our simple procedure and then specify that they are guest nodes, and when they need to execute. For example, let's send r22 out through PortB at certain times. First, insert the guest source code before the ret:

Guest0:
       ldi    r22, 55
       ldi    r17, 9
Guest1:
       add    r22, r17
Guest2:
       out    PORTB, r22
       dec    r22
Guest3:
       out    PORTB, r22
       dec    r22
Guest4:
       out    PORTB, 3
       ret

6 Specifying Timing Requirements for Basic Blocks

Next we need to modify the integration directives file. We add processor clock speed information (10 MHz) and a default tolerance for timing errors (0 cycles) as global parameters. The clock frequency isn’t essential at this point, but it will be useful if we want to define integration targets in time (e.g. microseconds) rather than cycles. Multiple tolerance directives are supported, the most recent one defines the tolerance for successive BLOCK directives.

We then add timing targets for each of the guest basic blocks; these times are referenced to the start of the procedure’s execution. We specify the real-time instructions should start well after the loop, beginning at cycle 603.

We can now examine the CDG created by Thrint for the input procedure; the new code is added and highlighted in yellow. This shows how Thrint is representing the program internally.

7 Determining Guest Code Idle Time

Next we examine the idle time between guest nodes now that the guest code has been added and sub-thread timing requirements have been specified. Use the –Tg switch to add guest timing analysis to Thrint’s tasks. -hv may also be needed to disable timing verification (we aren't scheduling codeyet ).

$ thrint –Gi –Tg tut.s
…
Analyzing Guest Idle Time
Created idle time analysis files:tut.main.i.gpc and tut.main.i.dat
Created idle time analysis files:latest_proc.i.gpc and latest_proc.i.dat
Guest Idle Time: CIdleNodeList(size=2): [2*1, 509*1]
…

Thrint reports that it has found idle time of two sizes: one which is two cycles long and one which is 509 cycles long.

Thrint processes this information into a histogram to simplify the analysis of this data. Two files are created: tut.main.i.dat holds idle time histogram data and tut.main.i.gpc is a command file for gnuplot. The first looks like this.

0 6
16 0
32 0
48 0
64 0
80 0
96 0
112 0
128 0
144 0
160 0
176 0
192 0
208 0
224 0
240 0
256 0
272 0
288 301
304 0
320 0

The first column holds the start (lower edge) of the cycle bin, while the second column holds the amount of idle time with that granularity. We can again use gnuplot and the .gpc file to plot this information, or excel if you prefer.

8 Discrete Padding to Schedule Guest Instructions

We can now tell Thrint to schedule the real-time instructions to ensure they begin at the right times. Thrint inserts nops or loops of nops to do this. We must change the id file to indicate discrete padding with nops is needed.

PROCEDURE main DISCRETE_PADDED

Then we can run thrint on the file to pad it with nops.

Thrint indicates its progress with the following text:
Padding dedicated guest function with nops
Padding procedure main as dedicated guest.
Done with padding away jitter in discrete guest.
Done with padding discrete guest for sub-thread scheduling.
Re-Analyzing Timing Statically
Verifying Integrated Guest Timing
The following CDG is created.

(Note that if we do not use a -G option (such as -Gi) to generate a CDG, the vcg file created shows the CDG before padding and leaves out the code we're interested in.)
An output assembly file tut.int.s is also created. It shows how padding instructions have been added. These come in two varieties: padding nops (e.g. at Guest1p and Guest2p) and padding nop loops (e.g. at Guest4p_*).

9 Discrete Padding to Eliminate Jitter

Thrint can also pad away timing jitter in code without scheduling any instructions to execute at specific times. The following example, using pad_test.s and pad_test.id, eliminates jitter before and within a loop.

We use the ID file and the command line options to indicate we wish to pad away that timing jitter. The ID file only requires the DISCRETE_PADDED keyword.

On the command line we specify we want assembly code generated (-S), code
transformations specified in the ID file performed (-i) and a CDG with instruction
information created (-Gi).

The final duration of the code is now constant. Here is the padded code pad_test.int.s.

10 Integration

We are now ready for integration, which we specify with the –i option. Thrint creates a file with its integration plan for each segment to be integrated in a procedure. For example, main.int.log holds the integration plan for our example.