| 
SOPC_2006_Seminar
中文
2004年,Aldec公司在EDA商会上举办了成立20周年庆祝会。Aldec公司自1984年以来一直致力于IC产品的仿真技术开发。通过23年的努力,公司的产品以其高效易用的特性占据了FPGA验证工具市场龙头位置。Aldec公司持续的业绩增长缘于混合语言的单内核仿真引擎的不断革新,这些混合语言主要包括:VHDL, Verilog,SystemC和System Verilog。
随着近期硬件加速仿真技术的发布,Aldec公司的产品为客户提供了更高的仿真性能,并且提供了一些复杂设计问题的解决方法;而这些设计问题在以往通常要等待硬件原型集成测试后才能够察觉。
到目前为止,Aldec公司发布了以下四种产品:
- Active-HDL
它是业内最优的、完整的FPGA设计解决方案。
- Riviera
它是支持多种操作系统平台的高性能HDL仿真器,不仅可以用于复杂的FPGA设计验证项目,同样可以满足大型ASIC设计验证的需求。
- HES
硬件仿真加速平台。在平台中,通过将~大型仿真验证系统中的~可综合实现的部分~移植到~硬件原型电路板中,将剩下的小部份行为级的代码保留在软件仿真环境里,使得大型仿真验证系统的~仿真性能~在速度和工作效率上~得到~大幅度的提升。
- CoVer
从~字面上看,它是~Co-Verification~这个单词的缩写。在SOC与SOPC设计领域中,它能够为用户~提供高效的,易搭建的~软/硬件协同验证~平台;使得软/硬件协同验证~在速度上~得到上百倍,甚至上千倍的提升。
Page 3
HW/SW协同设计最重要的特点就是能够有效缩短SoC/SOPC产品的开发周期。与传统的设计方法相比,通常能够提前4~8周的时间。
道理很容易明白。传统的SoC/SOPC设计流程中,软、硬件的集成必须要等待硬件原型加工完成后才能进行。并且,硬件原型与软件的集成测试过程中往往会出现大量的软/硬协作问题,为了解决这些问题,软件工程师通常需要对软件多次的反复调试,修正。在最糟糕的情况下,可能会需要硬件设计返工。
如果您采用HW/SW协同设计的工具,那么就可以将软、硬件的集成提前到产品的设计阶段;软、硬件的绝大部分协作问题在这个阶段将被解决掉。因此,当硬件原型回来后的软、硬件集成测试时,工程师遇见的问题将会少很多。
因此,如果您采用HW/SW协同设计工具,您将会获得两个最显著的好处:
- 缩短设计开发流程,从而有效降低项目成本;
- 更高的产品质量保证。
如果您是硬件工程师,您将从中获得以下的好处:
- 可以进行更全面的验证(例如由软件运行过程中产生的硬件错误);
- 减少testbench的开发时间(软件本身已经成为了testbench的一部分);
- 定位HW/SW接口的错误(这些错误往往来自于软、硬件工程师对接口规格理解的差异以及memory映射的不一致);
如果您是软件工程师,您将从中获得以下的好处:
- 尽早的在目标硬件环境中运行代码,而不用等待硬件原型的加工;
- 更早的了解硬件的特性;
- 在仿真环境中很好的分析和调整软件代码。
Page 4
对于SOPC设计来说,协同设计的方法除了缩短设计周期外,还能够提供更高的SOPC产品质量。
对于硬件工程师来说,运行在NIOS-2处理器上的软件就是一个传输级的testbench,从而允许硬件工程师编写更加简洁高效的仿真测试代码,同时不会降低测试代码的覆盖率。
对于软件工程师来说,最大的好处就在于能够尽早的在目标硬件环境中运行软件代码。同时,软件工程师不必再象以前那样自己编写虚拟的用户硬件模型代码,而是将精力集中在软件调试工作上,从而在更短的时间内获得更好的软件代码。而且由于能够更早的在目标硬件中运行代码,软件工程师将能更好的了解硬件的特性,更早的发现自身对硬件规格的理解偏差。
综合起来看,在设计阶段实施HW/SW的协同验证工作将使得软件引发的硬件错误或者由硬件引发的软件错误能够尽早的被发现和修改。
Page 5
到目前为止,在SOPC验证流程中还没有一个简单的方法来实现HW/SW协同设计。通常情况下,用户只能在HDL仿真器中对设计中的软、硬件部分进行联合仿真。
SOPC Builder软件产生HDL代码文件,这些代码文件描述了处理器系统的硬件行为。同时通过SOPC IDE环境,工程师将得到软件编译后的HEX文件。这个HEX文件在HDL仿真初始化时将被写入到系统存储器硬件模型中。
这种方法虽然提供了时间精确的系统软、硬件协同验证能力,但是有以下的缺陷:
- 仿真是面向硬件模型的,因此无法提供软件的调试能力;
- 很难发现软件的设计问题;
- 指令的执行速度慢,一般只能达到1K cycles/s;
- 随着设计复杂度的增加,仿真时间呈非线形的大幅度增长;在此环境下,复杂算法系统的验证变得不现实;一个完备的测试过程往往需要几天甚至几周的时间来完成;
- 使得RTOS的加载以及用户应用软件的运行调试变得不现实。
Page?? 6
因此,一个有效的HW/SW协同设计方法必须具有以下的能力:
- 提供C/C++软件代码的调试能力;
- 选择性的硬件仿真能力,例如HDL仿真;
- 更高的仿真执行速度。
我们要采用怎样的方法才能获得这些能力呢?
Page 7
在一个纯仿真环境中,我们不可能获得很高的仿真执行速度。因此,引入基于FPGA的HW/SW协同设计不失为一种很好的解决方案。
我们可以将一个设计大体分为以下两个部分:
- NIOS-2处理器,存储器以及标准外设(图中的蓝色虚线框部分);
- 用户自定义开发的外设(图中的绿色虚线框部分)。
其中,第一部分由SOPC Builder产生,这一部分不需要复杂的硬件调试,因此我们可以将这一部分的设计放入FPGA原型板中。
第二部分的设计以及Avalon总线模型将保留在HDL仿真环境中,以便于进行调试。
在这样的验证平台中要实现HW/SW协同验证,HDL仿真器必须能够与FPGA原型板实现通信。这种通信的能力通过低层接口驱动以及仿真器的API函数库来实现。
为了获得软件代码的调试能力,必须存在一种软件调试工具(在本图中为NIOS-2 IDE Debugger),并且调试工具必须具有和FPGA原型板的通信能力。同样的,这种通信的能力通过低层接口驱动以及调试工具中的API函数库来实现。
总结起来,这样的HW/SW协同设计平台包含以下内容:
- FPGA原型板;
- 具有与FPGA原型板通信能力的HDL仿真器;
- 具有与FPGA原型板通信能力的NIOS-2软件调试器;
- 设计划分工具,将设计划分为两个部分。
Part 8
看了上述的胶片,大家可能觉得协同设计很简单,很容易实现。但事实上,在如何将HDL仿真器和FPGA原型板互连起来并且同步化通信的问题上,我们将会遇到进退两难的局面:是以FPGA原型板作为同步的基准,还是以HDL仿真器作为同步的基准呢?
其中一个可能的解决方法就是将HDL仿真器作为协同验证系统的中心部分。然后将testbench产生的时钟来驱动所有的系统模块——包含FPGA原型板和HDL仿真器。
但是,这种方法将给我们带来无法解决的难题。因为如果以HDL仿真器作为系统同步的基准,FPGA原型板的工作频率将大大受到限制,一般最高工作频率为100 KHz。这远远
无法满足高效协同验证对于速度的要求,并且NIOS-2无法工作在KHz级别的频率下。
因此,我们可以得出以下的结论:
对于NIOS-2 SOPC来说,不能将HDL仿真器作为协同设计平台中的中心组件。
Page 9
如何来解决这个问题呢?
首先,我们将时钟晶振的输出接到FPGA原型板上。只要时钟的频率高于20MHz,NIOS-2处理器就可以正常工作了。
然后,HDL仿真器中的设计模型工作时钟是由testbench产生的;FPGA原型板部分的设计与HDL仿真器中的设计是失步的。很显然,这两部分不能够直接进行通信。
因此,我们还需要开发一个特定的同步化模块。
Page 10
Aldec公司开发了拥有专利权的Smart Clock Bridge技术,它很好的解决了FPGA原型板与HDL仿真器之间的同步化问题。
Smart Clock Bridge监视着Avalon总线,一旦发现总线上出现了程序空间的访问操作,Smart Clock Bridge将整个系统时钟切换到HDL仿真器中的时钟源上。通过这种方式,FPGA原型板可以经由Bridge模块建立起与HDL仿真模型的同步通信。一旦通信完成后,Smart Clock Bridge将整个系统时钟切回到硬件时钟晶振上。
因此我们可以看到,Smart Clock Bridge是通过在两种时钟之间的切换来实现FPGA原型板与HDL仿真器之间的同步通信的。这两种时钟可以描述为:
- HW CLK——硬件时钟晶振产生的时钟;
- SW CLK——HDL仿真模型的工作时钟(由testbench产生)。
用户可以根据需要对Smart Clock Bridge进行自定义配置。Smart Clock Bridge是基于系统存储空间映射来工作的,用户在使用Smart Clock Bridge前,需要对被称为“软件时钟窗口”的参数进行配置。
配置完成后,一旦发现Avalon总线上的传输目的地址位于“软件时钟窗口”对应的地址空间时,Smart Clock Bridge将把系统时钟切换到SW CLK。一旦系统工作在SW CLK时钟下,总线上的所有传输将只在HDL仿真模型之间进行。
Page 11
让我们来大致了解一下Smart Clock Bridge的结构。
如前面所述,Smart Clock Bridge的主要功能是实现系统时钟在HW CLK和SW CLK之间的切换。Smart Clock Bridge的核心模块叫做Smart Controller,它实时监视着Avalon总线,并根据传输的地址范围决定是否需要切换系统时钟。
另外一个模块称为“SW CLK address slots configuration table module”。它记录了系统存储空间映射的信息。
Smart Controller可以工作在多master设备的系统里,并且master设备可以放在FPGA原型板上,也可以位于HDL仿真器中。一旦位于HDL仿真器中的master设备发起传输,那么Smart Controller将把系统时钟切换到SW CLK。
容易理解,一旦系统时钟工作在SW_CLK状态下,Smart Clock Bridge对于总线传输来说是透明的,所有的传输都是在HDL仿真模型间进行的。
Page 12
显而易见,由于HDL仿真器只是在需要和FPGA原型板进行通信时,FPGA原型板的工作时钟才会由高频率的晶振信号切换到低频率的SW CLK。因此在大部分的仿真时间内,FPGA原型板的仿真速度是很快的。
如果将所有的系统标准模块放在FPGA原型板内,HDL仿真器的行为可以只占整个系统仿真行为的5%。其余95%的仿真工作将以FPGA原型板的工作频率进行。
Page 13
本页的表格显示了在以下条件成立时的理论仿真速度:
- FPGA原型板承担了95%的仿真事务;
- FPGA原型板工作在50 MHz频率下;
- HDL仿真器最快可以仿真100 KHz的硬件行为。
为了计算平均速度,我们首先根据表中的计算公式算出平均的时钟周期。计算结果显示整个系统的平均速度可以达到1.9 MHz。这个数值大概是纯HDL仿真验证环境下仿真速度的1900倍。1.9 MHz的仿真速度完全可以实现复杂的算法软件调试以及RTOS的加载。
Page 14
本页展示了三个实际的例子,前两个展示了新方法带来的仿真速度上的大幅度提升;最后一个展示了在设计效率上的改善。
Page 15
随着客户要求的提高,SOPC设计在面积和复杂度上不断的遭遇新的挑战。而这还不是首要的问题,客户往往更加关注SOPC的计算能力。
单单靠提高FPGA工作频率来解决这个问题是不实际的。因为随着频率的增加,我们需要能够高速运行的FPGA芯片,并且功耗也将成为一个很大的问题。因此,一种比较好的解决办法就是采用多处理器的设计。
SOPC Builder可以很好的支持多处理器设计,它提供了特定的多处理器同步IP核来实现多处理器件的通信。
然而,多处理器的设计给软件的实现和调试带来了很大的问题,例如:
- 多任务间的协作问题;
- 线程间互锁及资源冲突的问题;
- 线程间的数据保护问题。
如果我们单单通过FPGA原型板进行多处理器的软件调试,那么由于我们无法监视FPGA原型板内部的总线动作而导致调试工作无法开展。
上述的协同设计平台可以很好的解决这个问题,只是需要软件调试工具能够提供多处理器的调试通道,每个处理器单独拥有一个调试通道。
Page 16
Aldec的协同设计平台方案可以很容易的应用于多NIOS-2处理器设计,只需要在平台中加入一个叫做Multi-Channel DEBUG Controller (MCDC)的部件。
设计中的每个NIOS-2处理器单独拥有一个调试通道接口(通常是串口接口方式)。MCDC将所有的调试通道与一个NIOS-2 IDE调试器连接起来,因此用户可以很容易的实现不同处理器任务间的调试切换。这种C/C++代码调试的方法能够改善工程师的工作效率,在短时间内完成高质量的设计。
欢迎您对该软件给予评论 [ 发表评论 ]
[ 查看留言 ]
|