HSA DSE 初探索

本文主要将目前三种HSA模拟器设计文献进行翻译总结，文献请查看上传文件。

gem5-gpu: http://download.csdn.net/detail/lpn709695399/9620482

multi2sim: http://download.csdn.net/detail/lpn709695399/9621438

socrocket: http://download.csdn.net/detail/lpn709695399/9620483

http://download.csdn.net/detail/lpn709695399/9608852

gem5-gpu: A Heterogeneous CPU-GPU Simulator
-> 2013
集成CPU与GPU系统的模拟器，基于gem5(CPU)与GPGPU-sim(GPU)搭建
most memory accesses基于Ruby搭建，gem5中的可配置存储系统：
1. cache一致性
2. CPU/GPU共享虚拟地址，独享物理地址


可以运行CUDA 3.2的代码，非阻塞运行，CPU与GPU可并行运行，本文提供软件架构和性能分析，并提出扩展方案 <---如何实现非阻塞运行


1. Introduction
gem5为全系统多核模拟器，有多种CPU、指令集 和 存储模型；另外gem5支持面向对象的设计，灵活多变的配置方案。逐渐成熟的技术使得gem5成为评估通用CPUs和多核平台的主要工具。 <---是否包含ARM


GPGPU-sim为GPGPU的模拟器，为GPGPU的CU(compute units，如NVIDIA中的SM)和GPU的存储系统进行建模


gem5-gpu借鉴GPGPU-sim中的CU模型 和 gem5的CPU和存储系统模型
采用execution-driven simulation
trace-driven的prtition方法比较好
[1] MacSim中采用了更加细化的方法，相对于Multi2Sim和FusionSim，具有更灵活的存储架构和一致性协议，仿真时间比较长
优势：
1.Detailed cache coherence model
2.Full-system simulation
3.Checkpointing
4.Tightly integrated with the latest gem5 simulator
5.Increased extensibility of GPGPU programming model and entire system architecture
DMA engine可以对CPU和GPU地址空间进行数据搬运建模


2 Heterogeneous Computing
GPGPU计算是计算迁移（Computation Offloading）的代表
计算迁移：针对特定的工作任务，受当前计算系统资源的限制，需要将计算任务分配到其他外部平台，比如a cluster, grid, or a cloud。可以用到Artificial intelligence, Artifitial Vision and object tracking, or computational decision making
data-parallel image processing, scientific, and numerical algorithms


迁移到GPU的任务称为Kernel，Kernel可以分为许多线程，而只占用GPU一条指令的SIMT执行
Work units offloaded to the GPU are called kernels


CPU与GPU采用独立的存储空间时，GPU与CPU之间需要进行数据的搬运
程序迁移至GPU需要use-level calls，调用GPGPU的API（runtime），其中包含kernel-level驱动控制GPU设备。目前比较流行的runtime为CUDA和OpenCL


HSA fundation提出未来异构计算中统一存储方案（heterogeneous uniform memory access, hUMA）
[7]中NVIDIA也提出统一存储空间的方法UVA


gem5-gpu目的就是支持这种灵活、可扩展的编程模型和体系结构


3. The Giant's shoulders
3.1 gem5
gem5.org由学术界与工业界的许多实验室开发
gem5包含许多CPU，存储系统和指令集模型
two execution modes:
1) system call emulation： 系统调用仿真，可以执行User-level binaries调用emulated system calls <- 不是特别懂
2) full-system: 建模所有设备来boot并运行操作系统，提供检查点（checkpoint），可以有目的的进行仿真
优势：
1. 提供融合新体系架构机制，可以使用集成在gem中的EXTRAS接口例化外部代码 <- 如何添加
2. 集成了详细的cache和memory模拟器Ruby，Ruby是基于domain specific language, SLICC（用来描述cache一致性协议）开发的环境，目前还没有GPU的模型
3.2 GPGPU-Sim
[2] backed by a strong publication record
为现有的NVIDIA显卡进行建模
GPGPU-Sim将应用程序编译为PTX（NVIDIA中间指令集）或者汇编本地GPU机器码
GPGPU-Sim为线程分配逻辑、highly-banked regster file、特殊功能单元和存储器系统的计算流水进行功能和时序模型
GPGPU-Sim包含GPU的存储器、DRAM、cache模型
constant/scratchedpad/low-latency in-core cache/local/parameter/instruction/texture


GPGPU-Sim可以将源代码连接到为对应的GPGPU运行库
GPGPU-Sim是一个功能优先模拟器，先执行所有的指令，然后反馈给时间模拟器


GPGPU-Sim在为异构系统建模的缺陷：
1. 没有主CPU的时钟模型
2. 没有主设备拷贝函数的时钟模型
3. 严格的cache模型
4. 没有主设备间的交互模型


4. gem5-gpu architecture
GPU由许多CU组成，每个CU均有取指/译码逻辑、a large register file，许多执行通道（execution lanes, 多为32/64）
当读取global memory时，每个通道将各自地址发送到聚结器（coalescer），将所有的memory accesses指向相同的cache块，GPU也可以有自己的cache架构


4.1 gem5<-->GPGPU-Sim Interface
我们的目标之一是在gem5与GPGPU-sim间提供简洁的接口，在gem5中添加一条伪指令，简化DMA engine和GPU功能的调用
gem5-gpu将GPGPU-Sim对global address space的访问通过gem5接口映射到Ruby的访存指令


4.2 Memory System Modeling
gem5-gpu使用Ruby对CU存储器访问进行功能和时序的建模
load-store流水线在gem5中建模，包括coalescing, virtual address translation, and cache arbitration logic


gem5-gpu可以灵活修改通道的个数，CU的个数，缓存的架构等，未来将支持其他GPU模型


目前，GPGPU-Sim发送通用存储器指令给gem5，包含对global和constant存储器的访问
我们采用GPGPU-Sim对scratchpad和parameter存储器的访问
之后，我们将对texture和local memory的访问进行实现


gem5-gpu支持CPU与GPU进行统一存储，也可以独立存储


4.3 Detailed Cache Coherence Models
gem5-gpu采用cache一致性建模语言SLICC，配置gem5-gpu时，可以使用所有的cache一致性协议。 前提是为异构cache topology（不懂）


gem5-gpu添加了cache一致性协议：MOESI_hsc(heterogeneous system coherence with MOESI状态)
MOESI_hsc为CPU cache采用MOESI协议；对于GPU，添加L2 cache controller保证GPU与CPU L2 cache一致，GPU L1(write-through and valid and invalid states)在同步和kernal边界时将被清空


采用独立存储器时，需要显示地通过DMA进行数据搬运
gem5-gpu可以使用gem5提供的所有连接协议，包括mesh, torus, cross-bar （查）


4.4 Application Programming Interface
为了简化现有GPGPU的drivers和runtime的实现，gem5-gpu提供了简单的runtime和driver仿真模型，将统一的GPGPU application连接到gem5-gpu GPGPU runtime library中


当执行用户程序调用GPGPU runtime function时，执行gem5伪指令来仿真 （不懂）


5. Performance Validation
针对global memory performance，我们采用了memory microbenchmarks和Rodinia benchmark的子集[4]，包括coalescing, cache, off-chip latency和bandwidth


对NVDIA GTX 580进行GPGPU-Sim和gem5-gpu的建模


虽然gem5-gpu的运行时间比GPGPU-Sim差些，但提供了时钟模型，计算了数据搬运延迟和kernel的运行时间，GPGPU-Sim没有计算搬运时间


GPGPU-Sim中的CU寄存器处理采用PTX中间模型，而不是object code


6. Future work
缺陷：
1. 目前仅限x86 ISA，未来将支持ARM ISA
2. 仅支持CUDA，NVIDIA的GPGPU内核，未来将支持OpenCL
4. 仅支持GPGPU-sim，未来将支持其他GPU模型


Multi2Sim A Simulation Framework for CPU-GPU computing
-> 2012
建模方式不仅包括计算单元，也包括计算单元之间的交互
本文针对x86 CPU和 AMD Evergreen GPU指令集模拟，进行AMD Radeon 5870 Gpu的建模
针对仿真正确性，以及架构模拟的精确性，并使用AMD OpenCL benchmark库进行验证
仿真能力评估方式： 初期架构探索 + 性能范例


[12,13]提出了GPU仿真中的中间语言层（PTX）
但缺少 针对考虑ISA级的功能仿真及时钟精确架构仿真


本文结合 并行AMD Evergreen GPU集[3] 和 超标量、多线程、多核x86处理器
将描述指令流水和存储架构


Multi2Sim提供Linux命令行工具，对OpenCL不进行任何修改就可以执行，和支持程序性能评估的指令，程序优化，编译优化，硬件架构设计


2. The multi2sim project
初期，针对超标量、多线程、多核x86 CPU架构
仿真主要包括：
功能仿真：
模拟x86处理器上，翻译二进制文件，动态复现ISA级程序的执行
可以执行单线程benchmark（SPEC2006 and Mediabench），多线程benchmark（SPLASH-2 and PARSEC 2.1），自定义程序
架构仿真：
detailed or timing simulator，在功能仿真的基础上trace x86的指令，并trace处理器硬件结构每个时钟的活动
支持乱序执行，保持cache一致性，互联网络和其他特性
现在，Multi2Sim集成了商用AMD Evergreen GPU系列的许多可配置模型，和交互模型interaction model


GPU emulator traces Evergreen的指令，detailed simulator traces执行时间和架构状态
OpenCL(Open Computing Language)调用GPU的仿真


2.1 The OpenCL Programming Model
使用single-program multiple-data(SPMD)方法
OpenCL的kernel叫做work-items，可以访问私有存储器池（own pool of private memory），work-item在work-groups中
1. work-group中的work-item支持高效同步机制
2. work-group中的work-item可以低延迟访问local memory
所有的work-groups组成为ND-Range(grid of work-item groups)，共享global memory
2.2 OpenCL Simulation
CPU simulator调用OpenCL API，OpenCL runtime（libm2s-opencl.so）执行后，GPU simulator开始运行


3. Architectural simulation of an AMD Evergreen GPU
这部分主要描述硬件组件如何实现OpenCL kernel，包括指令流水，存储器，互联方法（大部分GPU提供商设为私密文件，不予公开）
3.1 The Evergreen GPU Architecture
GPU 包含 a ultra-threaded dispatcher, an array of independent compute units, and a memory hierarchy


ultra-threaded dispatcher:
对ND-Range处理，将等待的work-group分配到闲置的compute unit，从global memory hierarchy中读写数据，两级cache


计算单元由三个execution engines(control flow-CF, arithmetic-logic-ALU, and texture-TEX，分别执行不同的kernel)，一个local memory，一个register file


ALU包含a set of stream cores，每个stream core用来执行一条算术指令
ALU指令由5路VLSW束组成，编译过程中产生，VLSW上的每条指令分别执行，stream core执行
Evergreen GPU定义wavefront （a group of work-items）以SIMD的形式执行
每个work-item有各自的Private data，这种模式通过共用的front-end（不懂）简化了wavefront指令预取部件
3.2 The Evergreen Instruction Set(ISA)
当GPU simulator接收到OpenCL的Kernel，开始仿真时，模拟器开始循环 取指、译码、执行
Evergreen汇编使用基于clause格式，kernel以CF指令开始，影响主程序的控制流程，往global memory写数，向后期clause的转变（如ALU或TEX clause）
ALU clause负责指令执行和local memory的存取，TEX clause负责从global memory中读取数据


一个stream core一次只执行一个VLIW束，每个ALU label对应分配到指令的VLIW束（不太懂）
ALU的指令操作数可以通过PV(preveious vector)或PS(Previous Scalar)特殊寄存器，从上一条指令中获得


CPU可以初始化一块constant memory作为操作数来源（globally accessible）


从上面的描述中，我们可知其他高级中间语言的区别，如AMD的IL[4]和NVDIA的PTX[6]，如，在AMD Evergreen ISA中，仅有限个通用寄存器，所以生成的VLIW bundles优先，而且将机器码组合为clause也需要一定的规则。但总的来说，ISA许多属性在机器上直接执行，而存在中间代码时，不需要考虑。因此，ISA级的仿真可以有效地提升运算速度和准确性


3.2.1 Kernel Execution Model
OpenCL kernel is launched -> ND-Range configuration -> work-groups
work-groups可以被分配到单个compute unit，取决于4个限制：
i)   每个compute unit支持的最大work-group个数
ii)  每个compute unit支持的最大wavefront数
iii) 每个compute unit中寄存器数
iV)  每个compute unit中local memory大小
Multi2Sim可以权衡将多少work-group（maximize）分配到compute unit中，从而提升性能


每个work-group被分为多个wavefront，放入ready wavefront pool中，CF engine依据wavefront调度算法，从pool中选择wavefront，每个wavefront包含CF clause、ALU and TEX clause
wavefront调度算法是另外一个性能参数，Multi2Sim将其纳入


保证每次只有一个CF指令正在执行，避免分支预测和case预测。通过重叠不同wavefronts消除串行化的代价。Multi2Sim将决策重叠execution纳入
3.2.2 Work-Item Divergence
参考./GPU Branch Execution and Reduction Algorithms.pdf


work-item分支是单个wavefront中不同work-item执行时带来的副作用，为解决该问题，Evergreen ISA提供给每个wavefront一个active mask，active mask是个位图，标志哪个work-item正在工作，若inactive，相关的计算单元执行结果将被忽略，且不改变kernel状态


这种策略意在覆盖所有可能的执行路径，仅允许active（执行条件与预取指令流一致）的work-item，另外嵌套的分支需要active mask stack用来push/pop active masks。


Multi2Sim提供work-item divergence
3.3 The Instruction Pipelines
CF、ALU和TEX被组织为指令流水线（图5）
每条流水线中，需要确定调度策略（scheduling policies）、延迟、缓冲区大小


CF clause:
fetch stage: 每个时钟从wavefront pool中选取一个wavefront，每个CF instruction进行wavefront的切换
decode stage: 以Round-robin方式进行译码（负载均衡，权重轮询更优）
触发secondary clause（ALU或TEX）
保持execute state直至secondary clause结束


其他wavefront可以在中间执行
CF指令按顺序结束，结束后wavefront返回wavefront pool备选


Global memory writes 在CF engine中执行
ALU clause:
译码后的VLIW指令本分放到VLIW bundle buffer中
read stage: 读取VLIW bundle，并为wavefront中的work-item从register file和/或local memory中读取源操作数
execute stage: 从VLIW bundle中读取，在每周期分发到stream cores
若stream core中的寄存器资源不能满足wavefront的需求，wavefront被分为subwavefronts，每个subwavefront的work-item数与每个compute unit中的stram core数一致
write stage: 计算结果被写回目标地址（register file或local memory）
TEX clause:
执行从global memory取指令的操作
TEX指令字在预取、译码后存入TEX instruction buffer

read stage: wavefront中每个work-item的存储器地址从register file中读取，并向global memory发起读操作
write stage: 读回的数据写入register file
3.4 Memory Subsystem
GPU memory subsystem对于data storage and transfer有不同的组件
对于multi2sim，memory subsystem有较强的可配置能力，如cache层级，存储容量，block size，bank数目，ports


Register File: no contention，支持不同wavefront，TEX和ALU同时访问
Local Memory: 每个CU都有各自的local memory，当出现冲突时，进行串化，另外考虑到memory coalescing（合并内存）。可配参数有latency, number of banks, ports, and allocation chunk size
Global Memory: 所有的CU都可以访问，延时由硬件架构来减少，可配参数有cache levels和interconnects。每个CU有各自的L1，共享L2。L1的管理方法与CPU一致，硬件管理
Interconnection networks: 不同层级之间的连接网络，通过switch实现点对点连接
Cache access queues: 访问cache有缓冲区buffer来存储访问序列。一方面在流水线中Prevent stalls，另一方面解决memory access coalescing
4. Experimental evaluation
实例说明functional 和 architectural 仿真的正确性
仿真在Intel Xeon 4核处理器上进行仿真，性能评估由AMD OpenCL SDK完成


4.1 Validation
functional simulator:
instruction decoder的验证方法是对比反汇编与AMD编译器生成代码是否一致
对比benchmark在CPU上执行与仿真环境的输出结果
architectural simulator:
对比Multi2Sim与实际硬件（native）运行的结果
architectural model 是基于时钟的，native excution评估为Kernel的运行时间
ALU频率设置为850MHz，与硬件一致
硬件计算每1000条指令的平均时间，时间由AMD APP profiler获得，profiler统计不包含kernel的建立和IO时间


修改benchmark的问题大小，模拟效果与实际运行效果的时间长度趋势相同，横轴对应模拟时间，纵轴对应硬件执行时间，如果建模效果比较准确，


导致偏差的原因有：
Specialized Memory Path Design:
AMD Radeon 5870有两个路径来访问存储器，每个路径属性不同:
fast path仅支持基本的操作，如Load、Store 32位的数据类型；
complete path可以支持高级应用，如32位一下数据类型的store和原子操作
[17]这种架构在未来将不再使用，Multi2Sim未使用
Cache Interconnect:
L1与L2之间的互联细节未被公布，仅通过与L2之间的互联方法进行模拟
Cache Parameters:
不同层级间的延迟和连接关系不清楚
4.2 Simulation Speed
图9为仿真的slowdown，function simulation slowdown is 8700x(113)，architectural simulation time is 44000x(595s)


仿真一个100周期的指令快于一个10周期的指令


[18]GPGPUSim的用处，相对native execution，平均slowdown 为90000x(1350)


4.3 Benchmark Characterization
基于instruction classification（不同类型指令的执行时间）, VLIW bundle occupancy（5个VLIW lanes的使用率）, and control flow divergence对benchmarks进行描述


4.4 Architectural Exploration
性能评估由对比每个时钟的指令数（IPC - instructions per cycle）来完成


1. 增加cu的个数
会减少平分到每个cu的global memory访存带宽，增加L2 cache，会有5倍的访存速度
ALU/Fetch比例：如果大，为compute-intensive(URNG)，小为memory-intensive(Histogram)


2. 增加stream cores的个数
the number of stream cores -> the number of subwavefronts(that stream cores deal with for each VLIW bundle) -> performance
当stream cores数与workfront中work-item的个数一致时，串化的stream core导致的bottleneck就没有了
3. 增加L1 cache的大小
在缺少时间局部性和数据局部性时，性能受cache大小影响比较大
5. Related work
[12]Barra是针对NVIDIA G80 GPU上ISA-Level的模拟器，但是NVIDIA没有提供手册文档，依赖于其他学术研究。 仅限于GPU功能级仿真，缺乏架构级的仿真


[10]GPGPUSim也是针对NVIDIA架构的模拟器，包含shader core(着色)


Multi2Sim对不同GPU ISA进行建模


[13]Ocelot，将CUDA PTX(parallel thread execution)作为输入，翻译为x86、NVIDIA GPU和AMD GPU


优势：
1. 商用GPU的ISA建模
2. GPU架构建模
3. CPU-GPU模拟框架[8]


6. Conclusions
将支持AMD Fusion Architecture
支持共享存储
OpenGL + OpenCL


SOCROCKET: A VIRTUAL PLATFORM FOR SOC DESIGN
-> 2013
[1] SystemC和事务级编程模型已经逐渐成为发展趋势
必须能够描述整个系统工作流程
必须提供足够的灵活性已兼容目前的技术


[16] SCOC3 和 NGMP是未来SoC设计的代表，基于之前的设计和第三方组件
公司内部设计需要考虑的设计影响因素有：设计域、接口、抽象级别、细化粒度


亟需促进软件开发的方法，分析组合Hw/Sw系统的性能，Hw、Sw密不可分
key: 方法


Virtual Prototyping 切中关键点，使得软件开发在硬件设计过程中就可以进行，而无需考虑硬件结构


[17] 为了实现所描述方法，要求有广泛涉猎的IP核，这些核符合SystemC/TLM模型，可以在相关EDA工具获得
IP核由European Space Agency[4]（应用目标）和其他供应商（Aeroflex Gaisler with GRLIB[2]）
研究高抽象级模型和和相关方法，Braunschweig Technische Universitat开始研发SoCRocket Virtual Platform
伴随VP，SoCRocket中包含部分IP核模型:
基于TrapGen LEON ISS(instructino set simulator)
模型多为SystemC的仿真模型，如caches、 mmu、AMBA、memory controller、interrupt controller、timer等，这些模型符合TLM2.0标准（Transaction Level Modeling standard - Open SystemC Initiative 2007）
loosely-timed, approximately-timed coding styles, runtime reconfiguration, the completeness of tools and models
所有的IP仿真有免费开源的RTL代码，使得SoCRocket与其他商用VP区分开来
而且，由于满足TLM标准，所以SoCRocket环境可以移植到其他VP环境中，如Cadence VP, Synopsys VP


2. System Design with SoCRocket
Vitual System Prototyping 的优点：
1. sw/hw并行开发
2. 减少sw/hw的时间消耗
3. 相比硬件实现，节约成本
4. 由于没有线与针脚，观察能力与可控能力比较强
2.1 SystemC and TLM
[12] SystemC is a system design language that has evolved in response to a need for a language that improves overall productivity for designers of electronic systems.
SystemC是一种系统设计语言，为集成电路设计师提升产出


[11] SystemC is a C++ based modeling platform supporting design abstractions at the register-transfer, behavioral, and system levels.
SystemC是一个基于C++的建模平台，支持register-transfer、行为级与系统级的抽象


有许多库，构建系统级的混合软硬件系统的可执行模型
允许多种级别抽象的模拟器
SystemC使得设计师更多关注功能实现，而忽略实际的硬件结构


仅使用SystemC进行建模，还不足以实现高效的仿真模型，还必须定义建模规则与不同模型之间的操作流程


[13]最早提出TLM，抽象通信和计算模型（communication and computation）


2.2 Models Library
目前，仅Aeroflex Gaisler GRLib被建模，但只要满足SoCRocket建模手册，就可以对库进行扩展
所有的模型接口参数都可以进行修改，以便对各种硬件配置进行研究探索


SoCRocket主要关注Accellera TLM2[18]中描述的Loosely Timed & Approximately Timed coding styles.
LT针对fast address-accurate simulation(SW development)
Communication 采用阻塞功能调用，尽可能与SystemC Kernal同步
AT针对体系结构探索
依据所需精确度，对Communication protocol进行建模
没有对AHB进行时钟精确(cycle-accurate)的AHB模型，因为AT建模的目的是加速RTL仿真，同时保证精确，简化设计


优势：
在设计伊始就进行架构设计或优化
有利于辨别风险和缺陷
贴近于实际硬件实现的软件开发和硬件仿真


2.3 设计流程：
1. software implementing the desired functionality(功能级软件开发，手动将任务分配到软件或硬件，任务量比较大)
SoCRocket可以将C/C++代码映射到SystemC总能部件或软件任务中
手动创建或者利用综合工具生成硬件模型，硬件环境有GRLIB建模
2. 配置硬件参数，如cache大小，总线位宽，处理器单元数
两项工作同时进行，迭代至可满足性能的系统
有工具与方法来收集、分析性能参数，检测、统计仿真结果，助于设计师对架构性能的评估
可以通过shell脚本自动进行DSE，自动进行配置修改，并获得仿真结果


2.4 VP Infrastructure
不同模型 + facilities to interconnect, manage the simulation(start/stop/pause/etc.) + ability to produce results and statistics


SoCRocket设计了GUI，名为Configuration Wizard（CW），用户可以例化各个模型，修改配置参数，可以输出SW配置信息和HW配置信息
CW分析系统的存储器空间，生成软件映射链接脚本，自动集成新系统于VP环境中的编译脚本
软件代码可以在裸板上进行模拟，也可以在RTEMS OS（Real Time Executive for Multiprocessor Systems）上运行[7]


2.4.1 Performance Monitoring
为了统计执行信息，各模拟器模型提供一系列性能计数器，默认配置下，性能计数器在仿真结束后运行，1.也可以trace计数器于log或waveform文件，2.并为特定的边界、事件插入指针（基于GreenSocs infrastructure[6]）


这些统计数据用于评估设计目标，通常包括吞吐量，延迟，低成本（面积、功耗）


在仿真过程中，性能counters使用analysis API，可以实时记录仿真数据，API可以列出、读写、显示、记录各参数
而且，可以为参数生成波形和调用函数接口，供自定义的分析工具


Simulated Time Analysis
模型可以记录各个活动和时间的执行时间（如每条汇编指令在处理器中的执行时间）
时间记录为SystemC内核中的核心功能
Power Analysis
SystemC 中并没有提供这样的功能功能
需要各个实现（ad-hoc implemented）
评估原理：功耗只依赖于各个组件自己的功能
因为功耗评估框架搭建基础是整个架构模拟器，考虑到组件之间的互联


1. static power
the leakage of the component
输入参数必须初始化标准的漏电电压值
2. dynamic internal power
3. dynamic switching power(linearly dependent on the clock frequency)
存储器，总线执行一条读写操作的耗电量
库中包含GRLIB组件在 90nm CMOS工艺下功耗参数


3. Experimental Results
LEON3-based System-on-Chip
对高光谱图片进行无失真压缩算法


3.1 SoCRocket library 目前主要关注执行速度和功耗
3.1.1 Model's Accuracy
执行各种benchmark，LT & AT -> 准确率70%以上（因为许多细节只能进行抽象）
与RTL有相同的特性，cache越大，执行时间越短，仿真时间越短，这一点十分重要


功耗评估还没完成


3.1.2 Performance Results
相比VHDL，加速比高达1000+


3.2 Usage Example
参考软件分两部分，一部分成为处理器中运行的软件，一部分成为硬件
3.2.1 Design Flow Application to CCSDS Lossless Compression Algorithm
[14]CCSDS Standard