Schaumont, Figure 9.1 - The hardware/software interface

Figure 9.1 presents a synopsis of the elements in a hardware/software interface

the function of the hardware/software interface is to connect the software application to the custom-hardware module; this objective involves five elements:

Schaumont, Figure 9.2 - Synchronization point

synchronization: the structured interaction of two otherwise independent and parallel entities

• in figure 9.2, synchronization guarantees that point A in the execution thread of the microprocessor is tied to point B in the control flow of the coprocessor

Schaumont, Figure 9.3 - Dimensions of the synchronization problem

three orthogonal dimensions of the synchronization problem:

• time: time granularity of interactions
• data: structural complexity of transferred data
• control: relationship between local control flows

semaphore: a synchronization primitive S to control access over an abstract, shared resource, by operations:

• P(S): (try to) get access, wait if S=0, else S←0
• V(S): release resource, S←1

Schaumont, Figure 9.4 - Synchronization with a single semaphore

int shared_data;
semaphore S1;

entity one {
  P(S1);
  while (1) {
    short_delay();
    shared_data = ...;
    V(S1);                 // synchronization point
  }
}

entity two {
  short_delay();
  while (1) {
    P(S1);                 // synchronization point
    received_data = shared_data;
  }
}

Schaumont, Listing 9.1 - One-way synchronization with a semaphore

synchronization points: when entity one calls V(S1), so unlocking the stalled entity two

• this scheme only works under the assumption that entity two is faster in reading the shared data than entity one is in writing it

just assume the opposite, viz. move the short_delay() function call from the while-loop in entity one to the while-loop in entity two ...

• generally, in the producer/consumer scenario, both entities may need to wait for each other

the situation of unknown delays can be addressed with a two-semaphore scheme

• S1 is used to synchronize entity two, S2 is used to synchronize entity one

Schaumont, Figure 9.5 - Synchronization with two semaphores

int shared_data;
semaphore S1, S2;

entity one {
  P(S1);
  while (1) {
    variable_delay();
    shared_data = ...;
    V(S1);   // synchronization point 1
    P(S2);   // synchronization point 2
  }
}

entity two {
P(S2);
  while (1) {
    variable_delay();
    P(S1);   // synchronization point 1
    received_data = shared_data;
    V(S2);   // synchronization point 2
  }
}

Schaumont, Listing 9.2 - Two-way synchronization with two semaphores

figure 9.5 illustrates the case where:

• on the first synchronization, entity one is quicker than entity two, and the synchronization is done using semaphore S2, whereas
• on the second synchronization, entity two is faster, and in this case the synchronization is done using semaphore S1

a handshake: a signaling protocol based on signal levels; the most simple one is:

Schaumont, Figure 9.6 - One-way handshake

one-way handshake has a similar limitation as one-semaphore synchronization, the solution is:

Schaumont, Figure 9.7 - Two-way handshake

computational speedup is often the motivation for the design of custom hardware

• however, the hardware/software interface is also relevant to the resulting system performance

communication constraints need to be evaluated as well!

• e.g., assume the custom-HW module in fig. 9.8 takes 5 clock cycles to compute the result, with a 320-bit total data transfer size per execution: can the system actually perform at a rate of 320/5 = 64 bits per cycle?

Schaumont, Figure 9.8 - Communication constraints of a coprocessor

Schaumont, Figure 9.9 - Communication-constrained system vs. computation-constrained system

the number of clock cycles needed per execution of the custom hardware module is related to its hardware sharing factor (HSF) =_def   number of available clock cycles in between each I/O event

Schaumont, Table 9.1 - Hardware sharing factor

coupling indicates the level of interaction between execution flows in software and custom hardware

• tight = frequent synchronization | data transfer
• loose = the opposite

coupling relates synchronization with performance

Schaumont, Table 9.2 - Comparing a coprocessor interface with a memory-mapped interface

Schaumont, Figure 9.10 - Tight coupling versus loose coupling

example: difference between

• coprocessor interface: attached to a dedicated port on the processor
• memory-mapped interface: attached to the memory bus of the processor

N.B.: a high degree of parallelism in the overall design may be easier to achieve with a loosely-coupled scheme than with a tightly-coupled scheme