摘要

最近要把AI 整体自底向上的梳理一遍，同时把自己的知识面好好扩充一下，因此需要整体的看看，主要有哪些东西，并且这些东西，应该从哪些地方去补充知识；

坦白说，这部分跟我自己以往的工作经历差别有点大，从通用服务器芯片的全栈，要转移到AI专用芯片的全栈，这个里面涵盖的知识面可能相对通用服务器要求的更高，所以这里可能近一年需要花比较多的功夫；

---

雄关漫道真如铁，而今迈步从头越

---

背景

在驱动的开发过程中，一般来说会涉及两部分的内存：

• 描述符内存，数据量小，但是会比较频繁的跟CPU进行交互
• 数据内存，数据量大，跟CPU交互的一次较少；

在一般芯片架构设计以及软件设计上，对两者经常会有些特别不一样的处理，比如对于描述符的内存，是否需要IO去识别，并且主动推送到CPU cache中？ 又或者，对于数据内存，是否需要IO标记不冲刷系统SLC？等等，这里根据业务场景，行为模式的不同，会有一些区分；

同时，对于两块内存的申请，内核也会有特别的内存接口申请方式，一般来说，在内核驱动中，针对描述符内存，一般使用dma_alloc_coherent/dma_alloc_noncoherent接口，并且实际上，目前linux内核驱动，默认使用coherent接口，没有对描述符内存允许软件可配使用noncoherent接口；在处理数据内存的时候，一般使用dma_map_single/dma_pool的方式申请，并且可以选择由硬件维护一致性或者软件维护一致性；

摘要

在芯片项目的验证阶段中，主要分为硅前以及硅后两个大的阶段，在不同的阶段，各个团队的验证侧重点略有不同，但是同样的需要保证验证的质量，而验证的质量从验证的完备性去衡量；

而实际操作过程中，会根据芯片自研程度、模块规模、商用化目的、人力投入、职责划分等情况，验证策略会跟随着做出一些适时的调整，最终以在现有条件下达成芯片验证的目的；

在目前大部分芯片项目中，真正核心自研的东西其实并不太多，大部分情况下，更多的是三方集成+自研的模式，所以根据这种情况，项目应该以什么样的策略去应对，这个也是本文想要总结思考的；