zoukankan      html  css  js  c++  java
  • CAPI 初探及使用小结(3)

    作者注:

      限于能力和时间,文中定有不少错误,欢迎指出,邮箱yixiangrong@hotmail.com, 期待讨论。由于绝大部分是原创,即使拷贝也指明了出处(如有遗漏请指出),所以转载请表明出处http://www.cnblogs.com/e-shannon/

    http://www.cnblogs.com/e-shannon/p/7495618.html

    3 CAPI 详细结构和流程

    CAPI的设计思路即是将加速设备作为CPU的完全对等体(full peer to CPU),可直接与application通信,访问内存机制与CPU一致(所有访问实地址空间的权限,不用修改的有效地址EA,使用CPU的 page table等等)。相对于通过PCIE I/O口进行加速的方案,其减少了I/O driver的开销,简化了地址的转换,并且AFU/PSL接口简化了开发时间,不再需要关注PCIE驱动和设计[dream1]

    如上节图所示,CAPI采用PCIE为物理通道,在CPU一侧需要CAPP支持,在FPGA一侧需要IBM 的PSL IP支持。而CAIA则定义了OS和带有PSL的CAPI设备之间的接口。

    3.1 CAPI 硬件结构

    整个CAPI中,用户侧(FPGA侧)由PSL和AFU构成,CPU侧则是CAPP模块。

    3.1.1 CAPP

    CAPP的全称是Coherent Accelerator Processor Proxy (CAPP),在多核power CPU中,CAPP扩展了加速器的一致性,在CAPP上的目录代表加速器提供了一致性回应。整个一致性协议泡在PCE 物理链路上,PCIE介于PSL和CAPP之间。The Coherent Attached Processor Proxy (CAPP) in the multi-core POWER8 processor extends coherency to the attached accelerator. A directory on the CAPP provides coherency responses on behalf of the accelerator.Coherency protocol is tunneled over standard PCI Express links between the CAPP unit on the processor and the POWER service layer (PSL) on the accelerator card

    具有如下特征

    作为FPGA加速的代理,嵌入到处理器中,表驱动型协议(?),为加速器屏蔽cache目录,约1MB的cache tags标签(基于cache line[dream2]

    Proxy for FPGA Accelerator on PowerBus

    Integrated into Processor

    Programmable (Table Driven) Protocol for CAPI

    Shadow Cache Directory for Accelerator

    Up to 1MB Cache Tags (Line based)

    Larger block based Cache

    3.1.2 PSL

    PSL的含义是POWER Service Layer (PSL),作为AFU通向CPU的桥梁,它为AFU提供了兼容POWER架构地址翻译和系统memory cache(先期为256KB)。相对于I/O加速,它由许多优势,包括共享内存,无需钉住数据用于内存DMA,对于cached 数据的低延迟,以及更容易自然的编程模式。不需要数据它实现于FPGA中,为加密的IP核,原来实现于ALTERA,后实现于Xilinx[dream3]

    如下图PSL的大致功能如下,PSL含有图中几个功能,cache、MMU、ISL,PSL还含有内存保护表。

    clip_image002

    TLB:地址转换后备缓冲器(Translation Lookaside Buffer, TLB)用于缓存虚拟地址(或者有效地址)到物理地址(或者实际地址)的cache,有些地方用CAM实现。可以加速地址转换

    https://en.wikipedia.org/wiki/Translation_lookaside_buffer

    内存访问加速方法:http://blog.csdn.net/ctthuangcheng/article/details/8550450

    a. 使用了MMU(Memory Management Unit,内存管理单元)。

    b. 地址转换中出现最频繁的那些地址,保存到 地址转换后备缓冲器(Translation Lookaside Buffer, TLB)的高速缓存中。这些地址无需访问页表即可从高速缓存中直接获得地址数据。

    A CAIA-compliant processor includes a POWER service layer (PSL). The PSL is the bridge to the system for the AFU, and provides address translation and system memory cache.

    This interface provides the basis for all communication between the accelerator and the POWER8 system. The PSL provides address translation that is compatible with the Power Architecture® for the accelerator and provides a cache for the data being used by the accelerator. This provides many advantages over a standard I/O model, including shared memory, no pinning[dream4] of data in memory for DMA, lower latency for cached data, and an easier, more natural programming .model Effective addresses from an AFU are translated to a physical address in system memory by the PSL. The PSL also provides miscellaneous management for the

    Implemented in FPGA Technology

    Provides Address Translation for Accelerator

    Compatible with POWER Architecture

    Provides Cache for Accelerator

    First Implementation – 256KB

    Facilities for downloading Accelerator Functions

    3.1.3 AFU

    AFU 全称为Accelerator Function Unit,用户定制的加速功能则在此实现,它通过PSL提供的接口与application通信。这个接口为PSL Accelerator Interfaces

    AFU中含有AFU描述符,由一组寄存器组成,这些寄存器反映了AFU的能力,以及是software必须的知道的信息,它提供了一种机制,使得将问题状体区域(problem state area)与AFU相关的系统进程关联起来。 (Yxr注:对于PCIE介质,AFU中可能还存有PCIE configuration 寄存器组。)

    当应用程序需要使用使用AFU的时候

    AFU Descriptor Overview,The AFU descriptor is a set of registers within the problem state area that contains information about the capabilities of the AFU that is required by system software.The AFU descriptor also contains a standard format for reporting errors to system software. All AFUs must implement an AFU descriptor.

    When an application requests use of an AFU, a process element is added to the process-element linked list that describes the application’s process state. The process element also contains a work element descriptor (WED) provided by the application. The WED can contain the full description of the job to be performed or a pointer to other main memory structures in the application’s memory space. Several programming models are described providing for an AFU to be used by any application or for an AFU to be dedicated to a single application.See Section 3 Programming Models on page 25 for details.

    3.2 PSL 加速接口

    PSL加速接口介于PSL和AFU之间。通过这个接口,PSL提供AFU各种服务,这些服务基于cache-line size。在CAPI1.0中,PSL Accelerator Interface含有5个接口。

    1) 加速器命令接口Accelerator Command Interface,通过这个接口,AFU发出服务申请,其实就是读写和操控cache的命令,地址位为64位。这时AFU会产生一个8位tag标志(类似PCIE访问的tag标志,用以给此次访问打上标签,一旦PSL回应申请,会带上这个tag,告诉AFU针对的是哪个申请tag)

    2) 加速器缓存接口Accelerator Buffer Interface,这是一个数据接口,PSL响应AFU的申请,输入和输出数据给AFU,数据位均是512bit宽度,时钟250M

    3) PSL响应接口 PSL response interface。在PSL完成数据传输后,PSL给出状态应答给AFU。

    4) 加速器MMIO接口 Accelerator MMIO 接口。MMIO,内存映射IO,通过这个接口,软件的MMIO能够访问到AFU内部寄存器。24位地址,64位数据

    5) 加速器控制接口 Accelerator control interface。PSLjob 管理通过这个接口控制AFU的状态,这个接口是个关键接口,用来启动和终止AFU,AFU则反馈其状态给PSL。并且通过这个接口,PSL将WED写入给AFU,告知AFU进行什么工作。AFU完成后,回应done给PSL.

    在CAPI2.0中,接口命名将accelerator改为AFU,这样更科学。同时添加了第六个接口AFU DMA Interface。AFU DMA接口允许AFU能否发送PCIE的原生态读写命令和接收PCIE读完成命令,也就是说能直接操控PCIE,有更大的灵活性!所以CAPI2.0的接口如下

    1)AFU Command Interface

    2)AFU Buffer Interface

    3)PSL Response Interface

    4)AFU MMIO Interface

    5)AFU Control Interface

    6)AFU DMA Interface

    Yxr注:在CAPI2.0和CAPI1.0相同接口是否有细节上的差别,自己没有仔细甄别

    3.3 CAPI工作机制

    详见《OpenPOWER_CAPI_Education_Intro_Latest.ppt》

    3.3.1 CAPI的流程

    软件方面,先open AFU设备,初始化WED(work element descriptor),将WED写入到AFU中,主要告知AFU进行何种操作。WED可以是一个指针,指向一系列操作的链表。AFU读取WED,就开始进行。以上操作PSL 加速接口主要是 control interface(CTL 接口)和MMIO接口

    AFU分解WED,通过PSL读取内存数据进行加速处理,经过PSL加速接口的命令接口发出命令,PSL负责数据的传输,最后PSL给出AFU回应表示传输的结束状态。

    AFU获取数据完成加速操作,期间软件通过MMIO访问AFU的寄存器。AFU会通过控制接口告知app其完成加速操作。

    具体流程可以见下图

    clip_image004

    Because of CAPI’s peer-to-peer coherent relationship with the POWER8 processors, data-intensive programs are easily offloaded to the FPGA, freeing the POWER8 processor cores to run standard software programs. Any algorithm that you can code into an FPGA is now possible on a POWER8 system using this low overhead mechanism. CAPI’s overall value proposition is that it significantly reduces development time for new algorithm implementations and improves application performance by connecting the processor to hardware accelerators and allowing them to communicate in the same language (eliminating intermediaries such as I/O drivers).

    The main application is executed on the host processor with computation-heavy functions executing on the accelerator. The accelerator is a full peer to the host processor, with direct communication with the application. The accelerator uses an unmodified effective address with full access to the real address space. It uses the processor’s page tables directly with page faults handled by system software

    3.3.2 CAPI 应用程序流程

    CAPI application flow

    详见ppt,描述地更好,自己拷贝了几张图

    clip_image006

    clip_image008

    clip_image010

    clip_image012

    Yxr注:如上两图,可能软件的函数有些不同,但是整体流程差不多,可以看到此时app将WED的指针写给了AFU,WED则是指向一个链表的头和尾

    clip_image014

    Yxr注:这个时候,app可以通过MMIO接口访问AFU的寄存器,并且添加更多的命令。 CAPI solution flow

    clip_image016

    完成后,AFU发出done信号,PSL复位加速器。Accelerator asserts “done” and PSL resets accelerator

    3.4 CAPI仿真平台搭建

    由于自己主要涉及了CAPI1.0的仿真平台搭建,所以主要介绍基于questa平台的仿真。

    Yxr注:不知道CAPI2.0的仿真平台是否全部都变了,如果变了,则毫无意义了。

    《DeveloperWorksCAPIDevelopmentKitdemo_document_20141119.doc》

    3.4.1 仿真的原理和模型

    这里的仿真,指的是对于AFU的HDL代码与APP以及驱动的联合仿真。仿真的方法一直在改进,在原来的仿真方法中,分为HDK(hardware demonstration kit和SDK software demonstration kit两种方法, HDK的意思是整个OS和power CPU均放入仿真环境中进行模拟,曾经在HDK上耽误很长时间,实际上现有代码是基于SDK的方法。SDK的仿真方法也有演进,现在最新的应该存在于github中,仿真方法更简洁了。

    在SDK仿真中,引入了PSL仿真引擎(PSLSE :Power Service Layer Simulation Engine ).,其采用C语言完成,以静态库(libcxl.a)形式存在。在编译时和用户的application代码一起生成程序。AFU的代码为HDL代码,其通过PLI接口与afu_driver.sl协同:仿真,而afu_driver.sl通过socket 和PSLSE通信。结构框图如下

    clip_image017

    从仿真框图来看,其绕过了PCIE 物理链路, AFU代码直接通过PSLSE和application通信。

    可以理解PSLSE模拟了PSL,OS, libcxl(这些部分见CAPI 应用程序流程图一节)。而仿真中并不需要用户额外建verilog的仿真激励,只要把自己的应用程序C代码和AFU代码进行协同仿真。当要上板调试时,将PSLSE替换成libcxl即可。

    Preparing the PSL Simulation Engine

    Recall that applications initialize communications with their AFU on the FPGA using the API provided by libcxl. The PSL Simulation Engine (PSLSE) is essentially an embodiment of libcxl that redirects the communication set up to the modeled AFU. PSLSE uses a socket to connect to the afu_driver shim(应该是afu_driver.sl,即PLI文件)that exists in the modeled AFU.

    The demonstration kit provides a makefile in shim_client/sw to illustrate how to compile the code. The result is the PSLSE version of libcxl.

    下图来自CAPI user guide的拷贝,PSL shim可以理解为afu_driver.sl(PLI函数[dream5] )

    clip_image019

    3.4.2 仿真步骤

    1)编译libcxl.a库和afu_driver.sl PLI函数,编译app程序包含libcxl.a

      compile the application code and *.sl file:

         a) generate the libcxl.a

          run 'make' in {work directory}/pslse-master/pslse directory to

         b) generate the afu_driver.sl in

    {work directory}/pslse-master/pslse/afu_driver/src/afu_driver.sl

    run 'make' in {work directory}/pslse-master/pslse/afu_driver/src

        c) generate the application

    run 'make' in {work directory}/src/textswap

    src/textswap/textswap -C build/test.dat build/test_out.dat

    2)在HDL代码侧,IBM提供了顶层文件Afu_top.v,一方面与afu_driver.sl PLI函数相联,另一方面内部有PSL加速标准接口(就是前面提到的五个接口),用户只要对接这些接口,进行HDL 代码编程。

    3)启动questa,编译HDL代码(vlib,vlog,vcom),

    4)然后将PLI函数放在一起仿真

    vsim -L work -t ns -novopt -c -pli ./pslse-master/pslse/afu_driver/src/afu_driver.sl +nowarnTSCALE work.top

    5)run 仿真平台,等待application的调用

    6)运行 src/textswap/textswap -C build/test.dat build/test_out.dat 即可

    3.5 CAPI 优势

    3.5.1 相比于PCIE IO 加速的优势

    CAPI与一般PCIE加速板的第一个优势就是突出在C上,C就是coherent的意思,应指cache coherent。在这里,CAPI加速板(PCIE卡)作为一个对等的CPU(或者辅助加速器),而PCIE仅仅提供一个高速物理链路而已(因为高速总线最终可能要统一到PCIE总线)。在多核的系统里,每个CPU拥有自己的cache,通过cache coherence protocol保证cache的内容一致性。而CAPI也有自己的cache,约可能是256KB,这样其访问内存的速度就和没有cache的PCIE卡优势非常明显。

    为支持这个特性,在Power8的CPU侧添加了CAPP, 用于窥探powerbus的命令,同时反馈PSL中的cache状态 ,简而言之就是一种CCA(Cache Coherency Agent )负责cache的状态控制和更新,保证cache coherency

      由于是和CPU是对称关系,所以和CPU有相同的地址访问空间和cache

    所以说相比于一般的采用PCIE插卡的加速器,CAPI的第一个优势就是有对等于CPU的架构以及相应的cache结构,使得其效率远高于无cache的架构(就好比带Cache的CPU与不带cache的CPU的效率差距,至于对等性是否带来线程调度的差异,这个本人暂时没有深究)

       由于采用PSL/AFU结构,带来的另一个优势就是是AFU的开发者不需要理解掌握PCIE的操作,专注于解决自己的问题。(A primary function of the PSL is the physical separation of the AFUs so that they appear to the systemas independent units.),更加突出了PCIE仅仅是一个传输媒介。

    如下是文档关于优势的描述Coherent Advantages Over I/O Model,并且其给出了数值比较

    1)Virtual Addressing & Data Caching

    Shared Memory

    Lower latency for highly referenced data

    2)Easier, More Natural Programming Model

    Traditional thread level programming

    3)Enables Applications Not Possible on I/O attached

    Pointer chasing, etc…

    clip_image023

    Yxr注:但是自己确实不是很理解为什么I/O 开销很大,尤其是copy or pin source Data,这个CAPI也不能省吧,必须把数据拷贝到FPGA本地,才能做操作啊,只不过是AFU编程人员不需要知道这种拷贝操作,因为其直观认为是直接操作内存。

    个人理解是做为IO设备,在操作系统其走的路径,需要经过I/O driver,OS,最终到达application层。而CAPI设备则直接能通过OS到达application,减少了IO driver开销,尤其是IO map一系列地址映射带来的开销。

    引申

    CAPI的核心是提供给CPU一个可编程的对可并行处理的协处理,协处理器由于是并行硬件加速,所以快于一般的软件加速(其实并不清楚是否快于GPU加速,GPU也可以并行)

    引申开来,其实PCIE只是在CAPI中仅仅是一个媒介作用,在CAPI体系中,可以不是PCIE总线互联,效率高的可能是QPI和HT总线(类似FSB总线,但是点对对串行),只是无法开放给用户。而OpenCAPI确实给了bluelink总线,PCIE总线也存在软肋,就是round trip latency。而intel收购altera,使得这样的加速架构成为可能,FPGA嵌入到CPU中(以往的FPGA都是CPU嵌入到FPGA中),高端用户就可以完成自己的可订制加速!

    3.5.2 相比于CPU+GPU优势

    以下摘自http://www.openhw.org/module/forum/thread-597651-1-1.html,虽然列出了4大优势,但是笔者理解来应该FPGA是硬件加速,比起GPU的并行软件加速,速度更快,功耗更省!

    那么结合CAPI技术和FPGA技术的加速卡有什么优势呢?基本可以总结出四大优势:

    * FPGA芯片和CPU更通畅便捷的“对话” CAPI技术具备缓存一致性和对等的内存访问能力,也就是说CPU可以分享他的内存空间直接给FPGA使用和访问,通过CAPI给CPU和FPGA搭起一条快速通道,使得他们的“对话和交流”变得轻而易举。(yxr注: Power9的nvlink2.0可以对接nvidia的GPU,这样谁更便捷呢?)

    * 逆天高性能,真正实现以一当百 根据赛迪顾问发布的《中国OpenPower产业生态发展白皮书》介绍,使用CAPI+FPGA加速卡对大数据Hadoop算法中对性能要求最高的擦除码进行处理,经测试,服务器性能提升20-100倍!真正实现逆天的以一当百啊!

    * 灵活可编程,全方位实现指哪打哪 FPGA芯片是可以编程的,所以我们可以用它来实现多种不同算法的在线升级。我们可以在不同的场合对FPGA加速单元进行升级,灵活配置更换不同的算法,此法具备通用性,可应用于不同场景加速——可以说,FPGA芯片是“十八般武艺样样精通”呢!(GPU也能吧。。。)

    * 少吃多干,环保低功耗 啥是吃的是草,挤出来的是奶?看看CAPI+FPGA加速卡就知道了!一块FPGA加速卡功耗约20Watt~75Watt,安装在服务器机箱内,不占用额外机房空间。光看这个,你没什么概念是吧!没关系,对比一下就知道了! 1个CPU单元功耗约为 145Watt~190Watt, 1个GPU卡单元 功耗约为 235Watt~300W,这下明白了吧!(yxr注:是同等性能下吗?)

    3.5.3 劣势

    主要是和其他加速接口对比,比如必须要PSL加密IP。必须需要FPGA配合,不是公开的IP核。PCIE的round_trip delay大。FPGA编程难度高于GPU的软件编程,适用面小于GPU。受资源限制,过于复杂的算法能否由FPGA实现。


    [dream1]IBM_CAPI_Users_Guide_1-2.pdf

    The Coherent Accelerator Process Interface (CAPI) is a general term for the infrastructure of attaching a coherent accelerator to an IBM POWER® system. The main application is executed on the host processor with computation-heavy functions executing on the accelerator. The accelerator is a full peer to the host processor, with direct communication with the application. The accelerator uses an unmodified effective address with full access to the real address space. It uses the processor’s page tables directly with page faults handled by system software. Figure 1-1 shows an overview of CAPI.

    [dream2]基本没有懂

    [dream3]决定了CAPI 只能由FPGA实现,且仅仅适用于POWER CPU

    [dream4]Pinning:钉住

    http://www.ehcache.org/generated/2.9.0/html/ehc-all/index.html#page/Ehcache_Documentation_Set/co-life_pinning_data.html

    如果不钉住数据,则cache或者memory中的数据会被清除

    Pinning Data

    Without pinning, expired cache entries can be flushed and eventually evicted, and even most non-expired elements can also be flushed and evicted as well, if resource limitations are reached. Pinning gives per-cache control over whether data can be evicted from Ehcache .

    Data that should remain in memory can be pinned. You cannot pin individual entries, only an entire cache. As described in the following topics, there are two types of pinning, depending upon whether the pinning configuration should take precedence over resource constraints or the other way around.

    [dream5]对吗?

  • 相关阅读:
    dlo,学习清单
    OO第一单元优化博客
    BUAA Summer Practice 2017 #1 字符串专场
    OO第一次博客作业
    2018.12.16程设串讲
    助教工作总结 3-22
    软件工程助教3.15总结
    大数据应用技术课程实践--选题与实践方案
    第十五次作业-手写数字识别-小数据集
    第十四次作业-深度学习-卷积
  • 原文地址:https://www.cnblogs.com/e-shannon/p/7496181.html
Copyright © 2011-2022 走看看