Chiplet-4D毫米波雷达-总线互联IP分析

Chiplet-4D毫米波雷达-总线互联IP分析

自研4D毫米波雷达+前融合感知算法 复睿智行自动驾驶破局之道

 

 

 自动驾驶的未来究竟是纯视觉还是融合感知，今天早已没有悬念。即便激进如马斯克，也开始亲自下场造毫米波雷达，重拾融合感知路线。让他改变主意的正是横空出世的4D毫米波雷达。拥有了俯仰探测能力的4D毫米波雷达在精度大幅提升，且可不再受困于静止障碍物，全天候的优点更让它不可或缺。如今L3、L4级别自动驾驶迟迟无法落地，也告诉我们市场上的确需要更好的毫米波雷达。

无独有偶，特斯拉走的这条路线，国内早已有厂商在走。11月25日，复睿智行举行产品发布会。作为公司成立一年多以来的首次公开亮相，复睿智行现场发布了以自研高性能4D毫米波雷达+前融合感知算法为核心的自动驾驶感知解决方案，让我们看到了突破当前自动驾驶感知瓶颈的希望。

 

 

 不再鸡肋 高性能4D毫米波雷达的逆袭

如果说感知界有鄙视链，那么摄像头、毫米波雷达与激光雷达三者一定谁都不服谁。摄像头会鄙视毫米波雷达的精度太低，只能对少部分物体进行精准探测，犹如鸡肋；毫米波雷达鄙视摄像头距离不行，没有全天候能力，一下雨、下雪就不能工作了；而激光雷达问世之后，大家又发现一个激光雷达比一辆车还贵，根本落不了地。事实就是，每种传感器各有所长，融合是必然之路。同时，每种传感器都在努力突破自身的瓶颈，加速自动驾驶真正的到来。
4D毫米波雷达正是一项突破瓶颈式的革新，因为4D相较于3D（方位、距离、速度）多出的一个D正是弥补测高缺陷的俯仰角探测能力。一个4D成像毫米波雷达的点云密度更是可媲美一个低线束的激光雷达。这一切颠覆式的升级还都不影响它保持全天候工作与成本低两大优点。
在复睿智行发布会现场，公司首席技术官周轶博士发布了首个高性能4D毫米波雷达产品——哥伦布系列雷达。作为一款非成像4D雷达，其前雷达最大探测距离达到300米，水平视场角120°，分辨率低至2.8°，垂直视场角±15°，垂直角精度低至±0.5°；角雷达最大探测距离达到200米，水平视场角160°，分辨率低至4.8°，垂直视场角±15°，垂直角精度低至±1°。各项性能比肩国际头部厂商最新一代产品，居世界领先地位。

 

 

 据周轶博士介绍，哥伦布系列是市面上第一款使用四发四收解决方案的雷达，且这款雷达在波形上采用最新一代DDMA-MIMO波形，配合大天线合成孔径+超分辨率算法、3层俯仰天线布局以及智能抗干扰技术，使得产品相较市场主流的3发4收雷达，具有50%的探测距离提升，2倍的水平探测性能提升，2倍的俯仰性能提升以及3倍的稳定性提升。

作为基础版（Standard）产品，哥伦布系列雷达由复睿智行用仅仅不到1年时间研发完成，预计将于2023年第二季度开始量产。而在公司的在研产品管线上，两款4D成像雷达已赫然在列，分别是6发8收、最大探测距离可达350米的毕加索（Advanced）系列与12发16收、最大探测距离可达400米的毕加索（Premium）。这两款产品预计都将在2023年四季度开始量产。
为了更好地让我们理解一款优秀的毫米波雷达的重要性，周轶博士解释道：“在很多自动驾驶的车祸中，汽车都是无视前方障碍物全速撞上去的。这是因为毫米波雷达没探测到吗？并不是，而是主机厂往往不敢用毫米波雷达去做刹车动作。因为它的测高能力不好，你不能保证这个物体到底是可以驶过的，还是不可以驶过的。如果是一个下水道井盖导致了误刹车，造成后车追尾，那么主机厂就要承担责任，所以一般会选择宁可漏刹也不要错刹。因为漏刹是驾驶员的责任，误刹就是主机厂的责任了。但是好的4D雷达能让他们知道前方的物体是否可驶过，即使在摄像头失效的情况下，主机厂也可以听从毫米波雷达作出刹车动作。”

 

 

 摆脱数据焦虑 前融合感知算法的破局

高性能4D毫米波雷达只是解决了硬件端的问题，在软件端还需要依靠前融合算法来破局。数据焦虑困扰自动驾驶公司多年。美国加州车管局每年都会公布几家领先的自动驾驶公司前一年的路测数据。然而，动辄十万百万的测试里程数，却始终无法消除长尾效应，突发场景总是存在，导致自动驾驶也迟迟无法落地。问题就出在算法上。
当前市场上主流的感知算法绝大多数是基于后融合，即传感器各管各的，相机探测相机的，产生目标；激光雷达探测激光雷达的，产生目标；毫米波雷达探测毫米波雷达的，产生目标。然后把这些目标合在一起。这样的算法最大的问题便是在融合前，目标已经丢失大量原始信息，导致精度大幅降低，甚至将某个传感器的探测数据全部滤去。这就会产生事故的隐患，因此这样堆出来的数据，作用不大。
针对这一痛点，发布会上，复睿智行发布了自研的以前融合为核心的融合感知算法，相当于把摄像头、毫米波雷达还有激光雷达等原始数据先进行融合，再进行探测。
关于原理，周轶博士解释道：“好比把毫米波雷达当做一个低分辨率的相机，照一张相，可以直接构成一个三维空间，虽然精度不高，但景深信息，知道哪里有障碍物。单模摄像头虽然清晰度很高，但只有2D的平面信息，我们用毫米波雷达构造这样一个三维空间，把高清晰度摄像头的2D图象在三维空间进行投影，实现一个非常高清晰度3D空间。由此，对每一个目标我们知道它在哪里，形状是如何，运动还是静止。通过这样一个前融合，我们可以大大提高检测的精度。”

 

 

 但是前融合算法是有门槛的，那就是每个传感器都必须很好，就像木桶效应，如果毫米波雷达不够好就做不好前融合。而复睿智行采用自研高性能4D毫米波雷达来开发前融合算法的好处，不仅在于确保了体系中雷达的性能和质量，同时可以最大程度地释放雷达对算法的支持。这是复睿智行自主打造高性能4D毫米波雷达的原因，也是特斯拉这么做的原因。

基于自研4D毫米波雷达+前融合感知算法的强力组合，复睿智行所打造的感知方案能提供象素级别的深度信息，提供精确的目标形状，也可以解决非常见目标检测的数据样本不足的问题，因为即使摄像头不知道目标是什么，毫米波雷达也能知道它在哪里，以怎样的速度在运行，从而对外界目标实现非常精确的探测。

 

 正因为有了这些性能上的优点，复睿智行的融合感知能力可以支持全路况，不管是高速、国道、高低架桥还是乡村小路；全天候，因为方案融合了毫米波雷达、摄像头、激光雷达；全场景，可以满足从L0到了L4所有自动驾驶功能的感知需求；以及全目标的识别，无论是很小的目标还是很大的目标，都会提供象素级别的深度信息。

4D毫米波雷达，是对传统毫米波雷达的一次划时代的升级。前融合算法，也是对后融合算法的一次革命性的进化。复睿智行所打造的“软硬一体”的融合感知平台，让我们距离自动驾驶的大规模商业化落地又再进了一步。

Chiplet UCIe协议已定，CPU、GPU、DPU混战开启，未来路在何方？

Chiplet形成标准的UCIe协议，这为多个“芯片”互联成更大的“宏芯片”扫清了最后的障碍。当前，很多芯片的设计规模和板级多芯片协同的功能划分，都是基于现有工艺下的面积和晶体管规模约束而形成的。当Chiplet成为主流，很多芯片的功能范畴将发生质的变化。

CPU、GPU和DPU是数据中心的三大主流芯片，相互协同也相互影响，随着UCIe协议的确定，三者之间的界限变得模糊，未来的服务器芯片将走向何方？是走向更多核集成的平行扩展，还是把CPU、GPU和DPU的功能垂直集成到超异构计算单芯片？

接下来，我们详细见解。

---

参考文献：

1.UCIe白皮书，Universal Chiplet Interconnect Express (UCIe)®: Building an open chiplet ecosystem，https://www.uciexpress.org/_files/ugd/0c1418_c5970a68ab214ffc97fab16d11581449.pdf

2.https://www.eet-china.com/news/202203031041.html，英特尔、台积电、Arm、AMD等9大厂成立“UCIe产业联盟”，为Chiplet互联定制新标准

3.https://mp.weixin.qq.com/s/vdaujWZY0beoprxfGKUgpA，UCIe白皮书：打造Chiplet开放生态，半导体行业观察

---

1 Chiplet协议UCIe标准确定

英特尔、AMD、ARM、高通、三星、台积电、日月光等大厂，以及Google Cloud、Meta、微软于3月2日宣布了一项新技术标准UCIe（Universal Chiplet Interconnect Express）。UCIe是一个开放的行业互连标准，可以实现小芯片之间的封装级互连，具有高带宽、低延迟、经济节能的优点。

UCIe能够满足几乎所有计算领域，包括云端、边缘端、企业、5G、汽车、高性能计算和移动设备等，对算力、内存、存储和互连不断增长的需求。UCIe 具有封装集成不同Die的能力，这些Die可以来自不同的晶圆厂、采用不同的设计和封装方式。

 

 

 图1 UCIe开启开放式封装级生态系统交付平台

 

 

 图2 不同工艺节点的设计成本

Chiplets封装集成的价值有很多：

• 首先是面积的影响。为了满足不断增长的性能需求，芯片面积增加，有些设计甚至会超出掩模版面积的限制。即使不超过面积限制，改用多个小芯片也更有利于提升良率。另外，多个相同Die的集成封装能够适用于更大规模的场景。
• 另一个价值体现在降低成本。例如，图1所示的处理器核心可以采用先进的工艺，用更高的成本换取极致的性能，而内存和I/O控制器则可以复用非先进工艺。如图 2 所示，随着工艺节点的进步，成本增长非常迅速。若采用多Die集成模式，有些Die的功能不变，我们不必对其采用先进工艺，可在节省成本的同时快速抢占市场。Chiplet封装集成模式还可以使用户能够自主选择Die的数量和类型。例如，用户可以根据需求挑选任意数量的计算、内存和I/O Die，并无需进行Die的定制设计，可降低产品的SKU成本。
• 允许厂商能够以快速且经济的方式提供定制解决方案。如图1所示，不同的应用场景可能需要不同的计算加速能力，但可以使用同一种核心、内存和I/O。Chiplet方式允许厂商根据功能需求对不同的功能单元应用不同的工艺节点，并实现共同封装。相比板级互连，封装级互连具有线长更短、布线更紧密的优点。

 

 

 图 UCIe分层

UCIe 是一种分层协议，分为物理层、Die-to-Die适配器和协议层，如上图所示：

• 物理层负责处理电信号、时钟信号、链路训练和边带信号等。
• Die-to-Die适配器则为chiplet提供链路状态管理和参数调整。通过CRC和链路级重传机制保证数据的可靠传输。Die-to-Die适配器配备了底层仲裁机制用于支持多种协议，以及通过数据宽度为256字节的微片（FLIT）进行数据传输的底层传输机制。
• UCIe通过在协议层本地端提供PCIe和CXL协议映射，可以将已部署成功的SoC构建、链路管理和安全解决方案直接迁移到UCIe。通过PCIe/CXL.io（CXL子协议，下文中的Cache.Mem和Cache.cache同属此列）解决直接内存访问的数据传输、软件发现、错误处理等问题；主机内存则通过CXL.Mem访问；对缓存有特殊要求的加速器等应用程序可以使用 CXL.cache对主机内存进行高效的缓存。UCIe 还定义了一种“流协议”，可用于映射任何其他协议。此外，随着使用模型的发展，UCIe联盟可以通过不断创新来对Chiplet互连技术进行优化。

 

 

 图 封装选项：2D或2.5D

UCIe 1.0定义了两种类型的封装，如上图所示。其中标准封装(2D)成本效益更高，而更先进的封装（2.5D）则是为了追求同功率下更高的性能。实际设计中，有多种商用的封装方式可供选择，图表中仅展示其中一部分。UCIe规范支持所有这些类型的封装选择。

 

 

 UCIe支持不同的数据传输速率、位宽、凸点间隔、还有通道，来保证最广泛的可行的互用性，详细描述如上表所示。

 

 

 UCIe互联的单簇的组成单元是包含了N条单端、单向、全双工的数据线（标准封装选项中N=16，高级封装选项中N=64），一条单端的数据线用作有效信号，一条线用于追踪，每个方向都有一个差分的发送时钟，还有每个方向的两条线用于边带信号（单端，一条是800MHz的时钟，一条是数据线）。多簇的UCIe 互联可以组合起来，在每条连接链路上提供更优的性能，如上图所示。

2 CPU、GPU和DPU三国杀

 我们的世界中有三颗太阳，它们在相互引力的作用下，做着无法预测的三体运动：

 当我们的行星围绕着其中的一颗太阳做稳定运行时，就是恒纪元；

当另外一颗或两颗太阳运行到一定距离内，其引力会将行星从它围绕的太阳边夺走，使其在三颗太阳的引力范围内游移不定时，就是乱纪元；

一段不确定的时间后，我们的行星再次被某一颗太阳捕获，暂时建立稳定的轨道，恒纪元就又开始了。

 刘慈欣，《三体》第一部15章

 

 

 如三体一样，CPU、GPU和DPU，既相互协作，又相互竞争。随着Chiplet UCIe协议的确定，单芯片可以做到的设计规模突然增加了很多倍，这样，势必会引起CPU、GPU和DPU的功能的相互渗透甚至相互集成，直到最终形成新的稳定状态。

 

 

 也有点像三国时代：魏蜀吴三国正在混战，突然神奇的一幕发生，三个国家各自的人口、资源、财富都统统增加十倍，然后依靠山川、大河的天险所形成的边界，突然都变成了平地。这个时候，两两之间的混战就变得不可避免。

 

 

 一些基本的定位分析：

• 独立的DPU定位在基础设施处理器，主要是硬件加速；
• 独立的GPU主要做应用层的弹性计算加速；
• 而CPU主要负责低计算密度高价值密度的应用层的工作。

我们做一些假设：

• 一个面积单位刚刚是一个计算核；
• 如上图所示：CPU有60个面积单位，共计60个CPU核；GPU有60个面积单位，共计60个GPU Core（差不多对应流式多核处理器SM）；而DPU则由10个CPU核、10个GPU核以及40个其他加速引擎核组成。

 

 

 我们可以做如下分析，可以是平行扩展和垂直整合：

• 方向一：如上图（a）,平行扩展。CPU、GPU和DPU均平行扩展N倍。这样，CPU则具有60*N个CPU核，GPU则具有60*N个GPU核，DPU则具有10*N个CPU核、10*N个GPU核以及40*N个其他加速引擎核。
• 方向二：如上图（b）,完成垂直整合。CPU+GPU+DPU合并成一个超异构的单芯片。那么这个单芯片是70个CPU核、70个GPU核以及40个其他加速处理引擎组成。

介于两者之间的则是两两合并：

• 方向三，如上图（c）,CPU和GPU整合，独立DPU。
• 方向四，如上图（d），CPU和DPU整合，独立GPU。
• 方向五，如上图（e），GPU和DPU整合成独立加速平台，独立CPU。

3 未来的趋势：超异构计算

 

 

 芯片工艺以及Chiplet极致带来的资源规模越来越大，所能支撑的设计规模也越来越大，这给架构创新提供了非常坚实的基础。我们可以采用多种处理引擎共存，“专业的人做专业的事情”，来共同协作的完成复杂系统的计算任务。并且，CPU、GPU、FPGA、一些特定的算法引擎，都可以作为IP，被集成到更大的系统中。这样，构建一个更大规模的芯片设计成为了可能。这里，我们称之为“超异构计算”。如上图所示，超异构指的是由CPU、GPU、FPGA、DSA、ASIC以及其他各种形态的处理器引擎共同组成的超大规模的复杂芯片系统。

 

 

 数据中心的超异构计算大致有三种类型：

• DPU小系统。DPU已经明确是要整合嵌入式的CPU、GPU、FPGA、DSA以及ASIC等各种不同类型处理器引擎在一起的超异构混合计算架构的宏SOC。
• CPU+DPU中系统。如果我们把芯片的界限去掉，这样独立CPU+DPU可以理解成：独立CPU+嵌入式CPU+嵌入式GPU+其他嵌入式处理器引擎，依然是超异构计算架构。
• CPU+GPU+CPU大系统。同样的，无视芯片的物理界限，整个系统是由：独立CPU+独立GPU+嵌入式CPU + 嵌入式GPU + 嵌入式其他处理器引擎，架构依然没有本质变化，依然是超异构计算架构。

 

 

 上图是Intel对未来几年数据中心架构的基本看法。可以看到，不管是小系统、中系统还是大系统，本质上都是超异构计算架构。

4 超异构面临的挑战

4.1 性能和灵活性的矛盾

 

 

 指令是软件和硬件的媒介，指令的复杂度（单位计算密度）决定了系统的软硬件解耦程度。按照指令的复杂度，典型的处理器平台大致分为CPU、协处理器、GPU、FPGA、DSA、ASIC。任务在CPU运行，则定义为软件运行；任务在协处理器、GPU、FPGA、DSA或ASIC运行，则定义为硬件加速运行。

鱼和熊掌不可兼得，指令复杂度和编程灵活性是两个互反的特征：指令越简单，编程灵活性越高，因此我们才说软件有更高的灵活性；指令越复杂，性能越高，因此而受到的限制越多，只能用于特定场景的应用，其软件灵活性越差。

4.2 如何驾驭大系统

超异构计算本质上是系统芯片SOC（System on Chip），但准确的定义应该是宏系统芯片MSOC（Macro-System on Chip）。站在系统的角度，传统SOC是单系统，而超异构宏系统，即多个系统整合到一起的大系统。

传统的SOC，有一个基于CPU的核心控制程序，来驱动CPU、GPU、外围其他模块以及接口数据IO等的工作，整个系统的运行是集中式管理和控制的。量变到质变，当CPU所要控制的设备越来越多，各自之间的数据和控制交互也越来越多的时候。再加上CPU的性能已经瓶颈，这样，作为负责控制和计算核心的CPU，就成为整个系统里最脆弱的那一个。传统的以CPU控制为中心的架构，变得越来越无法适应以数据计算为中心的算力需求。

超异构计算，由于其规模和复杂度，每个子系统其实就是一个传统SOC级别的系统。需要多个子系统解耦，然后再集成，整个宏系统呈现出分布式系统的特点。这样，不同系统并行不悖的运行，以及系统间如何高效的自适应交互，就成为了挑战。

4.3 如何构建超异构生态

CPU通过标准化的指令集，使得CPU平台的硬件实现和软件编程完全解耦。软件工程师，不需要关注硬件细节，聚焦于软件开发。软件没有了硬件的“约束”，逐渐发展成了一个超级生态。从各种数百万使用者的高级编程语言/编译器，到广泛使用在云计算数据中心、PC机、手机等终端的操作系统以及各种系统框架/开发库，再到各种专业的数据库、中间件，以及云计算基础的虚拟化、容器等。上述这些软件都是基础的支撑软件，是软件的“冰山一角”，而更多的则是各种应用级的软件。系统级和应用级的软件，共同组成了基于CPU的软件超级生态。基于CPU已经构建非常庞大的生态。

基于GPGPU的并行计算编程一直是一件非常复杂的事情。但在NVIDIA的努力以及行业的变化下，GPGPU的生态逐渐发展了起来：

• 一方面，NVIDIA坚持多年，CUDA逐渐变得强大、稳定而易用，集成了众多开发库和强大的工具链，降低了编程的门槛；
• 另一方面，随着AI等算力需求强劲的场景变得越来越多，GPU并行计算的价值凸显，也使得GPU越来越成为AI、数据分析、HPC等场景的首先计算平台。

以AI场景为例，AI-DSA严格来说，目前还没有形成具有“统治力”的平台和生态。开发特定“架构”的AI芯片，再配合特定的驱动，再需要有配套的AI工具链，把算法模型和应用“半自动，半手动”的映射到自己特定架构的AI芯片。如果算法模型发生变化。则需要重新映射，整个过程耗时甚至会超过模型更新的时间。

超异构面临的问题，则更是难上加难。因为超异构本来就是这些处理引擎的集合。超异构可以当做是CPU+GPU+N*(DSA/ASIC)的集合，则所有单处理器引擎遇到的问题，这里都会遇到，工作量和复杂度等挑战都成数量级的提升。

5 软件人员轻松驾驭的算力：基于软硬件融合的超异构计算

经过上述各种分析之后，我们给出面向未来十年的新一代计算架构的一些设计目标——基于软硬件融合架构（CASH，Converged Architecture of Software and Hardware）的超异构计算：

• 性能。让摩尔定律继续，性能持续不断地提升。相比GPGPU，性能再提升100+倍；相比DSA，性能再提升10+倍。
• 资源效率。实现单位晶体管资源消耗下的最极致的性能，极限接近于DSA/ASIC架构的资源效率。
• 灵活性。给开发者呈现出的，是极限接近于CPU的灵活性、通用性及软件可编程性。
• 设计规模。通过软硬件融合的设计理念和系统架构，驾驭10+倍并且仍持续扩大的更大规模设计。
• 架构。基于软硬件融合的超异构计算：CPU + GPU + DSA + 其他各类可能的处理引擎。
• 生态。开放的平台及生态，开放、标准的编程模型和访问接口，融合主流开源软件。

与CPU芯片、GPU芯片、DSA芯片的比较如下表：

 

 

 如何设计一个“价值百万”的总线互联IP

无论是做SOC设计还是FPGA设计，AXI4总线是经常提及的。本系列以AXI4总线为例，来看下在SpinalHDL中AXI4总线互联IP的设计。

关于AXI4总线

关于什么是AXI4总线的定义，网络上相关的文章不胜枚举，也是无论是做FPGA还是ASIC都是必须要了解和掌握的知识，这里不做过多的讲解(小伙伴可以自行下载AMBA总线协议规范或者翻看网络上AXI4总线协议相关文章)。在SpinalHDL中，关于Axi4总线，包含了配置和实现两块内容，其内容均在spinal.lib.bus.amba.axi4 package中。

Axi4总线配置：

 

 

 这里结尾的四个参数值的注意：

• readIssuingCapability：指明AXI4总线读最大支持的指令个数。
• writeIssuingCapability：指明AXI4总线写最大同时支持的指令个数。
• combinedIssuingCapability:其值应不小于前两者，用于在AXI4总线读写地址通道共用的场景。
• readDataReorderingDepth：读乱序传输的深度。

AXI4总线定义为：    

 

 

 AXI4总线定义划分为五个Strema通道：aw，w，b，ar，r。

除了Axi4总线的定义，在SpinalHDL还另外定义了一些Axi4总线的接口变种：

•  Axi4WriteOnly：只有Axi4总线写通道(aw,w,b)的接口。
• Axi4ReadOnly：只有Axi4总线读通道(ar,r)的接口.
• Axi4Shared：Axi4读写地址通道（aw，ar）共用一组信号的接口(arw,w,b,r)。

关于总线互联的设计

凡是设计中用到Axi4总线的设计总离不开总线互联。在Xilinx FPGA使用中，VIvado针对Axi4总线提供了丰富的IP，对于设计带来了不少设计的便利性。然而在Intel系列FPGA中，其推崇自家Avalon总线，相关IP也不尽完善。当我们的设计从一家平台迁移到另一家平台时，便存在严重的设计兼容性问题，况且Xilinx IP对我们来讲属于黑盒，对于了解其设计背后的思想也难以入手。

而在SpinalHDL中针对Axi4总线互联也有相应的实现。不妨以此为蓝本，来学习下其背后设计的思路。

总线互联的逻辑从整体层面上来看并不复杂，其整体上可分为Decoder，Arbiter两大部分：    

 

 

 对于每个slave端口，其在整个互联系统上都会分配一段地址，在互联系统中通过对地址的译码来进行数据流的路由：

• Decoder：负责地址的译码。
• Arbiter：负责进行多路端口的仲裁。

再聚焦到Axi4协议本身，那我们面临的问题就相对来讲比较多了。在Axi4总线中，无论是读还是写，都需要多个通道的协作才能完成，而这其中便牵涉到了诸多问题：

1. Decoder，Arbiter做通道切换的契机选择？
2. 若master端读写访问地址均没有命中任何一个slave端口的处理？
3. readIssuingCapability，writeIssuingCapability如何支持？
4. Arbiter 如何将b，r通道数据路由至正确的端口？

除此之外，针对总线互联这种IP，如何做成参数化的形式在Verilog中也是一个不小的挑战。后续就上述问题来解析SpinalHDL中的设计实现。

 

 

 

参考文献链接

https://mp.weixin.qq.com/s/JqlEJsDXpKjT0NLr3OKlTw

https://mp.weixin.qq.com/s/6Xm4Sk-0Yao84g3cQAG9Qg

https://aijishu.com/a/1060000000254297?register=success