Conference on Adaptive Hardware and Systems (AHS'14) - Why FlexTiles uses OVP for Simulation

www.flextiles.eu
FlexTiles
FlexTiles Simulating Environment based
on Open Virtual Platforms (OVP)
Stephan Werner (KIT)

2 /
TheinformationcontainedinthisdocumentandanyattachmentsarethepropertyofFlexTilesconsortium.Youareherebynotifiedthatanyreview,dissemination,distribution,
copyingorotherwiseuseofthisdocumentmustbedoneinaccordancewiththeCAoftheproject(TRT/DJ/624412785.2011).Templateversion1.0
Outline
Outline
 Why using OVP?
 Introduction to FlexTiles Platform
 Implementation in OVP
 WebGUI
 Integration in toolchain

3 /
Why using OVP
Why using OVP:
 Very complex software
 OS
 Management services
 Ressource Managers
 User applications in Virtual Platforms
 Hardware not fully integrated
 Making a cycle-accurate model is not possible
 Possible: modeling the expected behavior (register set, protocols, etc.
 Our focus: Rapid Prototyping of complex software
 Simulation should run as fast as possible
 OVP: binary translation of cross-compiled code by morphing
 Cycle accuracy is not needed
 OVP is right choice for our application

4 /
Introduction to the FlexTiles Platform
Introduction to the FlexTiles Platform: Hardware
 GPPs
 MicroBlazes executing CompOSe
 One Monitoring Core
 DSP
 Icyflex 4
 eFPGA
 Accelerator Interface
 Virtualizing DSPs and accelerators
 Network Interfaces
 Abstraction for different NoCs
 NoC
 View in HW: DMAs
 View in SW: FIFOs

5 /
Introduction to the FlexTiles Platform: Hardware
Homogeneous
GPP nodes
Heterogeneous
accelerators
nodes
GPP Node
AI
DSP
Node
NI
GPP Node
NI
NoC
NI NI NI
AI AI
NI
Config. Ctrl.
DDR Ctrl.
NI
GPP Node
NI
I/O
NI
Generic
Interfaces
eFPGA Domain (Reconfigurable
HW acc.)
Dedicated
Accelerator
Node
Dedicated
Accelerator
Node

6 /
Introduction to the FlexTiles Platform
Introduction to the FlexTiles Platform: Software
 CompOSe
 Real-time OS
 Guaranteed real-time
 FIFOs
 Software view to NoC
 Cyclo-static dataflow
 Programming model
 ELF-bundles
 Contains information about the different configurations of the CSDF model
 Contains all executables
 Virtualization Layer
 Manages task migration and (re-)distribution
 Runs as priviledged service

7 /

8 /
Programming Model: CSDF

9 /
Programming Model: CSDF

10 /
Implementation in OVP
Implementation in OVP: Outline
 GPPs running the OS
 The Monitoring Core
 DMA-support as used for FIFOs
 Accelerator Interface
After implementation:
 WebGUI
 Integration in toolflow

11 /
Implementation in OVP: GPP
 MicroBlaze-model in OVP available
 Same (cross-compiled) code is executed
 Timer has to be adapted
 CompOSe executed
 Virtualization layer
 Test environment
 Can be connected to GDB
NI
NoC
GPP Core
Instruction
Cache
Local
Data Memory
Peripherals
IT / event
iNoC
Control Sync
Instruction
DMA
Supervisor

12 /
// FOR ALL CORES
for (index=0; index<CORES; index++){
...
////////////////////
// BUSES
////////////////////
bus[index] = icmNewBus( busName, 32);
////////////////////
// PROCESSORS
////////////////////
cpu[index] = icmNewProcessor(
cpuName, // CPU name
"microblaze", // CPU type
0, // CPU cpuId
0, // CPU model flags
32, // address bits
microblazeModel, // model file
"modelAttrs", // morpher attributes
SIM_ATTRS, // attributes
cpu_attr, // user-defined attributes
microblazeSemihost, // semi-hosting file
"modelAttrs" // semi-hosting attributes
);
icmConnectProcessorBusses(cpu[index], bus[index], bus[index]);
…

13 /
// FOR ALL CORES
...
////////////////////
// MEMORY
////////////////////
localMem[index] = icmNewMemory(memName, 0x7, MICRO_SIZE);
icmConnectMemoryToBus( bus[index], "mp1", localMem[index], MICRO_BASE);
icmConnectMemoryToBus( bus[index], memportName, shared, SHARE_BASE);
if(!icmLoadProcessorMemory(cpu[index], application[index], False, False, True))
return -1;
////////////////////
// TIMERS AND INTS
////////////////////
timer[index] = icmNewPSE(
timerName, // name
//timer_path, // model
"../Peripherals/Timer/pse.pse",
timer_attr, // attrlist
0, // semihost file
0 // semihost symbol
);
icmConnectPSEBus( timer[index], bus[index], "plb", 0, TIMER_BASE, (TIMER_BASE+TIMER_SIZE-1));
…

14 /
// FOR ALL CORES
...
irq[index] = icmNewNet(irqName);
icmConnectProcessorNet( cpu[index], irq[index], "Interrupt", ICM_INPUT);
icmConnectPSENet( timer[index], irq[index], "Interrupt", ICM_OUTPUT);
////////////////////
// UART
////////////////////
uartAttr[index] = icmNewAttrList();
icmAddStringAttr(uartAttr[index], "outfile", uartAttrName);
uart[index] = icmNewPSE(
uartName, // name
uart_path, // model
uartAttr[index], // attrlist
NULL, // semihost file
NULL // semihost symbol
);
icmConnectPSEBus(uart[index], bus[index], "plb", 0, UART_BASE, (UART_BASE+UART_SIZE-1));
...
}

15 /
// FOR ALL CORES
...
#ifdef DEBUG
if(index==DEBUG_CORE){
cpu[index] = icmNewProcessor(
cpuName, // CPU name
"microblaze", // CPU type
0, // CPU cpuId
0, // CPU model flags
32, // address bits
microblazeModel, // model file
"modelAttrs", // morpher attributes
ICM_ATTR_DEBUG, // attributes
cpu_attr, // user-defined attributes
microblazeSemihost, // semi-hosting file
"modelAttrs" // semi-hosting attributes
);
}else{
#endif
...
}

16 /
Implementation in OVP: Monitoring Core
 Not every GPP can have an UART
 Hardware limited
 Monitoring Core gathers the output
 Only GPP with I/O
 Connected via FSL to other GPPs
 On OVP: UART
 On board: Ethernet to PC
 Same operations run in OVP and on board
 getfsl, putfsl
CompOSe CompOSe
Monitoring
Core
CompOSe
UART
(OVP)
(Board)

17 /
Implementation in OVP: Monitoring Core
// FOR ALL CORES
...
//connections to central monitoring core; limitation: 16FSL links
//Monitor core is last core created, its link is defined by FSL_MONITOR, tile fsl connect to this id and putfsl sends to it
//FSL_MONITOR needs to be set to the # of the last core, which equals CORES
if(index!=FSL_MONITOR){
char monitorPort[64];
tfsl[index] = icmNewFifo(fsl_ToMonitor_Name, 64, 128);
sprintf(monitorPort, "MFSL%d", FSL_MONITOR);
icmConnectProcessorConn(cpu[index], tfsl[index], monitorPort, ICM_OUTPUT);
ffsl[index] = icmNewFifo(fsl_FromMonitor_Name, 64, 128);
sprintf(monitorPort, "SFSL%d", FSL_MONITOR);
icmConnectProcessorConn(cpu[index], ffsl[index], monitorPort, ICM_INPUT);
}
if(CORES==index+1){
char tilePort[64];
for(i=0;i<CORES;i++){
if(i!=FSL_MONITOR){
sprintf(tilePort, "SFSL%d", i);
icmConnectProcessorConn(cpu[FSL_MONITOR], tfsl[i], tilePort, ICM_INPUT);
sprintf(tilePort, "MFSL%d", i);
icmConnectProcessorConn(cpu[FSL_MONITOR], ffsl[i], tilePort, ICM_OUTPUT);
}
}
}
...
}

18 /
Implementation in OVP: DMA-support

19 /
Implementation in OVP: DMA-support
 Per DMA this is needed:
 One CMI: input memory
 One CMO: output memory
 Adress table:
 Local addresses
 Remote addresses
GPP local memory
CMI
CMO
DMA
///////////////////////////////
// DMA Peripheral
///////////////////////////////
// instantiate the peripheral
icmAttrListP config = icmNewAttrList();
icmAddUns64Attr(config, "id", 1);
icmPseP dma = icmNewPSE("dma", "../Peripherals/DMA/dma.pse",
config, 0, 0);
icmConnectPSEBus(dma, bus[2], "slave1", False,
mb0_dma0_BASEADDR, mb0_dma0_BASEADDR+7);
icmConnectPSEBus(dma, bus[2], "master1", True, 0x00000000,
0xFFFFFFFF);
icmConnectPSEBus(dma, bus[0], "slave0", False,
mb1_dma0_BASEADDR, mb1_dma0_BASEADDR+7);
icmConnectPSEBus(dma, bus[0], "master0", True, 0x00000000,
0xFFFFFFFF);

20 /
Implementation in OVP: Accelerator Interface
NI
NoC
Output
Data
DMA
DMA
data
out
req
FIFO
Input
Data
DMA
DMA
data
in
req
FIFO
datard
ctrlwr
Accelerator
Output Ch.Input Ch.
datawr
ctrlwr
Input
Config
DMA
DMA
cfg
req
FIFO
Config.Ch.
configwr
configwrconfigrd
ctrlwr
Work
req
FIFO
ctrlwrctrlrd
controlwrite/statusread
Synchronization /
Notification
read.writenotification
configwrsend
sync
Control / Status Channel
memctrl
memctrl
Debug
Ch.
write/readdebug
notificationread

21 /
EXPLANATION IN COMBINATION WITH LIVE-
PRESENTATION OF CODE

22 /
 AI implemented as peripheral in OVP
 Runs seperately from GPP simulation
 Algorithm of accelerator is executed on host natively
 Fast simulation
 Can be used as template for accelerators
 Insert algorithm in function start_calc()

23 /
Usability
WebGUI
 Generation of Hardware-Architecture

24 /
Usability
WebGUI
 Application-Binding

25 /
Usability
WebGUI
 Simulation in WebGUI

26 /
Integration in toolchain

27 /

28 /
Thank you for your attention
Questions ?

Conference on Adaptive Hardware and Systems (AHS'14) - Why FlexTiles uses OVP for Simulation

More Related Content

Similar to Conference on Adaptive Hardware and Systems (AHS'14) - Why FlexTiles uses OVP for Simulation (20)

More from FlexTiles Team (16)

Recently uploaded (20)

Conference on Adaptive Hardware and Systems (AHS'14) - Why FlexTiles uses OVP for Simulation