²ÝÁñÉçÇø

This bi-annual newsletter provides you with easy access to ASIP related resources. This issue includes the following topics:  

• Technology Feature: Fast Context Switching and Multi-Threading

• What¡¯s New: 2017.03 & 2017.09 Release Update

• Additional Resources: White papers, Webinars & Customer Stories  

Technology Feature: Fast Context Switching and Multi-Threading

ASIP Designer? comes with a rich set of example processor models provided in source code, which serve both as a modeling reference as well as a starting point for customer designs.

In previous issues of the eUpdate Newsletter we already covered the subject of data-level parallelism and instruction-level parallelism, including the corresponding example models. In this issue we will look at example processor models that demonstrate how to do a fast context switch. These models share as a common feature that registers are duplicated per context.  This duplication makes it possible to quickly switch from one thread of execution to another.  The motivation for requiring a fast context switching mechanism can be diverse, but broadly speaking we can make a distinction between

• Fast context switching upon an interrupt, or

• Switching between the multiple contexts in a multi-threaded processor

Before entering into these cases, let us look at how we can model a processor that has multiple register contexts. In the nML model, only one set of registers is declared.  These registers are used to define the instructions. In nML, additional copies of a register, sometimes called shadow registers, can easily be created by adding the additional_register_contexts property to the processor model. Assume that a processor has a register file R[4] and single field register SP, then the following property will result in the automatic creation of three shadow registers for both R[4] and SP, thus creating a total of four contexts:

                     additional_register_contexts : 3 ;

If for certain registers, we want to keep a single copy that is shared by all contexts, we must add the following exclude property:

                    exclude_from_additional_register_contexts : SP ;

Once the multiple register contexts have been created, we must decide how to switch from one context to the next. Using Figure 1 below for reference, we will look at different ways to generate the context select signal that steers the context multiplexor CM.

To understand the concept of fast context switches upon accepting an interrupt, ²ÝÁñÉçÇø¡¯ Tnano 16-bit microcontroller example is well suited. The context select signal is driven by the processor control unit (PCU).  When the PCU decides to accept an interrupt, the following actions are taken:

• A jump to the start address of the interrupt service routine is initiated

• Issuing of instructions is stopped until the first instruction of the service routine is fetched.  This flushes the pipeline

• In the meantime, the context select signal is set to a new context.  From then on, the instructions of the service routine operate on the shadow register

This achieves a fast context switch, which takes only a few clock cycles.

Multi-threading architectures can execute multiple threads in a concurrent way.  One popular use of this technique is to hide latencies of the pipelined data path and/or latencies of the memory. Instead of waiting for a value that is still being computed on the data path or that is being loaded from the memory, the processor switches to another thread.  When control returns to the first thread at a later point, that value will have been computed or loaded.

Such multi-threading is addressed by a second example processor, ILX. ILX is a variant of the DLX 32-bit microcontroller, to which interleaved multi-threading has been added. The original DLX has a pipeline with the following stages: instruction fetch (IF), instruction decode (ID), execute (EX), memory access (ME) and register write back (WB).  Registers are written in WB and are read in the ID stage, so there is a three-cycle dependency hazard. In the DLX model, the pipeline is fully protected by adding either a register bypass or by adding stalling logic for each hazard. Different to that, in the ILX model we execute four threads and use a round-robin schedule where the instructions from the different threads are interleaved on a cycle-by-cycle rhythm. This is depicted in Figure 2.

As you can see, two instructions from the red thread are now separated by three instructions from other threads.  Due to the multi-threading, the hazard is no longer present, and the bypasses and stalling logic can be removed.  Instead, we now need to control the context select signal in each stage separately. As you can see in Figure 3, in cycle 3, the red thread is in the WB stage while the yellow thread is in the ID (read) stage. 

What¡¯s New in ASIP Designer?