用于流送数据剖析的方法和装置
技术领域
本发明涉及一种具有多个功能单元的电路布置,其中功能单元的每一个包括多个数据处理模块和一个本地控制器,所述多个数据处理模块运行共用系统时钟,并与运行握手式流送数据传输协议的流送数据总线进行连接。本发明还涉及一种用于剖析(profiling)在这样的电路布置中使用的流送数据的数据流的方法。
背景技术
在构建大型片上系统(SoC)诸如用于在移动通信应用中使用时,设计者将经由适当定义好的总线接口来组合若干IP模块,IP模块也被称为IP(知识产权)核,这些IP模块甚至可能来自不同的厂商。
复杂的SoC在与多个嵌入式控制器通信的同时,互相之间以及与其他硬件设备(例如,数据处理模块)之间也在通信,这在优化系统性能时提出了挑战,发现了瓶颈和更多的实时调试的问题。
握手式总线协议被认为是一种用于在SoC的一个组件中的数据处理模块之间以及不同组件的数据处理模块之间流送数据的简单直接的手段。然而,基于握手式总线协议互连的系统可能仍表现出复杂和意外的行为。即使表面上数据已经处理,系统性可能仍然较差,因为模块基于它们的处理速度和它们的互相依赖性而互相拖延。尽管所有模块都按照它们各自的规范工作,系统甚至仍会陷入死锁的局面。这些死锁和不太致命的瓶颈尤其难以调试,因为由于资源限制(时间和测试方面),通常无法通过模拟来抓住这些问题。
在图1和图2中说明了复杂的相互依赖性的一些例子。
参考图1,列举了SoC组件的一个数据处理模块有时经由几个中继如何能够影响另一数据处理模块的几种情况。在图1中,流送协议结构用粗箭头表示,控制路径用细箭头表示。图1中的示例性组件包括六个数据处理模块11A-11F和一个本地控制器12。数据处理模块A以对齐方式向数据处理模块B和C两者提供数据。数据处理模块C以对齐方式处理来自处理模块A、E和F的数据。如从图中将理解的,在模块B中的延时(即,时延)可以拖延模块A,因为A不能发送数据至B。模块A中的延时可以拖延模块E和F,因为模块C以对齐方式处理来自A、E和F的数据。模块B中的延时可以拖延模块C,因为模块A同时发送数据至B和C。在模块A、B、D,然后返回至模块A当中出现环依赖的情况下,甚至存在死锁情况的可能性。因此,如果沿着该路线没有足够的FIFO容量,则在一个模块中的延时将使整个环路终止,并且,由于之前提到的情况,组件的所有其他模块也会如此。
上面所述的情况是否将发生首先取决于单独模块固有的处理和通信模式,并且其次取决于程序和组件控制器的启动顺序。
图2举例说明了组件间的依赖性,组件间的依赖性图示了如上所述的类似的延时情况也可能在跨越组件边界发生。图2示出了由第一本地控制器22控制的第一SoC组件20,且第一SoC组件20包括两个数据处理模块21A和21B;以及由第二本地控制器32控制的第二SoC组件30,且第二SoC组件包括两个数据处理模块31C和31D。在图2中,组件内流送数据路径由虚线的粗箭头表示,跨组件边界的流送数据路径由实线的粗箭头表示,控制路径由细箭头表示。如从图2中将理解的,例如,在D中的延时可以拖延C,因为A正在发送对齐数据至C和D。然而,因为包括了两个独立的组件控制器,所以这样的瓶颈甚至更难检测和避免。
已知有各种方法来应对一般的实时调试和剖析的问题。这些方法包括例如调试总线、测试嵌入式控制器运行的代码、经由调试端口观察内部状态的装置、可选地连接到外部逻辑分析仪。
然而,尤其是当涉及到系统提升的剖析时,这些已知的方法也会带来相当大的弊端。当使用调试端口和/或外部逻辑分析仪时,问题出在引脚有限的SoC上,也会出在现场可编程门阵列(FPGA)原型上,因为通常没有足够多的引脚来适应这个任务。用内部跟踪存储器的问题在于,片上存储器是一种稀缺和昂贵的资源,尤其是在ASIC上,并且将它仅用于剖析可能通常是不合理的。将功能性存储区重分配给剖析是一个潜在的解决方案,但是,可能没有足够的内部可用存储区,或者这种方法可能会干扰正常运作。
嵌入式控制器运行诊断代码通常在代码和数据存储器中只需要占用很少的额外消耗。然而,它可能会产生误导,因为运行的代码改变了实际系统的定时/行为,所以获得的剖析将价值不大甚至是错误的。
因而,在本领域中需要的是一种简单且低消耗的方法,用来评估大型SoC上的组件内和组件间链路性能和通信模式。
发明内容
根据本发明的第一方面,提供了一种包括多个组件或者功能单元的电路布置,多个组件或功能单元的每一个包括多个数据处理模块和一个本地控制器,数据处理模块运行共用系统时钟并与运行包括三个控制信号的握手式流送数据传输协议的流送数据总线进行连接。这些是第一和第二握手式控制信号,俗称有效信号和接受信号;以及第三控制信号,第三控制信号标记由在数据流中的数据元素的逻辑组组成的帧的开始和结束。根据本发明,至少一个功能单元包括剖析模块,该剖析模块接收在实时操作期间的流送数据总线的预定义链路处抽头的第一、第二和第三控制信号的至少一个集合,用于确定出于剖析和调试目的流送数据流的链路性能和通信模式。剖析模块可由功能单元的本地控制器来配置,或者由通过总线系统与剖析模块相耦合的电路布置的其他任何高级别的控制器来配置。剖析模块可以包括和各自的剖析器单元连接的多个链路选择装置,用于同时确定流送数据总线的多个链路的链路性能。每个剖析器单元适于接收系统时钟信号和流送数据协议的三个控制信号,这三个控制信号从选定的链路抽头,以由此来提取链路性能参数。剖析模块进一步包括控制寄存器的软件可访问集合,用于定义要评估的链路、链路性能获取模式、和要评估的控制信号的时间段,以及用于存储来自剖析器单元的链路性能输出参数。
根据本发明的一个实施例,剖析器单元包括用于确定自从上个清除操作后通过的帧的数目的第一计数器,用于确定采样帧的持续时间的第二计数器,用于确定采样帧的数据节拍的数目的第三计数器,以及用于控制用于要被采样的选定帧的第一、第二和第三计数器的计数器控制逻辑。
根据本发明的目前优选的实施例,剖析器单元进一步包括连接至第一计数器的输出的第一寄存器,连接在第二计数器的输出和第二寄存器之间的第一比较器,和连接在第三计数器的输出和第三寄存器之间的第二比较器,计数器控制逻辑适于根据选定的获取模式配置计数器、比较器和寄存器以用于要被采样的选定帧。
目前的流送数据剖析器单元只需要非常少的硬件资源,还可以在很大程度上支持剖析和调试。即使它不是直接针对一个问题,它仍然会引导调试和剖析问题的原因的更多常规手段。
根据另一方面,本发明提供了剖析用于上面所述的电路布置的流送数据的数据流的方法,该方法包括提供来自所述数据处理模块的任一对之间的所述流送数据总线的多个链路的抽头线;选择要评估的链路;选择链路性能获取模式;从要评估的选定链路抽头所述第一、第二和第三控制信号;以及确定来自所述第一、第二和第三控制信号的链路性能参数集合和用于控制信号的预定时间段的所述共用系统时钟。
在基于传输的操作模式中,确定链路性能参数集合的步骤包括计数自从上个清除操作后通过的帧的数目;计数采样帧的时钟滴答(clockticks)的数目,即,确定帧的持续时间;以及计数采样帧的数据节拍的数目。因此,性能参数的数目可以由这几项确定:例如由剖析器模块外部的某个事件触发的两个清除操作之间的帧的数目;在这个清除时段期间的第一个、最后一个、或者第N个帧的持续时间;最短或最长的帧的持续时间及其在该组帧中的索引;这些帧的任何一个中的实际数据传输的数目;具有最小或最大数目的数据传输的帧及其索引。
这些参数可以有助于找到瓶颈情况,其中延时导致差的持续时间与传输比率。这些参数也可用于找出能指示传输错误的丢失帧和/或具有多余数据的帧的帧。
在基于控制的操作模式中,确定链路性能参数集合的步骤包括通过关注流送数据协议的握手信号来确定传输的粒度更精细的情景。对于选定帧,可以确定下面的参数:宣称的(asserted)采样的有效信号的最小和最大持续时间;撤销的(de-asserted)采样的有效信号的最小和最大持续时间;宣称的采样的接受信号的最小和最大持续时间;撤销的采样的接受信号的最小和最大持续时间;最小或最大的帧间隙和该间隙之前的帧的帧索引。
这些参数可以有助于了解为何帧持续时间/数据传输比率并不如预期的那样。
尤其是对于具有多个流送数据端口的模块,根据本发明的具有流送数据剖析器的所有模块的设备可以示出总线抖动(thrashing)的原因。
附图说明
根据仅通过例子的方式给出的并且其中将参考附图的下面的特定实施例的详细描述,本发明的附加特征和优点将显而易见,在附图中:
图1示出了数据流的组件内依赖性;
图2示出了数据流的组件间的依赖性;
图3示出了在根据本发明的电路布置的实施例中使用的握手式流送数据协议;以及
图4示出了根据本发明的流送数据剖析器单元的框图;
图5示出了包括根据本发明的剖析器模块的电路布置的功能单元的框图;以及
图6示出了包括如图4中所示的四个剖析器单元的剖析器模块的一个实施例的框图。
具体实施方式
现在将参考图3中示出的以及在申请人的共同申请的欧洲专利申请“MethodforHighSpeedDataTransfer(高速数据传输方法)”(EP10197315.4)中描述的示例性握手式数据流送传输协议来详细描述本发明。图3的协议可以用于通过组件流送数据和SoC的若干组件之间流送数据,诸如图1、2和5中图示的组件11A-F和21A、B、31C、D。
举个例子,在用于无线通信应用的SoC的情况下,这些组件或功能单元是系统的各个构成块,例如数字前端(DFE)、Tx单元、共享RAM、前向纠错(FEC)数据单元、快速傅立叶变换(FFT)单元、参数估计单元、均衡器单元、搜索器单元、FEC控制单元等,这些中的每一个包括若干数据处理单元和一个本地嵌入式控制器。
协议包括三个二进制信号,这三个二进制信号包括用于在数据源和数据信宿之间握手的有效和接受信号,以及标记在数据流内的数据元素的逻辑组的开始和结束的帧信号。数据流的起源被称为“源”,目的端被称为“信宿(sink)”。在这里,数据源和数据信宿可以是SoC的任何组件或组件级别上的任何数据处理模块。有效/接受信号类似于来自其他握手式传输协议的信号,并用于驱动和拖延从源到信宿的通信。源和信宿可以在任何时间设置或重置这些信号。如果时钟的上升沿都为“高”,数据被采用。数据源和数据信宿必须对帧信号意味着什么具有相同的理解。所图示的传输协议的“帧”的含义是逻辑组或数据序列,例如OFDM符号,控制数据块,信息数据块,等等。仅当接受信号、有效信号和帧信号为高时,数据传输才会发生。帧信号标记了数据块传输的开始和结束。
然而,必须理解的是,本发明不仅限于这种特定的流送数据传输协议,而可以一般地与任何类似的握手式总线协议一起使用。
图4示出了根据本发明的流送数据剖析器单元40的框图。流送数据剖析器单元40是低于模块级别的构成块。为了明确地指示数据流而不干扰实际通信,其接收系统时钟信号和从流送数据总线的选定链路抽头的控制信号集合,以由此提取链路性能参数。
流送数据剖析器单元40不包括自己的控制寄存器集合,相反,它意指是控制流送数据剖析器单元40并且可能选择特定的流送数据流来剖析的模块的一部分。这可以是在图6中详细图示的整个功能单元的背景下诸如图5中所述的剖析模块51。剖析模块51也可以是功能单元的MISC模块的一部分。
如在图5和图6中所示,多个剖析器单元可以分组到剖析模块51中,并且可由软件可访问的控制寄存器集合511控制,控制寄存器组511进而由诸如图5的控制器12的功能单元的本地控制器进行控制。
图6示出了剖析模块51的示例性实施例,其包括四个剖析器单元40A-D,用于同时确定来自流送数据总线的四个不同接口的数据流性能参数。剖析器单元40A-D中的每一个耦合至作为复用器示出的相应的链路选择装置510A-D。控制寄存器511控制复用器510A-D中的每一个复用器来选择流送数据总线的链路以及通过从针对用于评估链路性能参数的其关联的剖析器单元的链路抽头的控制信号。由剖析器单元40A-D获取的输出参数被存储在控制寄存器511内,以由合适的软件实时或稍后读出。
返回图4,流送数据剖析器单元40通常收集关于链路性能和通信模式的剖析数据,诸如帧持续时间(第一、最后、最小、最大);帧内的数据传输(最小,最大);连续数据循环和/或帧内的死循环的数目。
如在图4中所示,剖析器单元40基本上由三个计数器42、43、44以及对应的存储寄存器47、48、49组成,三个计数器42、43、44由计数器控制逻辑41控制。计数器控制逻辑41包括公知的布尔逻辑门,且由相应的控制输入来控制。
基于握手式流送数据协议的定义,仅当全部宣称了有效信号、帧信号和接受信号时,才传输数据。该条件用于控制确定每帧的数据节拍的数目的活动计数器44。持续时间计数器43并行将每个帧的持续时间确定为系统时钟流逝的数目。帧计数器42确定自从上个清除操作后通过的帧的数目。图4中的字母f、d和a分别表示帧、持续时间和活动计数器的比特宽度。比较器45连接在持续时间计数器43和其关联的寄存器48之间,并且比较器46连接在活动计数器44和其关联的寄存器49之间,根据选定的获取模式控制这两个比较器,以使得关联的寄存器分别收集当前测量参数的最大或最小值。示例性获取模式将在下表4中列出。
流送数据剖析器使用如下表中所示的三个参数:
表1:流送数据剖析器单元的参数
参数 |
描述 |
frm_num_cnt_width_f |
帧计数器宽度 |
dur_cnt_width_d |
持续时间计数器宽度 |
act_cnt_width_a |
活动计数器宽度 |
如前所述,流送数据剖析器单元40没有自己的控制寄存器,而是受控于多个输入。可以在采用图3的流送数据协议的本发明的流送数据剖析器单元的示例性实施例中使用的非限制性的输入的列表如下:
图2:流送数据剖析器单元的输入信号
信号 |
描述 |
clk |
模块时钟 |
rst_an |
重置,异步,低活动性 |
rst |
重置,同步,到clk,高活动性 |
mode_in |
更新模式 |
smpl_idx_in |
采样索引选择 |
clr_cnt_in |
清除计数器 |
frame_in |
帧信号 |
valid_in |
有效信号 |
accept_in |
接受信号 |
有两种主要测量形式:基于传输的和基于控制的。在基于传输的形式中,所获得的值对应于如由流送数据协议定义的成功的数据传输。在基于控制的形式中,测量在粒度上更精细并且对应于特定帧的单独控制信号。测量值经由分别与相应计数器和锁存寄存器相对应的三个输出来提供。根据测量形式,值具有不同的含义,如下表所给出的:
表3:根据操作模式的输出涵义
下表列出了可以支持的示例性获取模式。模式0x1…0x7属于基于传输的测量形式;模式0x8…0xD属于基于控制的测量形式。
图4:获取模式
模式 |
助记符号 |
描述 |
0x0 |
NOP |
没有操作;剖析器40不活动,计数器42至44没有更新,仍旧坚持原来的数值 |
0x1 |
FRM_1ST |
计数器42至44包括来自第一帧的值 |
0x2 |
FRM_LAST |
计数器42至44包括来自最后一帧的值 |
0x3 |
FRM_NTH |
计数器42至44包括来自具有输入smpl_ind_in选定的索引的帧的值 |
0x4 |
FRM_MINDUR |
计数器42至44包括来自具有最小持续时间的帧的值 |
0x5 |
FRM_MINXFER |
计数器42至44包括来自具有最小的数据传输数目的帧的值 |
0x6 |
FRM_MAXDUR |
计数器42至44包括具有最大持续时间的帧的值 |
0x7 |
FRM_MAXXFER |
计数器42至44包括具有最大数据传输数目的帧的值 |
0x8 |
SEL_VAL |
对于由输入smpl_idx_in选定的帧,将宣称的采样valid_in的最大和最小的持续时间写入日志 |
0x9 |
SEL_NOVAL |
对于由输入smpl_idx_in选定的帧,将撤销的采样valid_in的最大和最小的持续时间写入日志 |
OxA |
SEL_ACC |
对于由输入smpl_idx_in选定的帧,将宣称的采样accept_in的最大和最小的持续时间写入日志 |
OxB |
SEL_NOACC |
对于由输入smpl_idx_in选定的帧,将撤销的采样accept_in的最大和最小的持续时间写入日志 |
OxC |
GAP_MINDUR |
持续时间计数器43示出了最小帧间隙;活动计数器44未使用;smpl_idx_out指的是间隙之前的帧 |
OxD |
GAP_MAXDUR |
持续时间计数器43示出了最大帧间隙;活动计数器44未使用;smpl_idx_out指的是间隙之前的帧 |
Oxe ... Oxf |
rsvd. |
保留以备后用 |
图4中示出的流送数据剖析器单元40是用于流送数据结构的设备的基本构成块。
以上描述的各种模式可以用于通用性能剖析并将有助于找到数据传输中的瓶颈。接下来,列出了一些示例性问题,以及在流送数据剖析器的帮助下如何回答这些问题:
数据传输是否是有效率的?
如果FRM_*模式中的一个的测量表明帧的持续时间等于传输的数目,或者如果差别仅仅很小,则没有延时发生。
帧是统一的吗?
如果在模式FRM_MINDUR和FRM_MAXDUR的情况下获得的帧持续时间值差别只有一点点,则这些帧每次迭代都以相同速度被发送/处理。
对于所有帧来说,数据载荷相同吗?
如果在模式FRM_MINDUR和FRM_MAXDUR的情况下获得的已传输帧的数目相同,则所有的帧承载相同数目的数据。
序列中的特定帧包含预期数目的数据吗?
使用FRM_NTH模式,并且应用帧索引到输入smpl_idx_in以获得讨论中的帧的值。
帧偏离平均传输模式吗?
当测量模式为FRM_MINDUR/FRM_MAXDUR或者为FRM_MINXFER/FRM_MAXXFER时,输出smpl_idx_out将该帧的索引显示为以比平均值长/短的持续时间或比平均值少/多的数据的形式突出。
如果传输被延时,则是一个大暂停还是很多小暂停?
如果在SEL_VAL或SEL_ACC模式中获得的最小/最大值相似(并且小于差值b/w帧持续时间以及之前获得的传输的数目),则存在很多小暂停,否则存在较少的但是较大的暂停。
传输延迟是由发送端还是接收端引起的?
如果在模式SEL_NOVAL中获得的最小和/或最大的持续时间大于在模式SEL_NOACC中获得的最小/最大的持续时间,则延时主要是由发送端引起,因为发送端较不经常提供新数据。否则,延时主要由接收端引起,因为接收端较不经常准备接受新数据。
各个帧是在其间以预期的间隔来传输的吗?
GAP_MIN和GAP_MAX模式可以用于获得帧间隙的最小和最大持续时间。
本发明的流送数据剖析器也可以通过检测非预期的通信模式来支持调试,以及因此引导更多指引性的调试手段。用于该功能的两个非限制性例子为:
存在具有丢失或者多余数据的帧吗?
如果在FRM_MINXFER或FRM_MAXXFER模式的情况下获得的传输数据的数目的值不如预期那样,则由输出smpl_idx_out指示的帧丢失和/或具有太多的数据。
特定的帧传输预期数目的数据吗?
可以使用FRM_NTH模式,并且帧索引可以应用于输入smpl_idx_in以获得讨论中的帧的值。