Hardware-in-the-loop Simulation for CPU-GPU Heterogeneous Platforms

文档下载：http://download.csdn.net/detail/lpn709695399/9633997

Hardware-in-the-loop Simulation for CPU/GPU Heterogeneous Platforms

2014年 首尔大学


ABSTRACT
cpu/gpu heterogeous platforms + full system simulator + running complete software stacks without modification
异构平台、FS仿真模式、完全支持以前的程序
但是目前异构系统的仿真环境十分罕见
本文提出hardware-in-the-loop，集成GPU hardware入FS simulator
CPU + 开发板（包含GPU）


实验中，GPU采用Exynos 4412的开发板，该开发板集成Mali GPU，CPU仿真环境为4核ARM，可以运行Android app，1.5M cycles per second


1. Introduction
CPU+GPU:
Tegra from NVIDIA
Snapdragon from Qualcomm
Exynos from Samsung
目前，低功耗已经成为计算机系统设计的主要约束，多核异构系统将成为趋势


为了Architectural exploration, debugging and performance monitoring，全系统模拟器为常用工具，软件程序不用修改就可以运行


CPU模拟器基本成熟，GPGPU-sim、Barra均为针对NVIDIA GPU的模拟器，但运行速度仅为k cycles per second，随着核数的增加，速度会更慢。但基本没有公开的GPU模拟器，如ARM的Mali，Imagination的PowerVR，Qualcomm的Adreno


集成硬件GPU如FS simulator中的挑战：
1. 不能暂停、继续，不方便调试；将开发板集成到CPU模拟器中也是一大挑战
2. 模拟器与硬件都有各自的Memory，如何同步、维护一致性
3. 模拟器需要与GPU协同工作，保证其正确性（比如中断的建模，不违反先后执行顺序，并解决死锁的可能）


优势： 第一个HIL模拟器，不用修改程序就可以执行原有程序，GPU、Linux、Android不需用修改驱动。提供了Instruction-level accuracy，提供体系结构探索的环境，如修改CPU核数或GPU类型


问题：若没有事件监听，GPU内部的通信方法不能评估


这项技术不是为了进行体系架构的探索，而是为了软件开发、调试、性能监测
以inaccuracy of communication workload modeling为代价，追求fast simulation


2. Related work
CPU模拟：如SimpleScalar[3]，M5[4]
HW/SW协同模拟器：[5][6][7] -> 可以系统地结合硬件环境，进行软件仿真


对于ARM Mali GPU，没有相关GPU模拟器，仅有commercial RTL可以使用，当其核数增加时，仿真速度非常慢，促进SCHP(Single Chip Heterogeneous Processor) simulator的产生，但是仿真速度比较慢
------------>lock-step fashion(何意)


HW/SW emulation的产生是为了替换对RTL的FPGA原型验证
[12]中提出一种Standard Co-emulation Modeling Interface(SCE-MI)，定义了仿真器与FPGA验证接口的连接（SW/HW间通过transactor传递messages，类似FIFO）
主要针对IP的设计，综合至FPGA，具有完全的控制权，比如可以控制硬件的时钟来控制硬件的操作，或者，增加tracing和debugging的逻辑


相反，本文的设计目的是不涉及GPU的仿真模型，针对特定的应用，进行CPU体系结构的探索，将CPU模拟器与现有的GPU硬件环境连接起来。集成不能控制和观察的GPU硬件环境，也不能外加逻辑，进行tracing和debugging


ARM具有Stramline Performance Analyzer[13](分析报告的基于时间的筛选，用于时间测量和快速热点分析的可伸缩、跨部分的标记)，DS-5(development studio) debugger，分析ARM CPUs和Mali GPUs


PVRTune[11]可以对PowerVR GPU进行profile，仅针对已有的CPU/GPU系统板进行分析，不能对CPU或者任意一个组件进行仿真验证，并且，需要额外版本的GPU驱动进行performance counters的记录


我们的目的是进行design space的探索，并甄别CPU/GPU系统中的性能瓶颈


3. CPU/GPU Heterogeneous System
将图形计算、缓冲更新等任务迁移到GPU中，不仅可以加速显示、游戏和视频应用的速度，并且可以提升系统的吞吐速率，并减少功耗，延长电池使用寿命
3.1 Typical Execution Scenario of the Systems
本实验环境中，采用ARM CPU和Mali GPU，采用Linux kernel 和 Android，执行Android app，调用Linux kernels完成功能。


假定Android app调用OpenGL ES API(The Standard for Embedded Accelerated 3D Graphics, a royalty-free, cross-platform API for full-function 2D and 3D graphics on embedded systems - including consoles, phones, appliances and vehicles. 图形软硬件行业协会Khronos集团定义推广，主要关注图形和多媒体方面的开放标准。OpenGL ESOpenGL ES 是免授权费的，跨平台的，功能完善的2D和3D图形应用程序接口API，它针对多种嵌入式系统专门设计 - 包括控制台、移动电话、手持设备、家电设备和汽车)。图形计算函数被翻译为多个ioctl()系统调用，具有多种commands和arguments
commands:
mali_core_session_add_job(插入GPU任务队列) -> mali_core_subsystem_schedule(检查idle_render_user_list，检查是否有空闲的render unit) 如果有 -> subsystem_(gp/pp)_start_job()，参数为job和render


wait命令，调用_mali_osk_notification_queue_receive()，查看现在是否有notification queue，如果没有，睡眠，知道_mali_osk_notification_queue_send()调用


4. The Proposed Technique
4.1 Overall HIL Simulation Environment
CPU由gem5实现，采用Full System模式，instruction-accurate加速仿真（准确性会降低），运行Linux kernel和Android


SytemC搭建总线和存储器模型


在CPU/GPU开发板上运行GPU code


此环境中的关键是gem5 simulator interface，采用socket communication（GPU仿真在真正CPU上运行，监听socket --- CPU解socket？）
4.2 HIL Simulation Interfaces
优势：不用修改源代码，在Linux kernel对GPU驱动定义CPU/GPU交互点，如gpu_ioctl()和gpu_mmap()


硬件环境中，CPU上运行GPU simulation interface


4.2.1 Gem5 Extension for GPU HIL Simulation
Gem5 simulator递归执行模拟例程，在例程中，执行（以时间顺序排列的）事件队列中的第一个事件，每个事件转为相应service routine，由模拟器执行。
常见的事件有TICK_EVENT，service routine是tick_code()，任何中断发生，首先执行此routine，调用相关的service routine，即tick_code()。接着，从PC提取相关指令，并执行。最后，为了提升时间模型的准确性，插入新的事件TICK_EVENT，该事件包含一个时间戳（current time + latency）


程序执行时，需要判断当前指令是否指向预定义的gpu调用程序，如果是，调用GPUClientRoutine()，此函数为gem5 simulation interface的关键，而且可以采用readIntReg()和readMem()来读取相关参数


4.2.2 Memory Synchronization
CPU与GPU共享存储器，但分开在模拟器和硬件中，这两份存储器内容一致，需要进行同步以保证正确性


gpu_ioctl()函数输入数据为模拟器存储器，输出为硬件存储器。在GPU开始工作前，需要将数据从模拟器搬运到硬件中，GPU simulation interface必须通过memcpy()来更新硬件存储器，任务完成后还需要将硬件存储器修改数据搬运到模拟器中


GPU需要从模拟器中申请frame buffer，每个核(core)，或PP(pixel processor)会被分配一个tile，每个PP处理完后，结果也存储在PP内部的tile中，在某些GPU中，比如Mali，只有内容改变的tile buffer才会被更新至相应的frame buffer中


本仿真环境中，为减少存储同步overhead，GPU interface比较原先的frame和现在的frame的内容，仅发送变化了的值给gem5 interface。可能underestimate真正的总线传输，但如果传输所有的frame，会overestimate。后期将对此问题进行处理


4.2.3 Address Translation Table
GPU simulation interface从ioctl()和mmap()中获取GPU虚拟地址，GPU simulator实为CPU的任务，所以并不能触及到GPU存储器的内容
而且gem5 simulator和板上的虚拟地址有可能不同


为解决这个问题，gem5 simulator interface 和 GPU simulator interface接口中都保留了GPU和CPU虚拟地址的转换表


4.2.4 Interrupt Modeling
通常情况下，CPU提供给GPU中断接口，CPU创建wait线程等待GPU运行结束信息，从而提升CPU的使用率。但因为中断为异步被动接收事件，保证其时间准确性的模型不易建立。（如果CPU在发送GPU调用后，做其他事情，GPU执行后返回的时间戳与gem5 simulator中时间不一致）


为解决这个问题，本文在GPU调用后，阻塞gem5 simulator，gem5 simulator接收到回复后，首先产生interrupt event，插入时间戳t1+δ


δ由硬件产生，但是并不包含PP之间的访存竞争时间，PP的ioctl()请求可能同时并发执行，因为PP共享资源，所以每个ioctl()请求平均时间可能大于单个ioctl()。为评估该时间，我们分析了有访存竞争和无竞争时的时间比率，在5节描述
4.3 An Example of HIL Simulation Scenario
gem5 simulator首先发送wait command，然后发送enqueue。


Mali GPU interface接收到wait后，创建wait线程，等待GPU执行结束，避免死锁，然后接收到enqueue，开始add_job(),schedule(),start_job()等


GPU执行时，首先执行MALI_PUT，GPU simulation interface从gem5 simulator存储器读取数据，更新Mali GPU的存储器；然后开始GP/PP_START，主线程sleep；GPU结束后，主线程被唤醒，想gem5发送结束信号；最终，gem5 interface发送MALI_GET，更新修改的存储器


4.4 Implementation Issues
因为模型搭建环境资源有限，不能执行所有的Android程序，如音频设备


实现中添加debugging mechanism，包含debugging function，如target instruction和memory addresses, reading register and memory contents, and instruction tracing using instruction stack, 而且还有save states of the board，从断点继续执行


4.5 Limitation
很难准确评估GPU的总线活动


5. Experiments
实验中，仿真Exynos 4412系统，4核ARM Cortex-A9 CPU + ARM Mali-400 MP GPU（4 Pixel Processors + 1 Geometry Processor），AXI连接，有256KB的片上存储器，使用ODROID-X开发板执行Mali GPU hardware，使用gem5 simulator来仿真ARM Cortex-A9 CPU
A pixel processor, such as the Mali-200 or Mali-400, performs rendering operations to produce a final image for display.


A geometry processor executes vertex shaders that typically contain transform and lighting calculations, and generates lists of primitives for a pixel processor to draw.
Lesson09:
gem5 simulation time占48%，Mali board interfacing占52%，仿真速度约为1.5M cycle per second，在Mali interfacing中，42.7%的时间用来数据同步


Cubic:
速度为0.8M cycle per second，因为存储器同步时间太长


评估contention overhead，修改Linux驱动中可用PP的个数，4000此ioctl()，δ'为4个PP时的时间，δ为1个PP的时间，比值作为t+aδ中的a


实际硬件与软件均调用相同次数的同一API，比较时间，得出时间准确性与gem5仿真一致，app执行时间越长，准确度越高。深度分析将在后期工作完成


6. Conclusion
7. Acknowledgement


问题：
GPU simulator如何运行
socket协议是什么
NIC采用哪个协议
simulator时间中如何考虑NIC带来的延迟
gem5 interface的比较时间是否影响评估结果
timestamp的格式
device的工作频率
δ如何获得
仿真中多少个PP运行
Figure 9看不懂