CN110445585A - 基于ppp数据帧组帧和解帧硬件加速器 - Google Patents
基于ppp数据帧组帧和解帧硬件加速器 Download PDFInfo
- Publication number
- CN110445585A CN110445585A CN201910743923.9A CN201910743923A CN110445585A CN 110445585 A CN110445585 A CN 110445585A CN 201910743923 A CN201910743923 A CN 201910743923A CN 110445585 A CN110445585 A CN 110445585A
- Authority
- CN
- China
- Prior art keywords
- data packet
- packet
- memory
- framing
- descriptor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0033—Systems modifying transmission characteristics according to link quality, e.g. power backoff arrangements specific to the transmitter
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0036—Systems modifying transmission characteristics according to link quality, e.g. power backoff arrangements specific to the receiver
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/26—Special purpose or proprietary protocols or architectures
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate
Abstract
本发明涉及网络通信领域,公开了一种基于PPP数据帧组帧和解帧硬件加速器。利用CPU把需要处理的数据包长度、数据包保存在内存中的首地址和通道号等信息组成接收描述符存储到加速器内部的存储器中,根据通道号来区分是组帧还是解帧。加速器通过内部的总线监视器监测到有新的数据包,就会根据描述符中的信息,从内存存储器DDR中将接收到的数据包搬运到其内部的存储器中,然后根据PPP数据帧的组帧和解帧规则,对数据包进行处理,把处理完成得到的数据包搬运到相应的内存DDR中的存储空间中。这样可以减少CPU资源的占用,降低功耗,同时可以提高运算速度,提升数据吞吐量。
Description
技术领域
本发明涉及网络通信领域,涉及一种基于PPP数据帧组帧和解帧硬件加速器。
背景技术
PPP(Point to Point Protocol,点对点协议)提供了一种在点对点的链路上封装多协议数据报(IP、IPX和AppleTalk)的标准方法。它不仅能支持IP地址的动态分布和管理,而且还支持多种配置参数选项的协商。所以在网络通信中会经常用到。
PPP协议的报文封装格式采用了HDLC(High-Level Data Link Control,高级数据链路控制)的定界帧格式,如图4所示是PPP数据帧格式。
图中的B,表示byte(字节),上方的数字表示该域包含的字节数。
每一个PPP数据帧都是以一个标志字节起始和结束的,该字节为0x7E。
地址域和控制域都是一个字节的常量值,分别为0xFF和0x03,这两个域是没有实际意义的。
协议域是用来区分信息域封装的协议类型,如IP(Internet Protocol)、LCP(LinkControl Protocol)、NCP(Network Control Protocol)等。信息域缺省时最大长度不能超过1500字节,包含了协议域中指定的协议数据报。校验域主要是对PPP数据帧传输的正确性进行检测。
在发送端组PPP数据帧时,当报文中的信息域出现了0x7E时,需要把0x7E转变为2个字节序列(0x7D 0x5E),如果出现了0x7D,则需要把0x7D转变为(0x7D 0x5D),如果信息域中出现ASCII码控制字符(即数值小于0x20的字符)时,需要在该字符前加入0x7D。在接收端接收到数据后要再进行与发送端字节填充相反的变换,才可以正确地恢复出原来的信息。
由此可见,在对PPP数据帧进行组帧和解帧时,是需要对信息域中的每个字节进行检查判断的。而当前对于PPP数据帧的组帧和解帧通常使用软件程序进行处理,需要占用大量CPU运算资源,CPU参与运算导致功耗上升;而且这种做法的数据吞吐量小,效率较低且速度较慢。因此,需要一种能够克服上述缺陷的PPP帧的编码和解码的硬件加速器。
发明内容
为了解决上述问题,本发明提供了一种基于PPP数据帧组帧和解帧硬件加速器,通过内部的总线监视器监测到数据包,根据描述符中的信息和PPP数据帧的组帧和解帧规则,对数据包进行处理,把处理完成得到的数据包搬运到相应的内存DDR 中,有效的减少CPU资源的占用,降低功耗,同时可以提高运算速度,提升数据吞吐量。
本发明提供如下技术方案:一种基于PPP数据帧组帧和解帧硬件加速器,包括了CPU、AXI Slave接口、接口、[h1] 存储器映射寄存器(MMR)、DMA引擎(DMA Engine)、包处理引擎(Packet Processing Engine)、内存(DDR)、描述符(Descriptor)存储器、总线监视器(Bus Monitor)、包(Packet )存储器、握手同步模块;
CPU通过一个AXI Slave接口连接到存储器映射寄存器(MMR),以用于将配置信息存入DMA引擎(DMA Engine)和包处理引擎(Packet Processing Engine)中的寄存器;
CPU从外部接口接收到数据包(PPP数据帧)或者是上层应用程序产生了数据包(IP报文),并存放在内存(DDR)中;
CPU通过AXI Slave接口把数据包(PPP数据帧或者IP报文)的描述符(Descriptor)储存到描述符(Descriptor)存储器中;
同时总线监视器(Bus Monitor)检测到CPU存储了描述符,说明有新的数据包要进行处理,于是提取对应的描述符的基础描述片段写入DMA引擎(DMA Engine)中的缓存,该缓存采用了先入先出(FIFO)队列的方式;
DMA引擎通过AXI Master接口,根据读取到的数据包在内存DDR中的存储地址,读取对应的数据包到包(Packet)存储器中,当读取一个数据包完毕,DMA引擎会向包处理引擎(Packet Processing Engine)发送读取完毕(Read_done)信号,通知包处理引擎该数据包已经读取完毕,包处理引擎可以开始工作了;
包处理引擎根据PPP协议对数据帧格式的要求进行组帧和解帧的处理,处理完成之后,把最后得到的数据包存入包(Packet)存储器中。同时向DMA引擎发送处理完毕(Process_done)的信号,通知DMA引擎数据包已经处理完成;
DMA引擎通过AXI Master接口,将处理完成的数据包从包存储器中搬运到内存DDR其对应的输出缓存(buffer)中,对于组帧和解帧分别有各自的输出buffer,并通过索引信息进行管理;
由存储器映射寄存器(MMR)发出中断请求信号(int_req),经过握手同步模块与外部的中断控制器的时钟域同步,中断控制器返回的中断响应信号(int_ack)同样经过握手同步模块与存储器映射寄存器(MMR)的时钟域同步之后,返回给存储器映射寄存器。
进一步,当所述FIFO为空时,DMA引擎的主状态机处于初始状态;当FIFO为非空,则DMA引擎进入读状态,DMA引擎首先从FIFO中读取当前最先存入的数据包对应的基础描述片段,然后根据该读取的基础描述片段从描述符存储器中读取对应的数据包的详细描述符信息,主要包括数据包的长度、及其在内存DDR中的存储地址、通道号(用来区分是组帧还是解帧)等信息。
进一步,所述包处理引擎将包存储器中的数据包读入,如果是包含了一个完整的数据包,根据通道号,则开始进行组帧或者解帧的处理;1时,对应的是进行组帧处理,[h2]对于组帧来说,由于输入的时候保证是一个完整的IP报文,所以当通道号为1时,就认为是收到了一个完整的数据包了;当通道号为2时,也就是对于解帧来说,由于输入的是字节流,因此需要检查以0x7E开头和0x7E结尾的一段数据,如果只有开始的0x7E,在输入的数据包中,没有找到结尾的0x7E,则认为不是一个完整的数据包,此时不进行解帧的工作,同时对该数据包进行标记,等待下次输入的数据包中包含了0x7E,才认为接收到了一个完整的数据包,然后才进行解帧的工作。
进一步,一种基于PPP数据帧组帧和解帧硬件加速器,对数据进行处理的具体过程为:
步骤1、配置加速器的存储器映射寄存器,并启动加速器;
步骤2、然后等待输入数据包的描述符信息,加速器内部的总线监视器会一直监视总线的情况;
步骤3、当总线监视器监视到总线有数据,则判断是否是输入数据包的描述符信息,如果是,则提取对应的描述符的基础描述片段写入DMA引擎中的缓存FIFO,如果不是,则回到步骤2继续等待;
步骤4、当DMA引擎发现FIFO不为空的时候,则开始根据描述符信息提供的数据包保存在内存DDR中的地址和长度,把数据包读取进来;
步骤5、然后再根据描述符信息中提供的通道号,来区分做什么处理;如果是通道1的数据包,则做组帧处理,否则做解帧处理;
步骤6、把数据包处理完成之后,然后检查内存DDR上对应的输出buffer是否满了,对于通道1的数据包,处理完成之后,存放到buffer1,对于通道2的数据包,处理完成之后,存放到buffer2;对应的输出buffer的剩余内存空间能否放得下刚处理完成的数据包,如果满了,则跳转到步骤7来处理,如果没有满,则跳转到步骤9来处理;
步骤7、写入中断,通知软件来读取之前已经处理完成的数据包;
步骤8、软件读取之前已经处理完成的数据包,然后把中断位清掉,加速器发现中断位被清掉之后,跳转到步骤6;
步骤9、把处理完成的数据包,写入到DDR中对应的输出buffer上,同时通过索引信息进行管理。
与现有技术相比,本发明的有益效果是:通过本发明的加速器,在对PPP数据帧进行组帧和解帧时,软件不需要对信息域中的每个字节都进行检查判断,仅当输出buffer满时才进行额外的处理,不需要占用大量CPU运算资源,降低的CPU参与运算的功耗;提高了数据吞吐量,使得运算效率得以提高,且速度快。
附图说明
图1是本发明一种基于PPP数据帧组帧和解帧硬件加速器的系统框图示意图;
图2是本发明一种基于PPP数据帧组帧和解帧硬件加速器的运行结构示意图;
图3是本发明一种基于PPP数据帧组帧和解帧硬件加速器的数据处理流程图;
图4是PPP协议的报文封装格式。
具体实施方式
在对技术方案进行说明之前,先对本发明的一些前提条件做一些说明。当作为PPP数据帧的发送端时(组帧),由于PPP协议中包含的LCP协议和NCP协议所组成的PPP数据帧是一个长度很短的报文,长度通常只有几个字节到几十个字节,而且LCP和NCP的报文只有在创建和关闭PPP连接时交互得比较多,在中间传输IP报文阶段,是很少的,只有少量的心跳包。所以,对于这种内部协议所产生的数据帧就不需要经过硬件加速器了,CPU自行组帧之后,直接通过外部接口发送出去了,因为数据帧太短而且太少了,体现不出硬件加速的优势。所以,作为PPP数据帧的发送端时(组帧),本硬件加速器只考虑IP报文封装在PPP数据帧的情况。而作为PPP数据帧的接收端时(解帧),本硬件加速器需要处理所有的PPP数据帧,因为从外部接口接收到是字节流,如果需要软件把帧头和帧尾找出来的话,太耗时了。因此,当作为PPP数据帧的接收端端时,本硬件加速器能够支持对字节流的输入,自动分析出帧头和帧尾,并对数据帧进行处理。
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
并且,本发明各个实施例之间的技术方案可以相互结合,但是必须是以本领域普通技术人员能够实现为基础,当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在,也不在本发明要求的保护范围之内。
请参阅附图1一种基于PPP数据帧组帧和解帧硬件加速器的系统框图示意图,首先CPU把需要处理的数据包长度、数据包保存在内存中的首地址和通道号等信息组成接收描述符存储到加速器内部的存储器中。通道号主要是用来区分是组帧还是解帧。在这里,通道1表示是组帧,通道2表示是解帧。然后,加速器通过内部的总线监视器监测到有新的数据包,就会根据描述符中的信息,从内存存储器(DDR)中将接收到的数据包搬运到其内部的存储器中,然后根据PPP数据帧的组帧和解帧规则,对数据包进行处理。最后,把处理完成得到的数据包(可能是经过组帧后的PPP数据帧,或者是经过解帧后的数据包)搬运到相应的内存存储器DDR 中的存储空间中。
请参阅附图2一种基于PPP数据帧组帧和解帧硬件加速器的详细工作流程说明如下(序号与图2中的序号对应):
①CPU通过一个AXI Slave接口连接到存储器映射寄存器(MMR),以用于将配置信息存入DMA引擎(DMA Engine)和包处理引擎(Packet Processing Engine)中的寄存器。
②CPU从外部接口接收到数据包(PPP数据帧)或者是上层应用程序产生了数据包(IP报文),并存放在内存(DDR)中。
③CPU通过AXI Slave接口把数据包(PPP数据帧或者IP报文)的描述符(Descriptor)储存到描述符(Descriptor)存储器中。
④同时总线监视器(Bus Monitor)检测到CPU存储了描述符,说明有新的数据包要进行处理,于是提取对应的描述符的基础描述片段写入DMA引擎(DMA Engine)中的缓存,该缓存采用了先入先出(FIFO)的方式。
⑤当FIFO为空时,DMA引擎的主状态机处于初始状态。只要FIFO为非空,则DMA引擎进入读状态。DMA引擎首先从FIFO中读取当前最先存入的数据包对应的基础描述片段,然后根据该读取的基础描述片段从描述符存储器中读取对应的数据包的详细描述符信息,主要包括数据包的长度、及其在DDR中的存储地址、通道号(用来区分是组帧还是解帧)等信息。
⑥DMA引擎通过AXI Master接口,根据读取到的数据包在DDR中的存储地址,读取对应的数据包到包(Packet)存储器中。当读取一个数据包完毕,DMA引擎会向包处理引擎(Packet Processing Engine)发送读取完毕(Read_done)信号,通知包处理引擎该数据包已经读取完毕,包处理引擎可以开始工作了。于是,包处理引擎将包存储器中数据包读入,如果是包含了一个完整的数据包,根据通道号,则开始进行组帧或者解帧的处理。1时,对应的是进行组帧处理,[h3] 对于组帧来说,由于输入的时候保证是一个完整的IP报文,所以当通道号为1时,就认为是收到了一个完整的数据包了。当通道号为2时,也就是对于解帧来说,由于输入的是字节流,因此需要检查以0x7E开头和0x7E结尾的一段数据,如果只有开始的0x7E,在输入的数据包中,没有找到结尾的0x7E,则认为不是一个完整的数据包,此时不进行解帧的工作,同时对该数据包进行标记,等待下次输入的数据包中包含了0x7E,才认为接收到了一个完整的数据包,然后才进行解帧的工作。
⑦包处理引擎根据PPP协议对数据帧格式的要求进行组帧和解帧的处理,处理完成之后,把最后得到的数据包存入包(Packet)存储器中。同时向DMA引擎发送处理完毕(Process_done)的信号,通知DMA引擎数据包已经处理完成。
⑧DMA引擎通过AXI Master接口,将处理完成的数据包从包存储器中搬运到DDR其对应的输出缓存(buffer)中。对于组帧和解帧分别有各自的输出buffer,并通过索引信息进行管理。
⑨同时,该硬件加速器的中断请求信号(int_req)由存储器映射寄存器(MMR)发出,经过握手同步模块与外部的中断控制器的时钟域同步。中断控制器返回的中断响应信号(int_ack)同样经过握手同步模块与存储器映射寄存器(MMR)的时钟域同步之后,返回给存储器映射寄存器。
请参阅附图3一种基于PPP数据帧组帧和解帧硬件加速器对数据的处理流程进行说明;
步骤1、配置加速器的存储器映射寄存器,并启动加速器;
步骤2、然后等待输入数据包的描述符信息,加速器内部的总线监视器会一直监视总线的情况;
步骤3、当总线监视器监视到总线有数据,则判断是否是输入数据包的描述符信息,如果是,则提取对应的描述符的基础描述片段写入DMA引擎中的缓存FIFO,如果不是,则回到步骤2继续等待;
步骤4、当DMA引擎发现FIFO不为空的时候,则开始根据描述符信息提供的数据包保存在内存DDR中的地址和长度,把数据包读取进来;
步骤5、然后再根据描述符信息中提供的通道号,来区分做什么处理;如果是通道1的数据包,则做组帧处理,否则做解帧处理;
步骤6、把数据包处理完成之后,然后检查内存DDR上对应的输出buffer是否满了,也就是说,对应的输出buffer的剩余内存空间能否放得下刚处理完成的数据包。如果满了,则跳转到步骤7来处理,如果没有满,则跳转到步骤9来处理;
步骤7、写入中断,通知软件来读取之前已经处理完成的数据包;
步骤8、软件读取之前已经处理完成的数据包,然后把中断位清掉,加速器发现中断位被清掉之后,跳转到步骤6;
步骤9、把处理完成的数据包,写入到DDR中对应的输出buffer上,同时通过索引信息进行管理。
以上所述仅为本发明的较佳实施方式,本发明的保护范围并不以上述实施方式为限,但凡本领域普通技术人员根据本发明所揭示内容所作的等效修饰或变化,皆应纳入权利要求书中记载的保护范围内。
Claims (4)
1.一种基于PPP数据帧组帧和解帧硬件加速器,其特征在于,包括了:CPU、AXI Slave接口、AXI Master接口、存储器映射寄存器(MMR)、DMA引擎(DMA Engine)、包处理引擎(PacketProcessing Engine)、内存(DDR)、描述符(Descriptor)存储器、总线监视器(BusMonitor)、包(Packet )存储器、握手同步模块;CPU通过一个AXI Slave接口连接到存储器映射寄存器(MMR),以用于将配置信息存入DMA引擎(DMA Engine)和包处理引擎(PacketProcessing Engine)中的寄存器;CPU从外部接口接收到数据包(PPP数据帧)或者是上层应用程序产生了数据包(IP报文),并存放在内存(DDR)中;CPU通过AXI Slave接口把数据包(PPP数据帧或者IP报文)的描述符(Descriptor)储存到描述符(Descriptor)存储器中;同时总线监视器(Bus Monitor)检测到CPU存储了描述符,说明有新的数据包要进行处理,于是提取对应的描述符的基础描述片段写入DMA引擎(DMA Engine)中的缓存,该缓存采用了先入先出队列FIFO的方式;DMA引擎(DMA Engine)通过AXI Master接口,根据读取到的数据包在内存(DDR)中的存储地址,读取对应的数据包到包[h1] 存储器中,当读取一个数据包完毕,DMA引擎(DMA Engine)会向包处理引擎(Packet Processing Engine)发送读取完毕(Read_done)信号,通知包处理引擎(Packet Processing Engine)该数据包已经读取完毕,包处理引擎(Packet Processing Engine)开始工作;包处理引擎(Packet ProcessingEngine)根据PPP协议对数据帧格式的要求进行组帧和解帧的处理,处理完成之后,把最后得到的数据包存入包(Packet)存储器中,同时向DMA引擎(DMA Engine)发送处理完毕(Process_done)的信号,通知DMA引擎数据包已经处理完成;DMA引擎(DMA Engine)通过AXIMaster接口,将处理完成的数据包从包存储器中搬运到内存(DDR)其对应的输出缓存(buffer)中,对于组帧和解帧分别有各自的输出buffer,并通过索引信息进行管理;由存储器映射寄存器(MMR)发出中断请求信号(int_req),经过握手同步模块与外部的中断控制器的时钟域同步,中断控制器返回的中断响应信号(int_ack)同样经过握手同步模块与存储器映射寄存器(MMR)的时钟域同步之后,返回给存储器映射寄存器(MMR)。
2.根据权利要求1所述的一种基于PPP数据帧组帧和解帧硬件加速器,其特征在于:当所述FIFO为空时,DMA引擎的主状态机处于初始状态;当FIFO为非空,则DMA引擎进入读状态,DMA引擎首先从FIFO中读取当前最先存入的数据包对应的基础描述片段,然后根据该读取的基础描述片段从描述符存储器中读取对应的数据包的详细描述符信息,主要包括数据包的长度、及其在内存DDR中的存储地址、通道号(用来区分是组帧还是解帧)等信息。
3.根据权利要求1所述的一种基于PPP数据帧组帧和解帧硬件加速器,其特征在于:所述包处理引擎将包存储器中数据包读入,如果是包含了一个完整的数据包,根据通道号,则开始进行组帧或者解帧的处理;[h2] 对于组帧来说,由于输入的时候保证是一个完整的IP报文,所以当通道号为1时,就认为是收到了一个完整的数据包了;当通道号为2时,也就是对于解帧来说,由于输入的是字节流,因此需要检查以0x7E开头和0x7E结尾的一段数据,如果只有开始的0x7E,在输入的数据包中,没有找到结尾的0x7E,则认为不是一个完整的数据包,此时不进行解帧的工作,同时对该数据包进行标记,等待下次输入的数据包中包含了0x7E,才认为接收到了一个完整的数据包,然后才进行解帧的工作。
4.根据权利要求1所述的一种基于PPP数据帧组帧和解帧硬件加速器,其特征在于:对数据进行理的具体过程为:
步骤1、配置加速器的存储器映射寄存器,并启动加速器;
步骤2、然后等待输入数据包的描述符信息,加速器内部的总线监视器会一直监视总线的情况;
步骤3、当总线监视器监视到总线有数据,则判断是否是输入数据包的描述符信息,如果是,则提取对应的描述符的基础描述片段写入DMA引擎中的缓存FIFO,如果不是,则回到步骤2继续等待;
步骤4、当DMA引擎发现FIFO不为空的时候,则开始根据描述符信息提供的数据包保存在内存DDR中的地址和长度,把数据包读取进来;
步骤5、然后再根据描述符信息中提供的通道号,来区分做出相应的处理;如果是通道1的数据包,则做组帧处理,否则做解帧处理;
步骤6、把数据包处理完成之后,然后检查内存DDR上对应的输出buffer是否满了,对于通道1的数据包,处理完成之后,存放到buffer1,对于通道2的数据包,处理完成之后,存放到buffer2;对应的输出buffer的剩余内存空间能否放得下刚处理完成的数据包,如果已满,则跳转到步骤7来处理,如果未满,则跳转到步骤9来处理;
步骤7、写入中断,通知软件来读取之前已经处理完成的数据包;
步骤8、软件读取之前已经处理完成的数据包,然后把中断位清掉,加速器发现中断位被清掉之后,跳转到步骤6;
步骤9、把处理完成的数据包,写入到内存DDR中对应的输出buffer上,同时通过索引信息进行管理。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910743923.9A CN110445585A (zh) | 2019-08-13 | 2019-08-13 | 基于ppp数据帧组帧和解帧硬件加速器 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910743923.9A CN110445585A (zh) | 2019-08-13 | 2019-08-13 | 基于ppp数据帧组帧和解帧硬件加速器 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN110445585A true CN110445585A (zh) | 2019-11-12 |
Family
ID=68435078
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910743923.9A Pending CN110445585A (zh) | 2019-08-13 | 2019-08-13 | 基于ppp数据帧组帧和解帧硬件加速器 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110445585A (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113014510A (zh) * | 2019-12-19 | 2021-06-22 | 航天科工惯性技术有限公司 | 惯导系统分布式测试中数据缓存方法及装置 |
CN113721972A (zh) * | 2020-05-25 | 2021-11-30 | Oppo广东移动通信有限公司 | 硬件加速器配置信息的配置方法、装置及存储介质 |
CN113866502A (zh) * | 2021-12-02 | 2021-12-31 | 深圳市鼎阳科技股份有限公司 | 频谱分析仪及其数据扫描和处理方法 |
CN116758968A (zh) * | 2023-08-16 | 2023-09-15 | 英诺达(成都)电子科技有限公司 | 存储器内建自测试方法及其电路、芯片 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1477885A (zh) * | 2002-08-21 | 2004-02-25 | 深圳市中兴通讯股份有限公司 | 一种实现高级链路控制规程帧处理的方法 |
CN102984166A (zh) * | 2012-12-07 | 2013-03-20 | 苏州简约纳电子有限公司 | 一种ip数据包过滤器 |
CN103885840A (zh) * | 2014-04-04 | 2014-06-25 | 华中科技大学 | 一种基于AXI4总线的FCoE协议加速引擎IP核 |
-
2019
- 2019-08-13 CN CN201910743923.9A patent/CN110445585A/zh active Pending
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1477885A (zh) * | 2002-08-21 | 2004-02-25 | 深圳市中兴通讯股份有限公司 | 一种实现高级链路控制规程帧处理的方法 |
CN102984166A (zh) * | 2012-12-07 | 2013-03-20 | 苏州简约纳电子有限公司 | 一种ip数据包过滤器 |
CN103885840A (zh) * | 2014-04-04 | 2014-06-25 | 华中科技大学 | 一种基于AXI4总线的FCoE协议加速引擎IP核 |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113014510A (zh) * | 2019-12-19 | 2021-06-22 | 航天科工惯性技术有限公司 | 惯导系统分布式测试中数据缓存方法及装置 |
CN113014510B (zh) * | 2019-12-19 | 2023-01-20 | 航天科工惯性技术有限公司 | 惯导系统分布式测试中数据缓存方法及装置 |
CN113721972A (zh) * | 2020-05-25 | 2021-11-30 | Oppo广东移动通信有限公司 | 硬件加速器配置信息的配置方法、装置及存储介质 |
CN113721972B (zh) * | 2020-05-25 | 2024-04-16 | Oppo广东移动通信有限公司 | 硬件加速器配置信息的配置方法、装置及存储介质 |
CN113866502A (zh) * | 2021-12-02 | 2021-12-31 | 深圳市鼎阳科技股份有限公司 | 频谱分析仪及其数据扫描和处理方法 |
CN116758968A (zh) * | 2023-08-16 | 2023-09-15 | 英诺达(成都)电子科技有限公司 | 存储器内建自测试方法及其电路、芯片 |
CN116758968B (zh) * | 2023-08-16 | 2023-12-08 | 英诺达(成都)电子科技有限公司 | 存储器内建自测试方法及其电路、芯片 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110445585A (zh) | 基于ppp数据帧组帧和解帧硬件加速器 | |
JP3938599B2 (ja) | 多重ネットワークプロトコルエンコーダ/デコーダ及びデータプロセッサ | |
CN111327603B (zh) | 数据传输方法、装置和系统 | |
CN106951388A (zh) | 一种基于PCIe的DMA数据传输方法及系统 | |
CN110417780A (zh) | 定制化数据传输协议的多通道高速数据接口转化模块 | |
CN115102780B (zh) | 数据传输方法、相关装置、系统及计算机可读存储介质 | |
CN109819065A (zh) | 基于fpga的数据传输及存储系统、方法以及数据系统 | |
CN102546542B (zh) | 电子系统及其嵌入式设备和中转设备 | |
CN108462620B (zh) | 一种吉比特级SpaceWire总线系统 | |
CN103164314B (zh) | 基于异步物理层接口的PCIe接口芯片硬件验证方法 | |
CN114297124B (zh) | 一种基于fpga的srio高速总线的通讯系统 | |
CN115604052B (zh) | 车辆通讯交互方法、系统及电子设备 | |
CN112261142A (zh) | 一种rdma网络的数据重传方法、装置及fpga | |
CN114915499B (zh) | 数据传输方法、相关装置、系统及计算机可读存储介质 | |
CN114422617B (zh) | 一种报文处理方法、系统及计算机可读存储介质 | |
CN107846328B (zh) | 基于并发无锁环形队列的网络速率实时统计方法 | |
CN207424866U (zh) | 一种基于异构多核处理器的内核之间的数据通讯系统 | |
CN102647412B (zh) | 移动显示数字接口的包结构 | |
CN112147918B (zh) | 基于arm+fpga+dsp架构的异步数据交互方法及系统 | |
CN109189711B (zh) | 基于以太网的串行控制台接口及其应用方法 | |
CN113609041A (zh) | 一种数据传输方法及系统 | |
CN113051212A (zh) | 图形处理器、数据传输方法、装置、电子设备和存储介质 | |
CN111193545A (zh) | 一种基于以太网的自校验光纤数据单向传输方法及系统 | |
CN109800035A (zh) | 一种算法集成服务框架系统 | |
WO2024060247A1 (zh) | 基于蓝牙通信的数据交互方法、装置、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20191112 |
|
RJ01 | Rejection of invention patent application after publication |