ISDF2016经典之A5：使用英特尔SoC FPGA加速IP原型开发

08       
        我们考虑在我们的SOC FPGA上建立起来一种混合的仿真模型。
        什么叫做混合仿真模型？
        是说把我们IP的一些功能以虚拟化的形式，跑在CPU的core上。
        它对于我们的SOC FPGA来说的话，这个CPU的Core是指我们的NIOS的软核，或者是我们的HPS也就是ARM的硬核。
        我们可以看到，我们在这里面，把我们的微处理器的功能一分为二，我们在我们的NIOS软核里面，运行一个守护程序。
        守护程序会执行真正的封外代码，而这个NIOS软核和我们的FPGA逻辑之间，通过Avalon的Bus连接。
        然后我们在我们FPGA的内部还插入了一个转换器，adapter。
        这个转换器会把所有的Avalon Bus上面的操作转换成实际的PIN的操作。
        然后我们举个例子来说吧，比如说我们刚才说的，我们需要以我们的微处理器控制我的IP，进入一个休眠的状态。
        而做这一点的话，在我们的封外代码里面，可能只是一个简单地去写一个寄存器。
       

09       
        而这个写寄存器的操作可以转换成为我们Avalon bus上面一个memory写的过程。
        而我这个Adapter又会把这个Memory write的过程转换成一系列PIN的操作，比如它会控制我们IP的，比如它的reset信号，它的pairOK信号等等。
        然后真正使我们的IP进入一个休眠的状态。这就是一个混合验证的一个模型。
        另外他的一个好处是在于，不管我们是用NIOS的软核或者HPS的硬核，我们都可以很方便地把我们这个封外执行的debug信息然后打印到我们OS里面，console里面。
        比如用putty，或者用别的方式，我们都可以很方便的去debug这个东西。
        但是它有一个很明显的不好的地方，我们知道就是NIOS本身还是一个软核，它会占用一部分的FPGA的资源。
        所以我们可以考虑HPS的ARM的硬核来代替之前的NIOS的软核，实现相同的功能。
        以此支持我们最后的一个解决方案。
        我们在这个解决方案，以这种方式的话，我们在我们的系统资源的占用率、性能以及包括可调试性等等因素当中取得了一个平衡点。
       

10       
        而且这种解决方案的话，可以运行真正的封外的代码。
        下面一个题目的话，我们会说一下怎么用Quartus的工具建立起来有效的FPGA的backdoor的这种调试的接口。
        我们知道，就是说我们Quartus的软件其实提供了很多非常有用的tool来帮助我们进行一些FPGA的在线debug的功能。
        而在我们的解决方案中，我们用了其中的两个tool。
        一个tool就叫做In-system sources and probes。
        如果想用这个tool的话，我们需要在我们FPGA里面插入一个Quartus自己提供的IP，它的名字叫做altsource_probe。
        用这种方式的话，它的作用是它可以去远程设置你的IP里面的某一个特定的signal。
        而对于我们的解决方案来说，我们是用它来设置我们的整个FPGA里面的global reset。
          

11
        我们可以实现对我们整个FPGA的系统进行一个远程的重启的一个功能。
        另外一个很好用的功能的话，也就是这个叫做system console，叫做系统控制台。
        去使用这个工具的话，同样在我们的FPGA里面需要插入IP叫做Altera_jtag_avalon_maste。
        这个IP会把所有Jtag上面的transition操作转换成我们的Avalon bus上面的操作。
        因为Avalon bus的设计本身很简单，它很方便地就可以和我们设计的FPGA的接口相连。
        通过这样一条回路，我们很方便地就可以通过在我们system console里面去在线debug我们被测IP里面的各种逻辑。
        我们看一下我们FPGA的backdoor可以完成什么工作？
        首先的话，它和我们刚才之前那个工具很相似，它也可以实现远程设置我们IP里面的某一个signal。

12
        此外的话，它可以很方便地去读写我们FPGA里面的内部的buffer。
        然后我们可以看到，下面是我们一个使用FPGA，然后做debug的这样子的一个例子。
        我们知道，当我们在做软件模拟的时候，当我们搭我们的testbench的时候，往往会插入一些其它的模块。
        比如说，一些激励产生器，traffic generator，在我们整条Bus上，我们会插入很多的tracker，去当做我们整个bus流程里面的各种数据以及命令等等。
        然后我们在我们的FPGA上做验证的时候，我们可以做相同的事情。
        我们用我们的FPGA backdoor来控制我们的这个traffic generator，把我们想要发出来的激励，各种命令都写进我们这个traffic generator的internal buffer里，然后我触发他，产生各种激励给我的DUT0。
        而在我们的整个测试流程中，我们往往可能会有不同的路径选择，比如说这个数据回路可以从DUT0到DUT1，也可以到DUT2。

13
        中间这个地方会有一个所谓的选择器，而我同样的可以用我的FPGA backdoor来实时地去选择不同的路径，进行我们的测试。
        此外在整个数据流程中，我们也可以在不同的IP的不同的port上插入各种的tracker。
        我们可以用我们FPGA的backdoor去读出我们的tracker里面挡住的所有的数据以及命令的内容，然后逐条解析，这样子会对我们在debug数据流程会有很好的帮助。
        我们刚才说了，就是说如果我们想用FPGA backdoor的话，我们需要Quartus里面的一个工具，这个工具就是system console。
        System console这个工具的话，它有一个很大的优点就是说它其实是可以支持Tcl编程的，Tcl就是tool command language，这个是现在广泛用于EDA工具里的一个类似于script的这种脚本。
        这种命令的话，就是编程比较简单，对我们的Quartus来说的话，它其实已经提供了一些基础的Tcl的function的库。
        比如说，用这些function我们可以去实现，去操作avalon bus上面的读写，去控制我们的HPS，就是那个ARM的硬核，去控制我们的transceiver等等。

14
        基于Quartus提供的这些tool之上，我们的用户就可以去开发自己的一些的库。
        比如说，他可以去产生一些函数，去产生不同的激励，然后用一个函数去解析我们的tracker里面的内容，打印出来我们所需要的信息。
        用一个函数去编程我们FPGA的Internal buffer等等，然后在这一层的基础上，然后用还可以去更高一层的function。
        比如说在一个function里面，他可以完成我刚才所说的那样的一个端到端的完整的测试流程。
        我们可以看到，右边的这个的话，就是一个典型的Tcl编程的例子。
        我们实现了这样一条Tcl的function，这条function的话会在挂在DUT1 Bus0上面的一个tracker里面，把它里面所有挡住的数据都读出来。
        然后逐条地进行解析，它会把它每条具体的信息都打印在我们的system console上面。

15
        比如说这条命令，它的序号，它的方向，它要做什么，然后要访问哪个地址，实际的数据以及长度，等等。
        这样子的话，就是说在我们system console上面就可以一目了然地知道我们整个IP里面的数据流向等等。
        非常地利于我们做在线的debug。
        下面一个主题的话，会说一下怎么样用SOC FPGA建立一个全自动化的系统验证的这个流程。
        我们为什么需要一个这种自动化的流程？
        我们知道，一般来说，FPGA这种验证组的话，我们是需要与IP的设计组一起工作，我们会从设计组里面拿到它release出来的最新的RTL代码，然后开发我们FPGA的对应的image。
        但是每个组的策略可能不一样，有的组会选择只去拿一些他们阶段性的官方的release。
        比如说，RTL 0.3，RTL 0.4，RTL 0.5，这样子，去拿这些包。
        但这样会带来一个不好的地方有什么？
        就是两个包之间，比如说RTL 0.3到0.4中间可能已经隔了几周甚至一个月的时间，然后整个RTL的设计上也会有很大的变化。
  

16
        这又导致了我们FPGA的team拿到了一个新的release包以后，往往需要很长的时间，才能完成包括像系统集成，以及解决由于新的RTL代码引起的后端的各种问题，比如说综合布局布线等等，各种问题。
        这样意味着他拿到一个新的包往往需要很长时间才能把FPGA的image给release出来。
        而对于我们的team来说，我们选择是另外一条路，我们的策略是我们要做的是daily update。
        每天我们都会去拿最新的RTL代码，然后发布我们的FPGA的image。
        这样的好处是在于，因为每天RTL的改动会比较小，如果整个流程中出现什么错误，我们就很容易找出是由哪一部分的RTL代码改变引起我们现在出现的问题。
        这样子的话，我们就只需要很小的effort，就可以把这个问题解决。

17
        但要实现这一个全自动化的流程的话，我们就需要有一些这种自动化的这种脚本。
        我们现在的做法是在我们的一个服务器上，实现了一个全自动化的这种nightly build的一个这样的脚本。
        这个脚本每天在一个定时的时候会去design team的RTL GIT repo里面，就是代码库里面去下载最新的RTL代码，然后完成一个全自动化的系统集成，然后产生我们的FPGA的top level。
        然后在此基础上，还会在我们的仿真的平台上进行一个简单的功能性的仿真。
        如果这个功能性的仿真可以通过的话，还可以自动地完成后端，比如说综合布局布线的相关工程，工作，然后产生FPGA的image。
        但是，就是说在我们把这个FPGA的image，release给最终的用户之前，往往我们还缺少一个步骤，我们需要把image，download到我们的FPGA的板子上进行一些简单的测试。