rapidio协议代码(rapidio协议)
最后更新：2024-01-21 01:30
XDMA 如何转换local bus接口
利用usbUSB需要外部的PHY对接FPGA，而且需firmware；以太网走到TCP才会保证不丢数据；PCI逐渐淘汰了，占用引脚多，而且带宽有限；SATA侧重存储，其协议的局限性比较高；RapidIO在一些场合使用，结构可以做到Full Mesh结构，但是这些年发展速度比较慢。而PCIe具备如下优点：A. 带宽高，目前FPGA有PCIe Gen3 x16，或者PCIe Gen4 x8，链路速度可以达到128Gbps;B. FPGA直连，不需要外部PHY;C. 协议保证数据无误传输，两级CRC，重传机制，保证数据无误;D. 软件生态丰富，各种系统原生支持，通过简单的驱动就可以完成数据交互;E. 在PCIe之上的协议逐渐增多，例如NVMe是基于PCIe的上层协议; Xilinx从15年前，V4系列开始，一直在PCIe的解决方案上深耕，提供众多的应用方案级的解决方案，方便用户专注于自己的应用。早期，Xilinx提供的有Application Notes，例XAPP859，XAPP1052等，构建了基本的双向数据传输。当时一些第三方公司，类似于PLDA，NwLogic也出针对Xilinx FPGA的PCIe传输方案。
惠普8640型i3的显卡是独立的显卡，还是集成显卡？
是独立显卡 ，不过是2012年左右的入门级独立显卡
基于PowerPC8640处理器的通用处理模块设计 电子技术应用2016-01-28摘 要： 随着新一代飞机机载电子设备综合化、智能化的发展，系统对机载电子设备的处理能力需求越来越高。借鉴国外高性能嵌入式计算机的设计原则，设计了一种基于高性能处理器PowerPC8640的通用处理模块，并对部分功能单元的设计进行描述。该模块具有数据处理能力强、功能扩展性强、通用性强、集成度高、高速外部串行总线接口等特点，具有较高的应用价值，目前该模块已经应用于多种机载电子设备中。0 引言随着新一代战机的出现和战技指标需求的不断攀升，机载航电设备作为航空电子产品中的重要一员，其功能和性能也要得到不断的完善和提高，同时体积和重量却要求不断减小，以满足战机的作战需求。功能的完备和性能的提高带来了大量数据的处理需求，需要高性能的处理器完成相关的任务，体积和重量的减少要求产品上的器件密度越来越高。本文主要介绍基于PowerPC8640处理器的高性能高集成度的通用处理模块的设计，它采用通用化设计思想、标准的ASAAC结构以及可配置性的设计，可用于多种机载电子系统[1]。1 系统概述本文所描述的通用处理模块是基于PowerPC8640高性能处理器，设计采用两片PowerPC8640，周边配置有存储器（包括DDR2、Flash和NvRAM）、看门狗、高速RapidIO接口、高速串行接口、CAN总线、离散量接口、422接口、485接口、温度监控、RTC和调试接口等资源。模块设计采用两块印制板，其结构图如图1所示。模块的结构采用标准的ASAAC结构，模块盒体尺寸（不包括连接器）为233.4 mm×160mm×24mm，散热方式为传导散热，通过模块的锁紧条传导到机箱进行散热。2 模块平台介绍2.1 PowerPC8640处理器简介PC8640属于PowerPC的处理器，目前已在国外数据处理与信号处理中采用。一片PC8640中提供1个e600内核，主频最高可达1.25 GHz，e600内核提供1 MB的高带宽、低延迟的L2 cache，设计中主频设为1 GHz。PC8640有两个64位的DDR2控制器接口，最高工作频率533 MHz。PC8640处理器使用e600核和高速内部互连技术来平衡处理器的性能与I/O系统的吞吐率。PC8640配置了两种灵活的高性能I/O接口。一种是×1、×2、×4、×8 PCI Express接口，采用PCI-E总线实现板级高性能设备的串行点对点互连；另一种是1×、4×线串行RapidIO接口，由于RapidIO总线具有软件开销小、配置简单、硬件纠错等特点，且支持存储器映射和包传输机制，非常适合作为底板接口。PC8640还配置了4个以太网控制器，支持10 Mb/s，100 Mb/s和1 000 Mb/s速率通信。每个以太网控制器可以转换为FIFO模式实现高效ASIC互连。此外PC8640还配置有UART接口、中断控制器、DMA控制器、GPIO等资源[2]。设计采用两片PC8640处理器，每片处理器的存储器资源、调试接口、温度检测、RTC资源独立，其他资源如离散量、422接口、485接口等资源是共用的。2.2 其他资源设计模块的存储器包括DDR2存储器、Flash存储器和NvRAM存储器。PC8640对外提供DDR2接口和HLP总线接口。PC8640的DDR2接口外接64位数据宽度的1 GB的DDR2 SDRAM；PC8640的HLP总线接口外接Flash和NvRAM。PC8640对外提供两路I2C总线，分别连接实时时钟和温度监测芯片，提供RTC和温度监测功能。PC8640对外提供调试接口，包括串口、以太网接口和JTAG接口，用于处理器以及软件的调试。处理器PC8640集成两个高速串行I/O接口（Serdes1和Serdes2），设计中将每个处理器的两个Serdes接口设置为×4 PCI-E模式和×4 RapidIO模块。Serdes1接口连接处理器和高速串行接口，用于实现高速串行接口通信控制，接口为PCI-E总线；Serdes2接口连接处理器和RapidIO交换芯片，接口为RapidIO总线。RapidIO交换芯片配置为3个4×RapidIO接口，10个1×RapidIO接口。4×RapidIO接口其中2路接处理器，1路引到底板；1× RapidIO接口10路引到底板上。高速串行接口实现2路，其中一路协议处理采用固定的逻辑版本；另外一路协议处理根据系统应用需要，可通过处理器控制加载不同的逻辑版本。两路高速串行接口的传输介质为光接口，通过光电转换芯片连接到底板连接器。422、485接口采用IP核在FPGA内部实现，处理器通用HLP总线控制422、485接口的收发数据。模块对外提供5路CAN总线接口，采用协议芯片实现，CAN总线接口挂在处理器控制FPGA下，接口采用SPI接口。模块对外提供多路差分的TTL输入输出信号、多路LVDS输入输出信号、多路LVTTL输入输出信号、多路MLVDS输出信号以及多路Aurora总线接口。底板连接器为带光纤接口的数字连接器，A腔包含2芯光纤接口和135芯低频接触件，B腔包含252芯低频接触件。3 设计要点3.1 高速接口重加载设计由于本文设计的是通用处理模块，高速串行接口也要适应多种机载电子设备，不同设备的配置共包括：2路高速串行接口、1路双余度的高速串行接口、1路单余度的高速串行接口等。高速串行接口的逻辑规模很大，因此将高速串行接口设计为2路，一路可重加载，另一路为固定的逻辑。下面说明高速串行接口重加载的设计实现。加载控制电路的设计框图如图2所示。加载控制、状态信号采用3.3 V电压，通过处理板FPGA控制，输出给CPLD，实现对逻辑重加载的控制。加载控制信号通过3个控制离散量分别表示3个不同逻辑状态，通过一个控制信号指示逻辑重载开始，通过处理器控制。加载控制时序如图3所示。加载及控制流程说明如下：（1）处理器的控制FPGA和CPLD中，重加载设计默认状态都为001，CPLD上电后固定加载PROM0中的逻辑；（2）处理器启动后，根据系统要求，首先判断加载的默认状态高速串行接口逻辑是否为系统所需要的，如果是，则处理器不再发起重加载，如果不是，则先设置加载控制离散量状态（每位设置为“1”，表示加载对应位的PROM中的逻辑；为“0”，表示不加载），然后将加载控制离散量置位为“1”，启动加载，此时处理器软件检测逻辑加载状态信号，在该信号为“1”后，表示加载完成，可对设备进行初始化；（3）CPLD在加载控制信号的上升沿启动加载，通过控制FPGA的Program_B信号控制逻辑重载[3]；（4）CPLD在完成逻辑加载后（判断FPGA给出的Done信号为“1”），处理器发起逻辑复位操作，在复位结束后，将加载完成状态离散量置位为“1”；（5）处理器软件在判断逻辑加载完成，将加载控制信号重新置位为“0”，以便于下次可用于逻辑重载。3.2 软件设计由于设计的是通用处理模块，在软件方面也需要满足多种机载电子设备的要求。处理器、存储器资源、接口资源在不同设备中是相同的，软件也完全相同。而高速串行接口在不同的设备中有不同的需求，驱动不同，因此在软件设计时，考虑到多种设备中使用同一款软件，需将不同的高速串行接口驱动固化在Flash的不同地址，根据系统设备需求，加载相应的软件驱动，具体实现如下：模块加电后，处理器需到Flash取指令，初始化模块，引导运行操作系统以及应用程序。因此在模块初始化完成后，设置选项，通过不同的参数选择不同软件驱动，以适应不同设备的需求。如参数设置为0，模块操作系统启动后，加载第一种设备的高速串行接口驱动以及其他驱动，这样应用程序启动后可直接调用相关的驱动函数。如果参数设置为1，模块操作系统启动后，加载第二种设备的高速串行接口驱动以及其他驱动，参数设置为2，加载第三种设备的高速串行接口驱动以及其他驱动。该参数固定在Flash中，不会随着模块下电而消失，用户只需要设置一次，下次模块上电后，会根据已经设置好的参数加载相应驱动，如需改用其他设备，只需要修改一次参数即可。4 结论本文结合高性能的PowerPC8640处理器的特征，设计了一种双处理器的通用处理模块，对外提供高速串行接口、CAN总线、RapidIO总线、422接口、485接口、多种形式的离散量接口以及处理器的调试接口，高速串行接口可适用于多种电子设备。该模块设计的目的是为了满足新一代飞机多种机载设备的需要，与系统中其他设备进一步综合，使机载设备整体性能达到最优，该模块具有很大的应用价值。参考文献[1] 汤艳飞，文敏华.基于MPC8640D处理系统的技术研究[J].航空计算技术，2012，42（1）：120-122.[2] Freescale Semiconductor， Inc. MPC8640DRM[EB/OL]. （2008-07-xx）[2014-10-31].http：//www.freescale.com.[3] Xilinx， Inc. Virtex-5 FPGA Data Sheet[EB/OL]. （2008-07-xx）[2014-10-31].http：//www.xilinx.com.
基于PowerPC8640处理器的通用处理模块设计 电子技术应用2016-01-28摘 要： 随着新一代飞机机载电子设备综合化、智能化的发展，系统对机载电子设备的处理能力需求越来越高。借鉴国外高性能嵌入式计算机的设计原则，设计了一种基于高性能处理器PowerPC8640的通用处理模块，并对部分功能单元的设计进行描述。该模块具有数据处理能力强、功能扩展性强、通用性强、集成度高、高速外部串行总线接口等特点，具有较高的应用价值，目前该模块已经应用于多种机载电子设备中。0 引言随着新一代战机的出现和战技指标需求的不断攀升，机载航电设备作为航空电子产品中的重要一员，其功能和性能也要得到不断的完善和提高，同时体积和重量却要求不断减小，以满足战机的作战需求。功能的完备和性能的提高带来了大量数据的处理需求，需要高性能的处理器完成相关的任务，体积和重量的减少要求产品上的器件密度越来越高。本文主要介绍基于PowerPC8640处理器的高性能高集成度的通用处理模块的设计，它采用通用化设计思想、标准的ASAAC结构以及可配置性的设计，可用于多种机载电子系统[1]。1 系统概述本文所描述的通用处理模块是基于PowerPC8640高性能处理器，设计采用两片PowerPC8640，周边配置有存储器（包括DDR2、Flash和NvRAM）、看门狗、高速RapidIO接口、高速串行接口、CAN总线、离散量接口、422接口、485接口、温度监控、RTC和调试接口等资源。模块设计采用两块印制板，其结构图如图1所示。模块的结构采用标准的ASAAC结构，模块盒体尺寸（不包括连接器）为233.4 mm×160mm×24mm，散热方式为传导散热，通过模块的锁紧条传导到机箱进行散热。2 模块平台介绍2.1 PowerPC8640处理器简介PC8640属于PowerPC的处理器，目前已在国外数据处理与信号处理中采用。一片PC8640中提供1个e600内核，主频最高可达1.25 GHz，e600内核提供1 MB的高带宽、低延迟的L2 cache，设计中主频设为1 GHz。PC8640有两个64位的DDR2控制器接口，最高工作频率533 MHz。PC8640处理器使用e600核和高速内部互连技术来平衡处理器的性能与I/O系统的吞吐率。PC8640配置了两种灵活的高性能I/O接口。一种是×1、×2、×4、×8 PCI Express接口，采用PCI-E总线实现板级高性能设备的串行点对点互连；另一种是1×、4×线串行RapidIO接口，由于RapidIO总线具有软件开销小、配置简单、硬件纠错等特点，且支持存储器映射和包传输机制，非常适合作为底板接口。PC8640还配置了4个以太网控制器，支持10 Mb/s，100 Mb/s和1 000 Mb/s速率通信。每个以太网控制器可以转换为FIFO模式实现高效ASIC互连。此外PC8640还配置有UART接口、中断控制器、DMA控制器、GPIO等资源[2]。设计采用两片PC8640处理器，每片处理器的存储器资源、调试接口、温度检测、RTC资源独立，其他资源如离散量、422接口、485接口等资源是共用的。2.2 其他资源设计模块的存储器包括DDR2存储器、Flash存储器和NvRAM存储器。PC8640对外提供DDR2接口和HLP总线接口。PC8640的DDR2接口外接64位数据宽度的1 GB的DDR2 SDRAM；PC8640的HLP总线接口外接Flash和NvRAM。PC8640对外提供两路I2C总线，分别连接实时时钟和温度监测芯片，提供RTC和温度监测功能。PC8640对外提供调试接口，包括串口、以太网接口和JTAG接口，用于处理器以及软件的调试。处理器PC8640集成两个高速串行I/O接口（Serdes1和Serdes2），设计中将每个处理器的两个Serdes接口设置为×4 PCI-E模式和×4 RapidIO模块。Serdes1接口连接处理器和高速串行接口，用于实现高速串行接口通信控制，接口为PCI-E总线；Serdes2接口连接处理器和RapidIO交换芯片，接口为RapidIO总线。RapidIO交换芯片配置为3个4×RapidIO接口，10个1×RapidIO接口。4×RapidIO接口其中2路接处理器，1路引到底板；1× RapidIO接口10路引到底板上。高速串行接口实现2路，其中一路协议处理采用固定的逻辑版本；另外一路协议处理根据系统应用需要，可通过处理器控制加载不同的逻辑版本。两路高速串行接口的传输介质为光接口，通过光电转换芯片连接到底板连接器。422、485接口采用IP核在FPGA内部实现，处理器通用HLP总线控制422、485接口的收发数据。模块对外提供5路CAN总线接口，采用协议芯片实现，CAN总线接口挂在处理器控制FPGA下，接口采用SPI接口。模块对外提供多路差分的TTL输入输出信号、多路LVDS输入输出信号、多路LVTTL输入输出信号、多路MLVDS输出信号以及多路Aurora总线接口。底板连接器为带光纤接口的数字连接器，A腔包含2芯光纤接口和135芯低频接触件，B腔包含252芯低频接触件。3 设计要点3.1 高速接口重加载设计由于本文设计的是通用处理模块，高速串行接口也要适应多种机载电子设备，不同设备的配置共包括：2路高速串行接口、1路双余度的高速串行接口、1路单余度的高速串行接口等。高速串行接口的逻辑规模很大，因此将高速串行接口设计为2路，一路可重加载，另一路为固定的逻辑。下面说明高速串行接口重加载的设计实现。加载控制电路的设计框图如图2所示。加载控制、状态信号采用3.3 V电压，通过处理板FPGA控制，输出给CPLD，实现对逻辑重加载的控制。加载控制信号通过3个控制离散量分别表示3个不同逻辑状态，通过一个控制信号指示逻辑重载开始，通过处理器控制。加载控制时序如图3所示。加载及控制流程说明如下：（1）处理器的控制FPGA和CPLD中，重加载设计默认状态都为001，CPLD上电后固定加载PROM0中的逻辑；（2）处理器启动后，根据系统要求，首先判断加载的默认状态高速串行接口逻辑是否为系统所需要的，如果是，则处理器不再发起重加载，如果不是，则先设置加载控制离散量状态（每位设置为“1”，表示加载对应位的PROM中的逻辑；为“0”，表示不加载），然后将加载控制离散量置位为“1”，启动加载，此时处理器软件检测逻辑加载状态信号，在该信号为“1”后，表示加载完成，可对设备进行初始化；（3）CPLD在加载控制信号的上升沿启动加载，通过控制FPGA的Program_B信号控制逻辑重载[3]；（4）CPLD在完成逻辑加载后（判断FPGA给出的Done信号为“1”），处理器发起逻辑复位操作，在复位结束后，将加载完成状态离散量置位为“1”；（5）处理器软件在判断逻辑加载完成，将加载控制信号重新置位为“0”，以便于下次可用于逻辑重载。3.2 软件设计由于设计的是通用处理模块，在软件方面也需要满足多种机载电子设备的要求。处理器、存储器资源、接口资源在不同设备中是相同的，软件也完全相同。而高速串行接口在不同的设备中有不同的需求，驱动不同，因此在软件设计时，考虑到多种设备中使用同一款软件，需将不同的高速串行接口驱动固化在Flash的不同地址，根据系统设备需求，加载相应的软件驱动，具体实现如下：模块加电后，处理器需到Flash取指令，初始化模块，引导运行操作系统以及应用程序。因此在模块初始化完成后，设置选项，通过不同的参数选择不同软件驱动，以适应不同设备的需求。如参数设置为0，模块操作系统启动后，加载第一种设备的高速串行接口驱动以及其他驱动，这样应用程序启动后可直接调用相关的驱动函数。如果参数设置为1，模块操作系统启动后，加载第二种设备的高速串行接口驱动以及其他驱动，参数设置为2，加载第三种设备的高速串行接口驱动以及其他驱动。该参数固定在Flash中，不会随着模块下电而消失，用户只需要设置一次，下次模块上电后，会根据已经设置好的参数加载相应驱动，如需改用其他设备，只需要修改一次参数即可。4 结论本文结合高性能的PowerPC8640处理器的特征，设计了一种双处理器的通用处理模块，对外提供高速串行接口、CAN总线、RapidIO总线、422接口、485接口、多种形式的离散量接口以及处理器的调试接口，高速串行接口可适用于多种电子设备。该模块设计的目的是为了满足新一代飞机多种机载设备的需要，与系统中其他设备进一步综合，使机载设备整体性能达到最优，该模块具有很大的应用价值。参考文献[1] 汤艳飞，文敏华.基于MPC8640D处理系统的技术研究[J].航空计算技术，2012，42（1）：120-122.[2] Freescale Semiconductor， Inc. MPC8640DRM[EB/OL]. （2008-07-xx）[2014-10-31].http：//www.freescale.com.[3] Xilinx， Inc. Virtex-5 FPGA Data Sheet[EB/OL]. （2008-07-xx）[2014-10-31].http：//www.xilinx.com.
uvm为了什么原因才引入factory机制
如果你的cpu env将会作为另一个更大level的一个agent组件，情况就变得有点糟糕了； 如果你的cpu env将会例化很多个，用在一个更大level的环境里，情况就变得更糟糕了；如果你的pcie driver被作为一个component单独用在一个大环境的很多地方，且分布于树形结构的不同深度的话，简直是噩梦！再假如，目前我有一个环境，有10个pcie driver，其中5个作为sub component用在5个cpu agent里面，另外5个pcie driver单独作为sub component用在top env（前面的5个cpu agent包含于top env中）里面。我现在想吧cpu agent里面的3个pcie driver换成rapidio driver，剩下的2个保持pcie driver不变；top level里面的5个pcie driver也有相似的需求，如果是用方法（1）改代码，那你的测试平台将会很糟糕，不具有任何可扩展性，容易出错等等....... 不同的需求回很多，因为需求永远是在变化的，我们需要一种方法来很好的适应这种变化，factory机制就可以做到。
1.factory的需求来源 我们的测试平台一般都是通过component来组织成一个层次化的树形结构的，测试平台做什么事情取决于各个包含在其中的函数或者任务。总有一些时候，我们希望改变现有的处理机制或者流程。举例来说，我有一个通用的CPU总线的测试平台，在上层看来（软件同事们），这个东西对他们开放的接口就是两个：read（address，length），write（address，data），他们不管下面是PCIe还是RapidIO。假设目前的底层接口形式是PCIe总线，也就是说这个CPU agent中的的driver是一个PCIe的driver；有一天CPU换了，底层接口形式也跟着换成了RapidIO总线，那之前的CPU总线的测试平台能不能除了换个RapidIO的driver，其它不变？如果测试平台做的够好，应该是这个结果。但是怎么个换法？（1）把cpu agent.sv找到，改代码,至少有一个地方需要如下改改pcie_driver drv； ---》 rapidio_driver drv;（2）其他更好的方法？测试平台不用动，只需要在testcase中说明我现在希望用RapidIO driver来替换PCIe的driver。我们当然喜欢第二种。当然如果你的cpu env是一次性的，第一种方法也不错，如果是那样的话就与UVM思想相违背了，也会挨你继任同事的骂。如果你的cpu env将会作为另一个更大level的一个agent组件，情况就变得有点糟糕了；如果你的cpu env将会例化很多个，用在一个更大level的环境里，情况就变得更糟糕了；如果你的pcie driver被作为一个component单独用在一个大环境的很多地方，且分布于树形结构的不同深度的话，那方法（1）简直是噩梦！再假如，目前我有一个环境，有10个pcie driver，其中5个作为sub component用在5个cpu agent里面，另外5个pcie driver单独作为sub component用在top env（前面的5个cpu agent包含于top env中）里面。我现在想吧cpu agent里面的3个pcie driver换成rapidio driver，剩下的2个保持pcie driver不变；top level里面的5个pcie driver也有相似的需求，如果是用方法（1）改代码，那你的测试平台将会很糟糕，不具有任何可扩展性，容易出错等等.......不同的需求回很多，因为需求永远是在变化的，我们需要一种方法来很好的适应这种变化，factory机制就可以做到。2.我心目中的UVM factory的演进2.1 使用继承来解决2.1.1 前提：（1）有一个基类叫做cpu_bus_driver，所以的cpu总线的driver都从这个base class继承（2）cpu_bus_driver中定义一系列的总线操作，而且这写总线操作对它的任何继承者来说都是充分的：get_transfer（）：得到此次cpu操作类型（read or write），地址，长度，写数据drive_bus（）：把读写操作转化成最后的signal level的信号get_response（）：返回读数据或者写是否成功的响应（如果需要的话）当然这些函数都是virtual的。（3）cpu_bus_agent中这样实例化了driverclass cpu_bus_agent ;.......cpu_bus_driver driver ;function build();. .......driver = new("driver");. ........endfunction（4）测试平台的层次结构是：cpu_env.cpu_agent.cpu_drivercpu_env在cpu_base_test中实例化。2.1.2 方法step1：定义新类：new_cpu_bus_driverclass new_cpu_bus_driver extends cpu_bus_driver ;........定义自己的get_tranfer, drive_bus, get_response函数endclassstep2：替换原有的类。因为不能修改cpu_env及其一下各层次的代码，所以只能在testcase中进行替换：class cpu_test1 extends cpu_base_test ;new_cpu_bus_driver new_driver ;......new_driver = new("new_driver");cpu_env.cpu_agent.cpu_driver = new_driver ;.......endclass2.1.3效果没有修改任何cpu env及其一下层次的代码。2.1.4问题（1）上面标示的蓝色粗体为关键代码，但是这个语句的执行时间点需要精确把控。如果太早，则在运行cpu_agent.build()之后cpu_agent中的driver又会被重置为cpu_bus_driver而不是new_cpu_bus_driver；如果太晚，则可能cpu agent可能已经用cpu_bus_driver运行了一段时间了，然后才会切换成new_cpu_bus_driver，这样回导致前面的错误操作。最佳时间点显然是在所有的build phase之后，任何connection phase之前。（2）开发testcase的人需要准确的知道cpu env的层次结构，也就是说需要知道xxx.xxx.xxx.xxx形式，很显然这是个缺点；（3）如果有100个cpu driver需要替换，那么就需要100次cpu_env0.xxx.xxx.old_driver = new_driver ;....cpu_env99.xxx.xxx.old_driver = new_driver ;如果你觉得这个也不是问题，因为层次结构很规整嘛；那还有更麻烦的：old_driver被单独用到了一些地方而不是只用在了cpu agent里面，比如A_env.xxx.xxx.old_driver，B_env.xxx.old_driver，C_env.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.old_driver......那你准备怎么办？而且这种情况下缺点（2）的影响会更恶劣!2.2 第一次改进使用查找表来记录每个对象是否需要被替换。2.2.1 缺点的本质：（1）需要准确的时间点的本质原因是testcase不知道driver时候被创建的确切时间！所以需要找个最保险的时间点，那就是在所有的组件都创建之后，但是又不能早于connection phase，幸好uvm提供了各个phase的管理，否则这个问题解决起来就特别棘手！我们选择的时间点过于保守了，最合适的时间点就是在需要被创建的时候就做替换！也就是说每个对象的new函数调用处就是最佳的替换时间点。（2）需要知道层次结构的本质是在testcase层次以下没有任何东西来记录每个对象的路径!如果有这么一个地方，它记录了所有存在于环境中的对象的路劲，那么我只需要对它说，把你的记录里面每个driver对象都换成new driver。我只想对这个记录中心提供如下信息：1）我需要替换所有的driver，无论它分布于何处，它的层次路劲如何2）把driver替换成new driver.其余的交给记录中心来完成，我不想知道怎么做。2.2.2 缺点的改进（1）怎么样才能在每个对象new的时候就能够做替换呢？首先，我们需要知道的一条重要的限制就是new函数返回的对象永远都是它声明的类类型的对象！也就是说 ：A a_obj ；=》任何时候我们调用a_obj = new；返回的对象永远是A类类型的，不可能是其他类，连A的继承类也不可能！就是注意点彻底的告诉我们，需要一种方法（假设叫create方法）来代替new函数，当我调用它的时候，它不是100%返回A类型，而是视情况而定，什么情况？那就是：当我不像替换A的时候它返回A类类型的对象；当我想用A的派生类A1替换A的时候它能返回A1类类型的对象；当我想用A的派生类A2替换A的时候它能返回A2类类型的对象..........我们不应该在这里用new，而是用create！（2）很明显，我们需要数据库来记录每个对象的基本信息第一个数据库的每个条目可能如下：层次路径 对象类型“a.b.c.obj1” A“a.b.obj2”B“a.b.obj3”A第二个数据库的每个条目可能如下：原对象的类型 希望被替换成的类型AA1BB2CC(也就是不替换)这种数据结构用关联数据再合适不过！2.2.3 实现对于缺点1的改进，按照我们的分析，应该做如下改变：a) 在cpu agent中创建driver的时候不用new函数，用另外一个叫做create的函数，用这个函数取代new函数。问题来了，这个create函数应该放在哪里？具有神马性质？首先，这个create函数可以放在cpu driver类及其子类中；或者外面。我们假设放在cpu driver类及其子类中。其次，既然能够取代new函数，那么必须不能针对于某一个具体对象，不然不能够调用；所以create应该是静态的。再则，我们的主要目的是需要这个函数视是否需要被替换的情况而来产生出对应的对象。达到这个目的可有很多种方法，最直观的一种是：在create之前我去中心数据库查一下先，如上述的第二个数据库，如果目前查到这样一条条目：/“原对象类型 cpu_bus_driver”，"需要替换"，“替换成的对象类型 new_cpu_driver”/,那么我就可以知道虽然实在调用cpu_bus_driver的create函数，但是实际上是想让我生成cpu_bus_driver的继承类new_cpu_bus_driver！对应缺点2的改进需求，我们可以建立一个数据库中心，取名叫做factory，它的核心内容就是若干个map，每个map中的条目都是为create函数来服务的。好了，基于上述的分析，我们写出如下的伪代码：class cpu_bus_driver ;.......virtual function cpu_bus_driver create_object();cpu_bus_driver me ;me = new ;return me ;endfunctionstatic virtual function cpu_bus_driver create();cpu_bus_driverkey;key = new ;new_driver = factory.create_object(factory.lookup(key));return new_driver ；endfunctionendclassclass new_cpu_bus_driver extends cpu_bus_driver;.......virtual function cpu_bus_driver create_object();new_cpu_bus_driver me ;me = new ;return me ;endfunctionstatic virtual function cpu_bus_driver create();new_cpu_bus_driverkey;key = new ;用key作为键字去factory的数据库中查出替换条目，得知想不需要替换factory利用查得的结果，生成一个new_cpu_driver对象给我，叫做 new_driverreturn new_driver ；endfunctionendclassclass factory ；cpu_bus_driver override_map [cpu_bus_driver] ;function cpu_bus_driver lookup(cpu_bus_driver key);return overrride_map[key];endfunctionfunction cpu_bus_driver create_object(cpu_bus_driver override_obj);return override_obj.create_object();endfunctionendclass好了，举例来说明一下具体的工作过程：a）声明一个 cpu_bus_driverdriver；b）调用 driver = cpu_bus_driver::create();b1）key = new ；////key是cpu_bus_driver类的b2）factory.lookup（key）；////返回一个new_cpu_bus_driver信息b3）factory.create_oject(new_cpu_bus_driver);b4）调用new_cpu_bus_driver::create（）；b5）new_cpu_bus_driver::create()调用new_cpu_bus_driver的new函数生成一个new_cpu_bus_drive类型的对象赋给driver经过上诉调用后driver就不是它声明是的cpu_bus_driver类型的一个对象了，而是一个地地道道的new_cpu_bus_drive类型的对象了，唯一一点的遗憾就是这个对象是用父类的句柄hold住的。2.3 第二次改进细心的朋友可能已经注意到上述实现的一个问题就是，factory的override map的键字是一个cpu_bus_driver的对象，而我的cpu_bus_driver类型的对象可能很多，举例来说如果override map中的cpu_bus_driver键字是一个叫做 “张三”的，很明显，如果我随意创建一个新的cpu_bus_driver类型的对象“李四”，虽然他们都是cpu_bus_driver类型的，但是用“李四”去查factory的override map时，就会查不到任何条目！这个就是2.2的实现中的一个问题！如何改进？很自然我们想到一种解决方案:用一个全局的众所周知的cpu_bus_driver对象去做键字。这个对象是给factory的override map专用的，不做他用，假设“张三”就是这样一个对象。这样一来问题就解决了，任何时候只要是想查询cpu_bus_driver类型的override条目，我只需要用 factory.override_map[“张三”]来查询即可！这个解决方案看起来好多了，也解决问题了，但是记得有一个前提就是：记得在进行任何查找override map[“张三”]之前，确保这个条目已经存在！看到这里，大家可能已经马上就想到了UVM中的factory register，没错！就是要向factory中注册！注册越早越好！2.4 第三次改进在第二次改进中，我们提议用一个众所周知的全局对象来向factory注册，然后用这个注册的全局对象来作为override map的查询的key来得出是否需要替换成别的子类的结论。这没有任何问题，但是不优美！原因有如下几点：（1）比如我有一个类叫做tcp_pkt，我希望我可以创建一个叫任何名字的tcp_pkt的对象，而不是叫“张三”的名字我不能取，因为这个“张三”被factory专用！在一个大型的环境中，会有很多个用户定义的类类型，比如除了tcp_pkt，还有ip_pkt，udp_pkt，还有其它方面的如ethernet_driver，ethernet_monitor.........假设设计中有100个类类型，那我岂不是要记着100个“张三”，“王三”，“李三”.......这些factory专用对象！（2）性能和效率太差！为什么这么说呢？如果我定义的类很复杂，那么这对象势必需要专用很大的内存，而每个类都需要一个factory专用对象，这些对象一直存在着[因为在override map随时都有可能需要lookup]，所以内存不释放！既然问题分析了，那就要找出对策了！问题在哪里？想一个问题：factory的override map里需要的最根本的信息是什么？没错，那就是类型而非一个具体对象！factory只想知道也只需要知道在我的override map里面有一个条目的含义是类型A需要不需要替换成A的子类，如果有，是A1还是A2还是其它.....我不像知道A里面是什么，有什么，做什么！很显然，我们想factory的override map里面注册的东西过于饱含信息量了！叫好比说，我在你家看到你的电视机我很喜欢，我也想去买一个，我其实只想让你告诉[注册]我电视机的型号[类型]，但是你却给我这个电视机[对象]让我抱着它去商场里比对这个实物电视去买！不错，我这样是能买到这个牌子的电视机，但是这样做是不是最好的办法呢，显然不是的。但是systemverilog有一个关键字叫做type，如果我声明以下一条语句：type a_type；那么我希望能够这样来操作这个a_type变量：if（a_type == int）......if（a_type == uvm_component）.....a_type = uvm_object; .......它就是type operator，也就是type操作符！我么可以使用诸如 var type(uvm_component)my_component这样的声明语句，也可以使用如下负责的判断语句：bit [12:0] A_bus, B_bus;parameter type bus_t = type(A_bus);case (type(bus_t))type(bit[12:0]): addfixed_int #(bus_t) (A_bus,B_bus);type(real): add_float #(type(A_bus)) (A_bus,B_bus);endcase那就是我们的facotyr中的lookup函数必然会有这样的结构所表达的含义：case（type（lookup key））type（cpu_bus_driver）: .......type（tcp_pkt）：.......type（A）：...............endcase注意，我指的是用这case语句结构表达的含义的本质，而不是说用case语句来表达！所以回到那两点问题上来，这两个问题的本质就是：（1）注册对象的全局性，换句话说有唯一性的需求；（2）信息的必要性，换句话说不要信息过量；所以，有一个最普通不过的方法来做就行了，怎么做呢？（1）tcp_pkt的“张三”对象你不希望我留着专用，那好，我给tcp_pkt变身一下，再定义一个新的类型叫做tcp_pkt_wrapper，而这个tcp_pkt_wrapper类型不会被任何的用户代码所用到，那么只要我生成一个tcp_pkt_wrapper的singleton不就行了，那么即不会影响用户使用tcp_pkt[你现在可以创建一个对象叫做“张三”等其它任何名字了]，也满足唯一性的要求了！（2）那么透过tcp_pkt_wrapper能不能也把信息不要过量也一并满足了呢？这个wrapper再合适不过了，为什么？因为sv可以定义参数化的类类型，我把这些tcp_pkt，cpu_bus_driver，A等等作为模版参数传给tcp_pkt_wrapper，cpu_bus_driver_wrapper，A_wrapper.....岂不是很好！所以通过sv的type操作符，我们达到了不要信息过量的目的。整合上述两点，以tcp_pkt来说，我们只需要定义这样一个wrapper就达到目的了：class tcp_pkt_wrapper（type T=tcp_pkt）;.......实现singleton.............enclass3UVM/OVM中的factory机制上诉的描述已经基本上把一些本质的东西都提及了，太过细节的东西没有必要在分析下去了；那我们就结合UVM中的factory来看看UVM的factory是如何实现的。（1）任何user defined 的class都是从uvm_object来（2）定义公共的wrapper类，uvm_obect_wrapper，此类的存在是为了提供一个基类，以便作为factoryoverride map的lookup key和 lookup value；根本原因是因为每个参数化类都是一个不同的类型，如果没有一个公共基类，则无法用一个统一类型的句柄来作为override map的lookup key。（3）在（2）的基础上定了模版类 uvm_component_registry和uvm_object_registry，模版参数就是user defined的类。（4）每一个uvm_component_registry#（T）或uvm_object_registry#（T）都会有一个singleton用来作为user definded类型T的轻量级代理和factory的注册。（5）factory有多种override map，用来进行不同override方式的支持，如override by name、override by type、override inst、override type等。（6）当我们使用uvm_object_utils/uvm_component_utils的时候，这些宏的重要作用之一就是利用上述机制像uvm_factory中注册，定义变量type_id，定义函数get_type（）等。看到这里，我最想说的是上述这些就是我对uvm class reference文档里下面这段话的理解，原文是：”the uvm_object_wrapper provides an abstract interface for creating object and component proxies. Instances of these lightweight proxies, representing every uvm_object-based and uvm_component-based object available in the test environment, are requested with the uvm_factory. When the factory is called upon to create and object or component, it finds and delegates the request to the appropriate proxy.“ 引自：asic_wangUVM/OVM中的factory---------个人总结
1.factory的需求来源 我们的测试平台一般都是通过component来组织成一个层次化的树形结构的，测试平台做什么事情取决于各个包含在其中的函数或者任务。总有一些时候，我们希望改变现有的处理机制或者流程。举例来说，我有一个通用的CPU总线的测试平台，在上层看来（软件同事们），这个东西对他们开放的接口就是两个：read（address，length），write（address，data），他们不管下面是PCIe还是RapidIO。假设目前的底层接口形式是PCIe总线，也就是说这个CPU agent中的的driver是一个PCIe的driver；有一天CPU换了，底层接口形式也跟着换成了RapidIO总线，那之前的CPU总线的测试平台能不能除了换个RapidIO的driver，其它不变？如果测试平台做的够好，应该是这个结果。但是怎么个换法？（1）把cpu agent.sv找到，改代码,至少有一个地方需要如下改改pcie_driver drv； ---》 rapidio_driver drv;（2）其他更好的方法？测试平台不用动，只需要在testcase中说明我现在希望用RapidIO driver来替换PCIe的driver。我们当然喜欢第二种。当然如果你的cpu env是一次性的，第一种方法也不错，如果是那样的话就与UVM思想相违背了，也会挨你继任同事的骂。如果你的cpu env将会作为另一个更大level的一个agent组件，情况就变得有点糟糕了；如果你的cpu env将会例化很多个，用在一个更大level的环境里，情况就变得更糟糕了；如果你的pcie driver被作为一个component单独用在一个大环境的很多地方，且分布于树形结构的不同深度的话，那方法（1）简直是噩梦！再假如，目前我有一个环境，有10个pcie driver，其中5个作为sub component用在5个cpu agent里面，另外5个pcie driver单独作为sub component用在top env（前面的5个cpu agent包含于top env中）里面。我现在想吧cpu agent里面的3个pcie driver换成rapidio driver，剩下的2个保持pcie driver不变；top level里面的5个pcie driver也有相似的需求，如果是用方法（1）改代码，那你的测试平台将会很糟糕，不具有任何可扩展性，容易出错等等.......不同的需求回很多，因为需求永远是在变化的，我们需要一种方法来很好的适应这种变化，factory机制就可以做到。2.我心目中的UVM factory的演进2.1 使用继承来解决2.1.1 前提：（1）有一个基类叫做cpu_bus_driver，所以的cpu总线的driver都从这个base class继承（2）cpu_bus_driver中定义一系列的总线操作，而且这写总线操作对它的任何继承者来说都是充分的：get_transfer（）：得到此次cpu操作类型（read or write），地址，长度，写数据drive_bus（）：把读写操作转化成最后的signal level的信号get_response（）：返回读数据或者写是否成功的响应（如果需要的话）当然这些函数都是virtual的。（3）cpu_bus_agent中这样实例化了driverclass cpu_bus_agent ;.......cpu_bus_driver driver ;function build();. .......driver = new("driver");. ........endfunction（4）测试平台的层次结构是：cpu_env.cpu_agent.cpu_drivercpu_env在cpu_base_test中实例化。2.1.2 方法step1：定义新类：new_cpu_bus_driverclass new_cpu_bus_driver extends cpu_bus_driver ;........定义自己的get_tranfer, drive_bus, get_response函数endclassstep2：替换原有的类。因为不能修改cpu_env及其一下各层次的代码，所以只能在testcase中进行替换：class cpu_test1 extends cpu_base_test ;new_cpu_bus_driver new_driver ;......new_driver = new("new_driver");cpu_env.cpu_agent.cpu_driver = new_driver ;.......endclass2.1.3效果没有修改任何cpu env及其一下层次的代码。2.1.4问题（1）上面标示的蓝色粗体为关键代码，但是这个语句的执行时间点需要精确把控。如果太早，则在运行cpu_agent.build()之后cpu_agent中的driver又会被重置为cpu_bus_driver而不是new_cpu_bus_driver；如果太晚，则可能cpu agent可能已经用cpu_bus_driver运行了一段时间了，然后才会切换成new_cpu_bus_driver，这样回导致前面的错误操作。最佳时间点显然是在所有的build phase之后，任何connection phase之前。（2）开发testcase的人需要准确的知道cpu env的层次结构，也就是说需要知道xxx.xxx.xxx.xxx形式，很显然这是个缺点；（3）如果有100个cpu driver需要替换，那么就需要100次cpu_env0.xxx.xxx.old_driver = new_driver ;....cpu_env99.xxx.xxx.old_driver = new_driver ;如果你觉得这个也不是问题，因为层次结构很规整嘛；那还有更麻烦的：old_driver被单独用到了一些地方而不是只用在了cpu agent里面，比如A_env.xxx.xxx.old_driver，B_env.xxx.old_driver，C_env.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.xxx.old_driver......那你准备怎么办？而且这种情况下缺点（2）的影响会更恶劣!2.2 第一次改进使用查找表来记录每个对象是否需要被替换。2.2.1 缺点的本质：（1）需要准确的时间点的本质原因是testcase不知道driver时候被创建的确切时间！所以需要找个最保险的时间点，那就是在所有的组件都创建之后，但是又不能早于connection phase，幸好uvm提供了各个phase的管理，否则这个问题解决起来就特别棘手！我们选择的时间点过于保守了，最合适的时间点就是在需要被创建的时候就做替换！也就是说每个对象的new函数调用处就是最佳的替换时间点。（2）需要知道层次结构的本质是在testcase层次以下没有任何东西来记录每个对象的路径!如果有这么一个地方，它记录了所有存在于环境中的对象的路劲，那么我只需要对它说，把你的记录里面每个driver对象都换成new driver。我只想对这个记录中心提供如下信息：1）我需要替换所有的driver，无论它分布于何处，它的层次路劲如何2）把driver替换成new driver.其余的交给记录中心来完成，我不想知道怎么做。2.2.2 缺点的改进（1）怎么样才能在每个对象new的时候就能够做替换呢？首先，我们需要知道的一条重要的限制就是new函数返回的对象永远都是它声明的类类型的对象！也就是说 ：A a_obj ；=》任何时候我们调用a_obj = new；返回的对象永远是A类类型的，不可能是其他类，连A的继承类也不可能！就是注意点彻底的告诉我们，需要一种方法（假设叫create方法）来代替new函数，当我调用它的时候，它不是100%返回A类型，而是视情况而定，什么情况？那就是：当我不像替换A的时候它返回A类类型的对象；当我想用A的派生类A1替换A的时候它能返回A1类类型的对象；当我想用A的派生类A2替换A的时候它能返回A2类类型的对象..........我们不应该在这里用new，而是用create！（2）很明显，我们需要数据库来记录每个对象的基本信息第一个数据库的每个条目可能如下：层次路径 对象类型“a.b.c.obj1” A“a.b.obj2”B“a.b.obj3”A第二个数据库的每个条目可能如下：原对象的类型 希望被替换成的类型AA1BB2CC(也就是不替换)这种数据结构用关联数据再合适不过！2.2.3 实现对于缺点1的改进，按照我们的分析，应该做如下改变：a) 在cpu agent中创建driver的时候不用new函数，用另外一个叫做create的函数，用这个函数取代new函数。问题来了，这个create函数应该放在哪里？具有神马性质？首先，这个create函数可以放在cpu driver类及其子类中；或者外面。我们假设放在cpu driver类及其子类中。其次，既然能够取代new函数，那么必须不能针对于某一个具体对象，不然不能够调用；所以create应该是静态的。再则，我们的主要目的是需要这个函数视是否需要被替换的情况而来产生出对应的对象。达到这个目的可有很多种方法，最直观的一种是：在create之前我去中心数据库查一下先，如上述的第二个数据库，如果目前查到这样一条条目：/“原对象类型 cpu_bus_driver”，"需要替换"，“替换成的对象类型 new_cpu_driver”/,那么我就可以知道虽然实在调用cpu_bus_driver的create函数，但是实际上是想让我生成cpu_bus_driver的继承类new_cpu_bus_driver！对应缺点2的改进需求，我们可以建立一个数据库中心，取名叫做factory，它的核心内容就是若干个map，每个map中的条目都是为create函数来服务的。好了，基于上述的分析，我们写出如下的伪代码：class cpu_bus_driver ;.......virtual function cpu_bus_driver create_object();cpu_bus_driver me ;me = new ;return me ;endfunctionstatic virtual function cpu_bus_driver create();cpu_bus_driverkey;key = new ;new_driver = factory.create_object(factory.lookup(key));return new_driver ；endfunctionendclassclass new_cpu_bus_driver extends cpu_bus_driver;.......virtual function cpu_bus_driver create_object();new_cpu_bus_driver me ;me = new ;return me ;endfunctionstatic virtual function cpu_bus_driver create();new_cpu_bus_driverkey;key = new ;用key作为键字去factory的数据库中查出替换条目，得知想不需要替换factory利用查得的结果，生成一个new_cpu_driver对象给我，叫做 new_driverreturn new_driver ；endfunctionendclassclass factory ；cpu_bus_driver override_map [cpu_bus_driver] ;function cpu_bus_driver lookup(cpu_bus_driver key);return overrride_map[key];endfunctionfunction cpu_bus_driver create_object(cpu_bus_driver override_obj);return override_obj.create_object();endfunctionendclass好了，举例来说明一下具体的工作过程：a）声明一个 cpu_bus_driverdriver；b）调用 driver = cpu_bus_driver::create();b1）key = new ；////key是cpu_bus_driver类的b2）factory.lookup（key）；////返回一个new_cpu_bus_driver信息b3）factory.create_oject(new_cpu_bus_driver);b4）调用new_cpu_bus_driver::create（）；b5）new_cpu_bus_driver::create()调用new_cpu_bus_driver的new函数生成一个new_cpu_bus_drive类型的对象赋给driver经过上诉调用后driver就不是它声明是的cpu_bus_driver类型的一个对象了，而是一个地地道道的new_cpu_bus_drive类型的对象了，唯一一点的遗憾就是这个对象是用父类的句柄hold住的。2.3 第二次改进细心的朋友可能已经注意到上述实现的一个问题就是，factory的override map的键字是一个cpu_bus_driver的对象，而我的cpu_bus_driver类型的对象可能很多，举例来说如果override map中的cpu_bus_driver键字是一个叫做 “张三”的，很明显，如果我随意创建一个新的cpu_bus_driver类型的对象“李四”，虽然他们都是cpu_bus_driver类型的，但是用“李四”去查factory的override map时，就会查不到任何条目！这个就是2.2的实现中的一个问题！如何改进？很自然我们想到一种解决方案:用一个全局的众所周知的cpu_bus_driver对象去做键字。这个对象是给factory的override map专用的，不做他用，假设“张三”就是这样一个对象。这样一来问题就解决了，任何时候只要是想查询cpu_bus_driver类型的override条目，我只需要用 factory.override_map[“张三”]来查询即可！这个解决方案看起来好多了，也解决问题了，但是记得有一个前提就是：记得在进行任何查找override map[“张三”]之前，确保这个条目已经存在！看到这里，大家可能已经马上就想到了UVM中的factory register，没错！就是要向factory中注册！注册越早越好！2.4 第三次改进在第二次改进中，我们提议用一个众所周知的全局对象来向factory注册，然后用这个注册的全局对象来作为override map的查询的key来得出是否需要替换成别的子类的结论。这没有任何问题，但是不优美！原因有如下几点：（1）比如我有一个类叫做tcp_pkt，我希望我可以创建一个叫任何名字的tcp_pkt的对象，而不是叫“张三”的名字我不能取，因为这个“张三”被factory专用！在一个大型的环境中，会有很多个用户定义的类类型，比如除了tcp_pkt，还有ip_pkt，udp_pkt，还有其它方面的如ethernet_driver，ethernet_monitor.........假设设计中有100个类类型，那我岂不是要记着100个“张三”，“王三”，“李三”.......这些factory专用对象！（2）性能和效率太差！为什么这么说呢？如果我定义的类很复杂，那么这对象势必需要专用很大的内存，而每个类都需要一个factory专用对象，这些对象一直存在着[因为在override map随时都有可能需要lookup]，所以内存不释放！既然问题分析了，那就要找出对策了！问题在哪里？想一个问题：factory的override map里需要的最根本的信息是什么？没错，那就是类型而非一个具体对象！factory只想知道也只需要知道在我的override map里面有一个条目的含义是类型A需要不需要替换成A的子类，如果有，是A1还是A2还是其它.....我不像知道A里面是什么，有什么，做什么！很显然，我们想factory的override map里面注册的东西过于饱含信息量了！叫好比说，我在你家看到你的电视机我很喜欢，我也想去买一个，我其实只想让你告诉[注册]我电视机的型号[类型]，但是你却给我这个电视机[对象]让我抱着它去商场里比对这个实物电视去买！不错，我这样是能买到这个牌子的电视机，但是这样做是不是最好的办法呢，显然不是的。但是systemverilog有一个关键字叫做type，如果我声明以下一条语句：type a_type；那么我希望能够这样来操作这个a_type变量：if（a_type == int）......if（a_type == uvm_component）.....a_type = uvm_object; .......它就是type operator，也就是type操作符！我么可以使用诸如 var type(uvm_component)my_component这样的声明语句，也可以使用如下负责的判断语句：bit [12:0] A_bus, B_bus;parameter type bus_t = type(A_bus);case (type(bus_t))type(bit[12:0]): addfixed_int #(bus_t) (A_bus,B_bus);type(real): add_float #(type(A_bus)) (A_bus,B_bus);endcase那就是我们的facotyr中的lookup函数必然会有这样的结构所表达的含义：case（type（lookup key））type（cpu_bus_driver）: .......type（tcp_pkt）：.......type（A）：...............endcase注意，我指的是用这case语句结构表达的含义的本质，而不是说用case语句来表达！所以回到那两点问题上来，这两个问题的本质就是：（1）注册对象的全局性，换句话说有唯一性的需求；（2）信息的必要性，换句话说不要信息过量；所以，有一个最普通不过的方法来做就行了，怎么做呢？（1）tcp_pkt的“张三”对象你不希望我留着专用，那好，我给tcp_pkt变身一下，再定义一个新的类型叫做tcp_pkt_wrapper，而这个tcp_pkt_wrapper类型不会被任何的用户代码所用到，那么只要我生成一个tcp_pkt_wrapper的singleton不就行了，那么即不会影响用户使用tcp_pkt[你现在可以创建一个对象叫做“张三”等其它任何名字了]，也满足唯一性的要求了！（2）那么透过tcp_pkt_wrapper能不能也把信息不要过量也一并满足了呢？这个wrapper再合适不过了，为什么？因为sv可以定义参数化的类类型，我把这些tcp_pkt，cpu_bus_driver，A等等作为模版参数传给tcp_pkt_wrapper，cpu_bus_driver_wrapper，A_wrapper.....岂不是很好！所以通过sv的type操作符，我们达到了不要信息过量的目的。整合上述两点，以tcp_pkt来说，我们只需要定义这样一个wrapper就达到目的了：class tcp_pkt_wrapper（type T=tcp_pkt）;.......实现singleton.............enclass3UVM/OVM中的factory机制上诉的描述已经基本上把一些本质的东西都提及了，太过细节的东西没有必要在分析下去了；那我们就结合UVM中的factory来看看UVM的factory是如何实现的。（1）任何user defined 的class都是从uvm_object来（2）定义公共的wrapper类，uvm_obect_wrapper，此类的存在是为了提供一个基类，以便作为factoryoverride map的lookup key和 lookup value；根本原因是因为每个参数化类都是一个不同的类型，如果没有一个公共基类，则无法用一个统一类型的句柄来作为override map的lookup key。（3）在（2）的基础上定了模版类 uvm_component_registry和uvm_object_registry，模版参数就是user defined的类。（4）每一个uvm_component_registry#（T）或uvm_object_registry#（T）都会有一个singleton用来作为user definded类型T的轻量级代理和factory的注册。（5）factory有多种override map，用来进行不同override方式的支持，如override by name、override by type、override inst、override type等。（6）当我们使用uvm_object_utils/uvm_component_utils的时候，这些宏的重要作用之一就是利用上述机制像uvm_factory中注册，定义变量type_id，定义函数get_type（）等。看到这里，我最想说的是上述这些就是我对uvm class reference文档里下面这段话的理解，原文是：”the uvm_object_wrapper provides an abstract interface for creating object and component proxies. Instances of these lightweight proxies, representing every uvm_object-based and uvm_component-based object available in the test environment, are requested with the uvm_factory. When the factory is called upon to create and object or component, it finds and delegates the request to the appropriate proxy.“ 引自：asic_wangUVM/OVM中的factory---------个人总结
Aurora ，Rapidio和GTP是什么关系
Aurora ，Rapidio是协议，gtp是物理层
Aurora 和Rapidio是一个概念吗
另外Rocketio和gtp是一个概念吗
Aurora 和Rapidio是一个概念吗
另外Rocketio和gtp是一个概念吗
rapidio 接口fpga有哪些
一、Mobiveil RapidIO 2.2核仿真操作说明 3 二、基于Xilinx GTX的RapidIO可综合wrapper设计说明 4三、上板调试步骤 43.1 chipsocpe观察RapidIO Outbound和 Inbound接口数据 53.2 SoC系统调试操作说明 5一、Mobiveil RapidIO 2.2仿真操作说明Mobiveil RapidIO源代码需要对其仿真环境进行设置才能完成仿真过程，原因是Mobivieil RapidIO测试激励system verilog代码只能在32位操作系统中运行，且有些操作系统缺少相应仿真运行环境库。具体仿真修改操作如下：1. 建立64位操作系统镜像，选择rhel-server-6.3-x86_64-dvd.iso为操作系统安装所用操作系统镜像。在现有的操作系统下键入以下命令进行操作系统光盘挂载：mount -o loop ~ver7/rhel-server-6.3-x86_64-dvd.iso /home/RHEL6.3/2. 在系统etc/yum/repos.d/目录下建立文件名为rhel6-3.repo的文件，文件内键入以下内容：#[rhel-source]#name=Red Hat Enterprise Linux $releasever - $basearch - Source[6.3image]Name=Red Hat Enterprise Linux 6.3Baseurl=file:///home/RHEL6.3Enable=1gpgcheck=03. 使用如下命令查看VCS和DVE软件缺少的库文件：ldd /export/COREDATA/eda_tools/synopsys/tool_collection/VCS_MX/2011.12/linux/bin/vcs1ldd /export/COREDATA/eda_tools/synopsys/tool_collection/VCS_MX/2011.12/gui/dve/linux/bin/dve.exe4. 在.bashrc中设置库搜索的路径，键入以下RapidIO，VCS，verdi库路径:exportLD_LIBRARY_PATH= $NOVAS_HOME/share/PLI/VCS/LINUX:$RAPIDIO_SO:/export/COREDATA/ eda_tools/synopsys/tool_collection/VCS_MX/2011.12/linux/lib :/export/COREDATA/eda_tools/Novas/novas-201210p3/share/FsdbWriter/LINUXAMD64:5. 搜索缺少的库，键入如下命令：Yum search “X11”。其中X11为需要安装的库名称。6. 安装缺少的库，一般32位库为有i868的标志，安装后能自动解决库的关联问题，例如键入以下命令进行库安装：Yum install libX11.i686 libX11-common.noarch libX11-devel.i6867. 部分.so库操作系统不带有该安装包，需要单独下载安装，安装路径为/home/RHEL6.3/Packages/，比如：Rpm -i /home/RHEL6.3/Packages、 安装完成后，进入rapidIO/dv/rundir文件夹下运行./RUN命令进行仿真，各个仿真功能点命令放在rapidIO/dv/config文件夹下，仿真结果。
本文由 在线网速测试 整理编辑，转载请注明出处。
