PS与PL - 基于SDSoC开发流程环境应用的详解以及其优势

位于PS侧的ARM内部用硬件实现了AXI总线协议，提供GP、HP和ACP等性能各不相同的数个物理接口。而PL侧则需要使用可编程逻辑来搭建相应的AXI接口。在具体设计时，可以在Vivado IPI中使用赛灵思提供的IP如AXI-Stream等等来实现。此外，软硬件之间有数据交互的设计就牵扯到在软硬件之间如何进行数据搬移，这种情况下，我们还需要一个或数个DataMover，这也同样需要在PL侧使用可编程逻辑来搭建。

Zynq SoC 开发流程

之所以要花几页篇幅来介绍Vivado HLS的作用与Zynq的架构，就是为了更清楚地描述全面可编程Zynq SoC的开发流程。

对于以C/C++等高阶语言为起点来进行SoC开发的用户来说，由C/C++算法开始，首先需要对软硬件进行分区，选择哪些部分放入PL侧进行加速，哪些部分仍然在PS侧用软件实现。对那些指定到放入可编程逻辑上用于硬件加速的部分，还需要完成C代码到RTL IP的转换。接下来，就是完成软/硬件之间的连接，包括使用怎样的DataMover、PS与PL之间的接口如何配置等，接下来还要完成配套的软件驱动程序。所有这些往往牵扯到数个不同团队和专业人员的通力合作，需要通过数次迭代来探索最佳的实现方案和系统架构。这个流程图很清晰地描绘了SoC的开发流程，每一步都是耗时耗力的工作。

 

不使用SDSoC的开发流程

具体到每一步的工作来看，传统的Zynq设计流程大致分为五个步骤：

 

首先，系统架构师来决定将哪些部分用于软件实现，哪些部分放入硬件加速，即所谓的软硬件分区。划分为硬件实现的功能将需要使用RTL代码来开发，或是使用HLS将C/C++代码综合成Vivado中可实现的IP。然后，要在Vivado IPI中搭建DataMover和接口。后是应用软件和驱动程序的开发。

这无疑是一个十分耗时的过程，需要多个部门和团队之间的设计切换。有时候，即便这样完成后的设计可以正常工作，却可能无法满足你在吞吐量、延迟或面积等方面的设计性能要求。此时就可能需要通过修改系统连接来重新搭建硬件架构来对系统性能进一步优化。但这么做，又将导致软件应用程序和驱动程序的变化。因此，你往往需要与多个软件和硬件团队紧密合作，通过多次迭代设计来试着满足最终需求。

在某些情况下，设计不能满足你的性能要求的原因在于 软件性能不够，或是硬件的占用率太高。这时候，你就需要返回到最初的设计，重新修改软/硬件分区方案，然后前面所说的硬件实现，系统连接，软件驱动等所有步骤都要重新再来一边，这势必要求更多的团队一起配合，改变设计来探索另一种架构，而且可能面临更多次的设计迭代，进一步拉长设计周期。

毫无疑问，用在系统优化上的时间对time-to-market的影响巨大。此外，我们也注意到在Zynq SoC的设计中，用户最关注的部分往往是算法的最终实现和算法模块的优化，包括IP或是软件功能块。因此，SDSoC的设计理念也致力于解决这些用户最关注的问题。

应用了SDSoC的开发流程

如下图所示，在应用了SDSoC的Zynq设计流程中，工具可以自动搭建软硬件之间的通讯部分，包括DataMover、软件驱动程序和硬件连接接口。工具还可以将整个开发过程抽象到C/C++的应用层面，以C/C++为起点来进行算法开发，当然，工具也可以调用以传统的IP方法开发的算法模块，包括已经由Vivado HLS转换后的RTL IP，也包括那些本身就由Verilog或VHDL硬件描述语言编写的IP。在调用这类IP时，只需将其封装为C可调用库的形式即可。 在SDSoC中，我们能够轻松进行软件/硬件的划分，用户仅需在图形化界面中用鼠标单击指定那些需要进行硬件加速的模块即可。

 

相比较传统SoC设计流程，SDSoC通过自动生成硬件连接和软件驱动程序大大简化了Zynq SoC和MPSoC的开发过程。它会自动调用Vivado HLS来将那些用C/C++开发的算法模块转化为Vivado可综合的RTL IP，它也可以将那些已经优化过的HDL IP模块通过C可调用库的方式进行重用。用户可以在软件中通过简单点击某个功能块将其应用到PL上进行加速来迅速修改软/硬件的分区，因此，它也有助于系统架构设计人员运行快速假设性分析来评估系统的性能和面积。