The complete program is compiled from the top level make file. Both a standalone program (simple-soc) and a libtool compliant library (libsimple-soc.la) are created, and both incorporate the library created when building the logger test (see Section 5.6). The library provides a convenient mechanism for reusing the code from this model, when creating subsequent models which used derived classes.

The Or1ksim configuration is also unchanged. Like the logger, the UART registers start at address 0x90000000 and are a total of 8 bytes in length.

Running the model requires specifying the configuration file (unchanged) and the binary executable (this time the UART loop back program). Assuming the programs have been built in a directory named build, the following command line is suitable.

.build/sysc-models/decoup-soc simple.cfg progs_or32/uart-loop
	

The results look very similar to those for the synchronized version, as shown in Figure 9.4.

$ .build/sysc-models/decoup-soc simple.cfg progs_or32/uart-loop

             SystemC 2.2.0 --- May 16 2008 10:30:46
        Copyright (c) 1996-2006 by all Contributors
                    ALL RIGHTS RESERVED

   ... <Or1ksim initialization messages>

Char F read at  554441676667 ps
Read: 'F'
Char written at 555541610 ns
Char a read at  604641666667 ps
Read: 'a'
Char written at 605741610 ns
Char r read at  666641666667 ps
Read: 'r'
Char written at 667741600 ns

   ... <Lots more output>
	  

The timing reported for the first character, 'F', is 1100μs—in the synchronized version it was 1056μs. The global quantum was set to 100μs, which means that other threads may have a delay of up to 100μs before they can run, affecting the time they will report for their actions.

If the quantum is changed from 100μs to 10ms, the change is more dramatic, as shown in Figure 9.5.

$ .build/sysc-models/decoup-soc simple.cfg progs_or32/uart-loop

             SystemC 2.2.0 --- May 16 2008 10:30:46
        Copyright (c) 1996-2006 by all Contributors
                    ALL RIGHTS RESERVED

   ... <Or1ksim initialization messages>

Char F read at  541041666667 ps
Read: 'F'
Char written at 551041600 ns
Char a read at  641041686667 ps
Read: 'a'
Char written at 651041620 ns
Char r read at  1471041676667 ps
Read: 'r'
Char written at 1481041600 ns
	  

The time taken to write the first character is now 10ms, completely dominated by the quantum. The typing of characters at the xterm is notably sluggish.

This is characteristic of loosely timed models with temporal decoupling. The objective is to model the gross behavior of the system with a reasonable view of the timing, such that events happen in the correct sequence. However detailed timing can be sacrificed in the interest of greater model performance.

The value for the global quantum is a subjective choice. In this case, with a busy polling UART loop back function, any delays were wasted in additional polling cycles, so a small quantum was appropriate.

In a more realistic scenario, the UART would be interrupt driven (or at least not polled continuously). Very likely the UART would only be lightly used, while other parts of the system were working. Under such circumstances, a global quantum of 100-500μs (10%-50% of the time to put one character on the UART) would be reasonable. The timing of characters output would be out by up to 100%, but the model would gain from fewer synchronizations.

In other scenarios an even higher quantum could be justified—for example if the UART were only for occasional diagnostic output, where sluggishness did not matter. However when modeling a 100MHz ISS as part of the SoC, the benefits of such large global quantum values would be minimal.

Beware that an excessively large quantum may break software with timing dependencies. It may mean that interrupt sequences do not arrive in a reasonable order, or flood in all at once. An example of this is shown in Chapter 10.

The other step to take to improve the system would be to move to an exclusively TLM 2.0 model. The SystemC buffer is a good way to model the UART to terminal connection. However by using a TLM 2.0 socket in each direction, the UART could adopt temporal decoupling, giving further improvement in the overall model.