System-on-ChipDesignHW/SWInterfacesandCommunica;ons

HaoZhengCompSci&EngUofSouthFlorida

1

SystemStructuralModel

2

Bridge

HW

P5

HW

P3P4

P1P2

CPU MemArbiter

BasicElementsofHW/SWInterfaces

3

1.On-chipcommunicaConfabrics,ex.buses

BasicElementsofHW/SWInterfaces

4

2.CPUinterfaceforSWtocommunicatewithcustomHW.

BasicElementsofHW/SWInterfaces

5

3.HWinterfaceforcustomHWtocommunicatewithCPU.

BasicElementsofHW/SWInterfaces

6

4.SWdriverconvertsSWIOoperaConstooperaConssupportedbyCPUinterface.

BasicElementsofHW/SWInterfaces

7

5.ProgrammingmodelwhereSWrunningCPUusestocontrolcustomHWmodule.

Synchroniza;onSchemes

8

SynchronizaConisnecessaryforeffecCvecommunicaCons,i.e.datatransferredbetweenCPUandHWcorrectly.

SynchronizaConispartofinterfaceimplementaCon.

Synchroniza;onSchemes

9

Time:howsynchronizaConisdefinedoverCme.

Synchroniza;onSchemes

10

Data:howdataisrepresentedinsynchronizaCon.

Synchroniza;onSchemes

11

Control:howsynchronizaConisimplementedlocallyinindividualmodules..

Semaphores

•  Usedtocontrolofaccessestosharedresource.•  TwoopsonsemaphoreS:– P(S):acquireS.– V(S):releaseS.

•  Howcanweensureanorderbetweenthread 1&2?

12

thread1:…P(S);x++;V(s);…

thread2:…P(S);x=x–2;V(s);…

Semaphores

13

intshared_data;semaphoreS;

enCtyone{P(S);while(1){short_delay();shared_data=…;V(S);}}

enCtytwo{short_delay();while(1){P(S);rd=shared_data;}}

Semaphores

•  Semaphorescanonlyguaranteeexclusiveaccesstosharedresources.– Difficulttocontrolprecisedatatransfer– MulCplesemaphorescanbeused,butnotelegant.

•  Handshaking:asignalingprotocolbetweentwoenCCestocoordinatedatatransfers.– CanhandleenCCeswithdifferentspeeds.

14

One-WayHandshake

15

AssumethatenCtytwoisslower.

Two-WayHandshake

16

X

Two-WayHandshakeforDataTransfer

17

reqackdata

XXXXX d1

clk

req

ack

data

Src Dest

XXX

Communica;onConstrainedvsComputa;onConstrained

18

SystemperformanceshouldconsiderbothcomputaConperformanceandcommunicaConoverhead.

Communica;onConstrainedvsComputa;onConstrained

19

TightandLooseCoupling

20

Coupling:thelevelofinteracConsbetweentwocomponents.

DegreeofcouplingaffectschoiceandimplementaConofsynchronizaCon.

DedicatedvsSharedInterfaces

21

282 9 Principles of Hardware/Software Communication

Table 9.2 Comparing acoprocessor interface with amemory-mapped interface

Coprocessor Memory-mappedFactor interface interface

Addressing Processor-specific On-chip bus addressConnection Point-to-point SharedLatency Fixed VariableThroughput Higher Lower

describe in detail in the next Chapters – are called memory-mapped interface andcoprocessor interface respectively. Table 9.2 compares the key features of these twointerfaces.

These two interfaces each take a different approach to synchronization. In thecase of a coprocessor interface, synchronization between a hardware module andsoftware is at the level of a single instruction. Such a coprocessor instructiontypically carries both operands (from software driver to hardware coprocessor)as well as result (from hardware coprocessor to software driver). In the case ofa memory-mapped interface, synchronization between a hardware module andsoftware is at the level of a single bus transfer. Such a bus transfer is unidirectional(read or write), and either carries operands from the software driver to the hardwarecoprocessor, or else results from the hardware coprocessor to the software driver.Clearly, the use of a coprocessor interface versus a memory-mapped interface implya different style of synchronization between hardware and software.

A given application can use either tight-coupling or loose-coupling. Figure 9.10shows how the choice for loose-coupling of tight-coupling can affect the latenciesof the application. The left side of the figure illustrates a tight-coupling scheme.The software will send four separate data items to the custom hardware, each timecollecting the result. The figure assumes a single synchronization point which sendsthe operand and retrieves the result. This is the scheme that could be used by acoprocessor interface. The synchronization point corresponds to the execution of acoprocessor instruction in the software.

The right side of the figure illustrates a loosely coupled scheme. In this case, thesoftware provides a large block of data to the custom hardware, synchronizes withthe hardware, and then waits for the custom hardware to complete processing andreturn the result. This scheme would be used by a memory-mapped interface, forexample using a shared-memory.

Loosely-coupled schemes tend to yield slightly more complex hardware designsbecause the hardware needs to deal more extensively with data movement betweenhardware and software. On the other hand, tightly-coupled schemes lean moreon the software to manage overall system execution. Achieving a high degree ofparallelism in the overall design may be easier to achieve with a loosely-coupledscheme than with a tightly-coupled scheme.

Cghtcoupling

loosecoupling

NatureofcouplingaffectstheorganizaConofHW/SWinterfaces

ReadingGuide

•  Chapter9,theCoDesignbook.

22