lcytms
发表于 2017-2-24 00:13:10
08
我们考虑在我们的SOC FPGA上建立起来一种混合的仿真模型。
什么叫做混合仿真模型?
是说把我们IP的一些功能以虚拟化的形式,跑在CPU的core上。
它对于我们的SOC FPGA来说的话,这个CPU的Core是指我们的NIOS的软核,或者是我们的HPS也就是ARM的硬核。
我们可以看到,我们在这里面,把我们的微处理器的功能一分为二,我们在我们的NIOS软核里面,运行一个守护程序。
守护程序会执行真正的封外代码,而这个NIOS软核和我们的FPGA逻辑之间,通过Avalon的Bus连接。
然后我们在我们FPGA的内部还插入了一个转换器,adapter。
这个转换器会把所有的Avalon Bus上面的操作转换成实际的PIN的操作。
然后我们举个例子来说吧,比如说我们刚才说的,我们需要以我们的微处理器控制我的IP,进入一个休眠的状态。
而做这一点的话,在我们的封外代码里面,可能只是一个简单地去写一个寄存器。
lcytms
发表于 2017-2-24 00:15:53
09
而这个写寄存器的操作可以转换成为我们Avalon bus上面一个memory写的过程。
而我这个Adapter又会把这个Memory write的过程转换成一系列PIN的操作,比如它会控制我们IP的,比如它的reset信号,它的pairOK信号等等。
然后真正使我们的IP进入一个休眠的状态。这就是一个混合验证的一个模型。
另外他的一个好处是在于,不管我们是用NIOS的软核或者HPS的硬核,我们都可以很方便地把我们这个封外执行的debug信息然后打印到我们OS里面,console里面。
比如用putty,或者用别的方式,我们都可以很方便的去debug这个东西。
但是它有一个很明显的不好的地方,我们知道就是NIOS本身还是一个软核,它会占用一部分的FPGA的资源。
所以我们可以考虑HPS的ARM的硬核来代替之前的NIOS的软核,实现相同的功能。
以此支持我们最后的一个解决方案。
我们在这个解决方案,以这种方式的话,我们在我们的系统资源的占用率、性能以及包括可调试性等等因素当中取得了一个平衡点。
lcytms
发表于 2017-2-24 00:17:13
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。
lcytms
发表于 2017-2-26 22:08:41
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。
lcytms
发表于 2017-2-26 22:09:30
12
此外的话,它可以很方便地去读写我们FPGA里面的内部的buffer。
然后我们可以看到,下面是我们一个使用FPGA,然后做debug的这样子的一个例子。
我们知道,当我们在做软件模拟的时候,当我们搭我们的testbench的时候,往往会插入一些其它的模块。
比如说,一些激励产生器,traffic generator,在我们整条Bus上,我们会插入很多的tracker,去当做我们整个bus流程里面的各种数据以及命令等等。
然后我们在我们的FPGA上做验证的时候,我们可以做相同的事情。
我们用我们的FPGA backdoor来控制我们的这个traffic generator,把我们想要发出来的激励,各种命令都写进我们这个traffic generator的internal buffer里,然后我触发他,产生各种激励给我的DUT0。
而在我们的整个测试流程中,我们往往可能会有不同的路径选择,比如说这个数据回路可以从DUT0到DUT1,也可以到DUT2。
lcytms
发表于 2017-2-26 22:11:09
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等等。
lcytms
发表于 2017-2-26 22:12:19
14
基于Quartus提供的这些tool之上,我们的用户就可以去开发自己的一些的库。
比如说,他可以去产生一些函数,去产生不同的激励,然后用一个函数去解析我们的tracker里面的内容,打印出来我们所需要的信息。
用一个函数去编程我们FPGA的Internal buffer等等,然后在这一层的基础上,然后用还可以去更高一层的function。
比如说在一个function里面,他可以完成我刚才所说的那样的一个端到端的完整的测试流程。
我们可以看到,右边的这个的话,就是一个典型的Tcl编程的例子。
我们实现了这样一条Tcl的function,这条function的话会在挂在DUT1 Bus0上面的一个tracker里面,把它里面所有挡住的数据都读出来。
然后逐条地进行解析,它会把它每条具体的信息都打印在我们的system console上面。
lcytms
发表于 2017-2-26 22:13:47
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的设计上也会有很大的变化。
lcytms
发表于 2017-2-26 22:15:27
16
这又导致了我们FPGA的team拿到了一个新的release包以后,往往需要很长的时间,才能完成包括像系统集成,以及解决由于新的RTL代码引起的后端的各种问题,比如说综合布局布线等等,各种问题。
这样意味着他拿到一个新的包往往需要很长时间才能把FPGA的image给release出来。
而对于我们的team来说,我们选择是另外一条路,我们的策略是我们要做的是daily update。
每天我们都会去拿最新的RTL代码,然后发布我们的FPGA的image。
这样的好处是在于,因为每天RTL的改动会比较小,如果整个流程中出现什么错误,我们就很容易找出是由哪一部分的RTL代码改变引起我们现在出现的问题。
这样子的话,我们就只需要很小的effort,就可以把这个问题解决。
lcytms
发表于 2017-2-26 22:16:13
17
但要实现这一个全自动化的流程的话,我们就需要有一些这种自动化的这种脚本。
我们现在的做法是在我们的一个服务器上,实现了一个全自动化的这种nightly build的一个这样的脚本。
这个脚本每天在一个定时的时候会去design team的RTL GIT repo里面,就是代码库里面去下载最新的RTL代码,然后完成一个全自动化的系统集成,然后产生我们的FPGA的top level。
然后在此基础上,还会在我们的仿真的平台上进行一个简单的功能性的仿真。
如果这个功能性的仿真可以通过的话,还可以自动地完成后端,比如说综合布局布线的相关工程,工作,然后产生FPGA的image。
但是,就是说在我们把这个FPGA的image,release给最终的用户之前,往往我们还缺少一个步骤,我们需要把image,download到我们的FPGA的板子上进行一些简单的测试。