文章总结: 文档主要介绍SOC片上互联设计,重点聚焦NOC架构。阐述了MESH互联形态及组件结构,深入分析开关节点设计演进,通过引入虚拟通道、旁路控制器及资源共享机制解决队头阻塞与拥塞问题。同时简要介绍了源路由、分布式路由等多种路由算法分类。文章属于技术科普,旨在解析片上通信瓶颈的解决方案。 综合评分: 75 文章分类: 其他
SOC片上互联设计
谈思实验室
2026年2月25日 17:16 上海
点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
01
前言
SOC片上互联的核心思想就是把各个硬件组件连接起来而且能够高效率地进行通信。片上互联的发展需求来自于集成电路从小规模到大规模高度集成化高频高带宽低延迟的诉求。
片上互联结构对比
本文主要focus在NOC互联结构。NOC的核心思想是将计算机网络技术移植到IC电路,从体系结构上彻底解决片上通信的瓶颈问题,同时解决timing等问题。利用分布式的计算机系统通信方式,利用路由和分组交换技术替代传统的总线通信方式,结构化的网格互联提供更高的带宽,支持多重并行通信,兼具多任务并行计算,结构灵活性强的优点。
02
NOC架构
MESH互联形态
在深入NOC架构之前,我们来先了解一下基于ARM CMN MESH互联的系统形态。
example
基于CMN的示例可以看到至少包含如下信息:
1.包括很多个XP;2.每个XP除了互联临近的XP之外带有2个口;3.每个XP都带有坐标信息;4.该图显示的是2维互联形态。
NOC组件结构
通常意义上,NOC网络包括如下组成:
- 资源节点:执行计算和缓存等操作的硬件;
- 开关节点:也叫通信节点,核心功能是路由器,包括路由选择,仲裁,开关阵列,输入输出缓存等;
- 通道:资源节点和开关节点之间,或者开关节点之间的互联通信的载体;
开关节点的原始结构(通用)
传统的switch 节点的设计架构如图,每个节点包括输入和输出方向。
- 输入方向包括5路或者说5个通道的请求,N,S,E,W,L其中除了东南西北4个方向的请求之外,local的请求也参与仲裁;
- 输出方向同样包括东南西北以及local;
- 每一路输入channel都包括了小容量buff,吸收一定个数的请求,和MESH链路上的outstanding;
- Arbiter对每个方向进来的请求判断去处,同时会遇到不同方向输入到同一个方向输出的需要做仲裁;
switch节点隐藏了一个路由的判定,怎么知道一个请求到走那个出口哪个方向,结合CMN坐标系的定义可以发现,采用2维坐标作为node定标,同时传输的报文携带源和目的地坐标,即可完成链路的路由,当然还有其他高级路由方式。
开关节点的结构一
基于原始节点结构,一个方向的输入会暂时进入队列,然后参与仲裁。可以发现存在一个场景下的问题:如果出现第一个请求要路由目的方向为E,第二个请求路由目的方向为W,之后的目的路由方向为L,但是因为第一个请求被堵塞,堵塞的原因可能是目的出口E的方向被反压,或者仲裁机制仲裁判决给其他输入端口,这样就导致对头阻塞。严重影响通信效率。
基于该问题:对输入请求如果按照去向预仲裁,放入不同的buff,然后各自参与switch 仲裁,有效缓解对头阻塞。
所以可以对输入buff通道进行优化,结构如下:
结合原始switch结构图,加上预分配通道可以得到一种新结构的switch node设计:
开关节点的结构二
增加预分配通道(VC)之后可以看到,路由目的地预解析后存放的VC只接受特定方向的请求,那如果其中某一个VC出现通道拥塞或者通道坏死的情况,就只能把上游的请求反压,然后又拥塞在上游的node 对应通道的VC里面,如此会造成路由器拥塞传递,增大网络延迟,减低吞吐率。
如果本switch node的其他方向入口对应的VC没有出现拥塞,那是否可以借用呢? 针对一个请求,进入switch node的生命周期是为了路由出口,能够按照正确路由方向输出,基于此判断,该请求是存在E或者W的VC不会影响其最终路由结果。
所以提出一种新的switch 结构
可以看到在预分配阶段可以互相利用临近资源进行节点入口缓存。该结构主要包括5个输入输出端口,路由计算模块,虚通道分配模块,交叉开关分配模块和旁路控制器组成。其中路由计算模块采用前向路由技术,数据包从输入端口进入后会通路进行路由计算和虚通道分配操作,此路路由计算的结果数数据包在进入下游路由器后需要发完的输出端口,这种前向路由技术使得数据包在路由器中的输入变成4阶段的流水,减少了数据包在网络中的传输延时。
数据包进入输入端口后,会经过VC选择器、双向fifo控制器和输出选择器阶段,接受siwtch 开关的仲裁。
开关节点结构三
多local 通道
进一步地,在SOC片上系统,可能存在一些计算单元对带宽需求更加高,那么针对switch node节点的设计需要考虑通道的replicate问题,允许系统可配置local交互通道数量,当然对于crossbar switch之间的联通也允许通道double实现更高效率的传输,比如针对memory上NOC switch node,可以使能replicate channel 来double 带宽。
03
路由算法
计算机网络已经提出很多路由算法。按照标准不同,可以分为以下几类:
(1)source routing
源路由是指在发送数据包之前,由源节点确定整个传输路径。因此每个数据包都携带路由信息,增加了数据包的尺寸;
(2)distributed routing
分布式路由是指每个通信节点在接收到数据包之后,再决定该数据包是传输给当前的资源节点还是继续往前传递给相邻的节点;
(3)detrerministic routing
在确定路由中传输的路径完全由源和目标地址来决定;
(4)adaptive routing
自适应路由是指在给定的源和目标地址,根据网络状况来确定数据包的传输路径;
(5)minimal routing
最短路由市值路径满足源和目标节点之间的最短距离;
(6)non-minimal routing
非最短路由允许根据当前网络的状况选择较长的路径来传输,如果使用非最短路由,必须小心出现活锁现象(数据包在mesh网络里一直在传播,但是就是无法传到目标节点)
来源:知乎@北极星
https://zhuanlan.zhihu.com/p/555962119
谈思-汽车出海安全合规(欧洲)
交流群
谈思 AutoSec Europe 峰会旨在搭建一个能融汇全球视野与中国实践、连接技术前沿与落地应用的国际性专业平台,以助力中国汽车应对在出海过程中面临的网络与数据安全合规痛点。从前沿技术研讨、合规要点解析到经验交流,都将通过本平台为您提供持续支持。社群已超过200人,需邀请加入,如需入群,欢迎添加社群小助手微信taaslabs01。
谈思-SDV&AIDV技术出海
交流群
诚邀行业同仁加入谈思SDV&AIDV出海技术交流群,聚焦软件定义汽车、AI定义汽车、下一代EEA、智能座舱、智能驾驶、软件架构、域控制器开发、芯片技术、软件工具等核心议题,欢迎大家加群交流探讨~~社群已超过200人,需邀请加入,如需入群,欢迎添加社群小助手微信taaslabs01。
end
谈思汽车媒体门户
精品活动推荐
AutoSec系列沙龙
专业社群
部分入群专家来自:
新势力车企:
特斯拉、理想、极氪、小米、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯……
外资传统主流车企代表:
大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚……
内资传统主流车企:
吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用……
全球领先一级供应商:
博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、潍柴集团、地平线、紫光同芯、字节跳动、……
二级供应商(500+以上):
中科数测、ETAS、BlackDuck、NXP、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学……
人员占比
公司类型占比
文章
不要错过哦,这可能是汽车网络安全产业最大的专属社区!
关于涉嫌仿冒AutoSec会议品牌的律师声明
一文带你了解智能汽车车载网络通信安全架构
网络安全:TARA方法、工具与案例
汽车数据安全合规重点分析
浅析汽车芯片信息安全之安全启动
域集中式架构的汽车车载通信安全方案探究
系统安全架构之车辆网络安全架构
车联网中的隐私保护问题
智能网联汽车网络安全技术研究
AUTOSAR 信息安全框架和关键技术分析
AUTOSAR 信息安全机制有哪些?
信息安全的底层机制
汽车网络安全
Autosar硬件安全模块HSM的使用
首发!小米雷军两会上就汽车数据安全问题建言:关于构建完善汽车数据安全管理体系的建议
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:谈思实验室 《SOC片上互联设计》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。








评论