计算机体系结构的一些总结

1.软件和硬件如同太极中的阴阳元素一样，你中有我，我中有你，不断演化,彼此渗透又隔离，但总体上看，从控制和计算两个主要维度来讲，软件擅长于控制而非计算，硬件则相反，所以，设计系统的一个大的目标就是要让合适的组件做擅长的事情，在这样的系统中，软件就像大脑一样，统筹全局，运筹帷幄，对整个处理器资源统一调配，而且硬件则发挥领域内的计算优势，对各种具体的应用场景进行加速，所以各种各样的处理器就出来了，比如有擅长做视频编解码的VPU，也有擅长做图形处理的GPU，G2D, 适合做矩阵运算的TPU， 还有各种AI加速单元例如NPU等等，这些单元可以提供领域内的专用算例，而用软件提供这些算力是非常困难和低效。 通用算力IP(例如CPU）作为软件的载体，定义则越来越抽象，高层，和灵活。

在消费电子芯片中，软件和硬件的转化经常发生，软件硬化和硬件软化都会遇到。

硬件和软件的关系就像太极的阴阳调和，不知道这里有没有NASH均衡的存在，软件和硬件之间互相对抗，互相合作，最终达到了NASH均衡，这个时候，任何一方的改进都不会导致总体收益的增加，大家画地为界，各自安好，或许，这样才是一个完美的芯片方案吧。

2.关于异常和指令关系的总结

---

3.关于异常和中断

异常处理，包括指令异常和外部中断，是处理器的一项重要技术，在异常事件产生时，用来使处理器转入对异常事件的处理，异常处理是处理器根据内部或外部的异常事件从正常的程序处理转入特定的异常处理程序，引起异常的外部事件包括，外设中断，总线错误，引起异常的内部事件包括：非法指令和非对齐访问等等，还有某些调试或者系统调用指令等产生异常。异常处理机制利用异常向量表跳转到异常服务程序的入口。异常处理的关键是在异常发生时，保存CPU当前指令运行的状态，在退出异常时恢复异常处理前的状态。异常能够在流水线的各个阶段被识别，并使后面的指令不会改变CPU的状态（当然可以改变流水线的状态，但流水线对ISA之上不可见），异常在指令的边界上被处理，即CPU在指令退役时响应异常，并保存退出异常处理时下一跳被执行的指令地址。即使异常指令退休前被识别，异常也要在相应的指令退休时才会被处理。处理器根据异常识别时的指令是否完成决定异常地址寄存器存储哪一条指令的地址，例如，如果异常事件是外部中断服务请求，被中断的指令将正常退休并改变CPU状态，它的下一条指令地址将被保存起来，如果异常是由于访问错误指令引起，因为这条指令不能完成，它将退役但是并不改变CPU的状态，也就是不改变寄存器的值，这条非法指令的地址将被保存在返回寄存器中，如果CPU能够从这次异常中恢复，它将继续执行这条出错的指令，当然非法指令访问多少次都是非法，这个例子对其它异常，比如浮点算法更合适。

异常没有使能寄存器，因此一旦触发异常即可进行响应，但是中断优先级一般高于异常优先级，异常内部也分优先级。

4.对于处理器的设计来讲，实时和非实时的区别在MMU，先有确定性，再有实时性，在存在MMU的场景下，如果发生TLB不命中，需要到内存中查找页表，而且页表会分好多级。总线对内存的访问存在latency以及不确定性，这会导致执行流到底要花多少时间完成任务是不确定的，可能很久，可能永远，虽然概率很小。所以MMU是决定实时性的硬件因素，其次是软件因素，包括操作系统是否支持硬实时，是否支持抢占，等等。

除此之外，现代操作系统中的一些复杂内存管理机制，比如缺页机制，也依赖于MMU，缺页机制会导致MMU有效页面并没有实际的物理存储对应，进而出发新的内存分配，这些时间也是不可预测的，理想情况下，我如果假设有无限的内存，每个页表项都已经分配了物理页框，我们再也不用担心缺页中断。所以，一切的根源，在于MMU提供了灵活的便利性，以及由此灵活性引入的各类OS机制的不确定性，所以，实时系统不能用MMU.

4.关于mass storage和MTP的区别

Melis2.0和melis3.0-c800一直是使用的MSC模式，在PC 访问小机端文件系统的时候，小机端是无法访问本地文件系统的，但是MTP不一样，允许PC和小机端同时访问，因为它多了一个mtp框架。如今大多数手机只给消费者提供MTP模式，少数考虑周全的厂商则会提供MSC、MTP两种模式

4：为什么CPU主频一般都比 FPGA快，但是却说FPGA可以帮助CPU加速？

可以简单的总结为，CPU的时钟利用率不如FPGA高，虽然CPU的时钟更快，但是它多个时钟做一件事，相比于FPGA，一个时钟可以做多件事。FPGA通过堆叠多路并行的硬件完成加速，时钟不是重点。

5.CPU decap操作：

强酸溶液将CPU树脂外壳溶解，即Decap操作

6.OpenGL有软件实现mesa和GPU的实现两种，GPU的实现虽然API一样，但是内部是对不同vendor的GPU进行了封装，比如ARM MALI的OpenGL实现和PowerVR GPU的OpenGL实现，之前写过一些shader的用例，很久了，只是照本宣科的皮毛，突然想到。我可不可以理解成，基于GPU的OpenGL函数内部，有可能是调用 shader程序实现的？shader的程序是GPU上跑的， Opengl的函数 是告诉GPU如何干活,我记得当时的步骤是，在c/c++代码里面，编辑好shader的文本，然后调用一个compile类似的函数，编译这个文本，最后编译结果投给GPU去跑，所以C/C++在这里面的角色只是一个桥梁，实际的工作是shader完成的.c/c++仍然用GCC编译,可以这么认为，你看到的C或者C++ 实际上都是调用OpenGL的API，让GPU如何去干活.

7.分布式系统的定义，若干独立计算机的集合，这些计算机对用户来说就像是单个相关的系统:

 硬件方面，多个机器，机器之间独立,软件方面，用户觉得在和单核系统交互。

8：关于国产自主OS的探讨

 中长期以Linux Kernel为核心

 兼容Android，说明Android那套东西还是保留....

不兼容安卓,参考Meego, Tizen.

高度重视新的OS：Fuchsia（微内核架构)

9：OTA的实现方案

 recovery系统(使用一个裁减过的专门用于OTA的系统）和AB系统（两个系统都是全功能的）l两个方案，实现的时候这两个方案取一个。

AB系统是放在裸分区中的，A和B是一样的地位。

AB系统的话文件系统就是有备份的，recovery系统就没有，recovery系统是增加了一个recovery分区，其中存放的是一个带initramfs的kernel，我们称为recovery系统。

OTA 需要支持升级 rtos，支持升级文件系统中的指定文件，支持 AB 系统切换，AB 系统方案，是将原有的系统 , 增加一份。即 flash 上总共有 AB 两套系统。两套系统互相升级。OTA 时 , 若当前运行的是 A 系统 , 则升级 B 系统 , 升级完成后 , 设置标志 , 重启切换到 B 系统。OTA 时 , 若当前运行的是 B 系统 , 则升级 A 系统 , 升级完成后 , 设置标志 , 重启切换到 A 系统。

10:关于ssh tunnel，ubuntu下载工具gstm

12：一个成熟的AI方案，从Linux迁移到RTOS,会遇到哪些障碍呢？或者说，AI方案对系统平台有哪些差异性需求呢？不同系统，对NPU使用上影响大么？

1.零边界，直接用的RTOS，没有Linux,RTOS需支持大内存分配管理就行，其它好像没啥。水表识别，人形检测，人脸检测，人脸识别，语音识别，空调节能算法等等。

13:争论指令集好坏是一个非常悲哀的事情，他甚至不是几十个操作码，而是80%的核心执行只有6条指令，加载，存储，加法，减法，比较和分支跳转，有了这些，你机会已经覆盖了所有应用场景。以RISCV为例子，jal/jalr, slt/slti/sltu, sub, add, lb/sh/lw, sb/sh/sw全部都定义在RV32I/RV64I(base integer) 中。

14:DRD中有包USB Host，就是EHCI和OHC,还有另外一个USB Device控制器。所以我们的主控一直用的是EHCI， 之前经常说到的弱主机是指DRD里面的EHCI。 我们也有独立于DRD之外的独立的EHCI控制器， usb有多个的时候，单独叫host那些控制器，就是只有ehci和ochi。

15:RTT&Melis上，每一次rt_device_register调用/dev目录下的节点都是一一对应的关系。

rt_device_register line 54, reg 49 devname E.

msh /dev>ls -l
brw-rw-rw- root root 1970-01-01 00:00:00 0000000000B            E
brw-rw-rw- root root 1970-01-01 00:00:00 0000000000B            B
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B v4l-subdev13
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B v4l-subdev12
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B v4l-subdev11
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B v4l-subdev10
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B  v4l-subdev9
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B  v4l-subdev8
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B  v4l-subdev7
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B  v4l-subdev6
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B  v4l-subdev5
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B  v4l-subdev4
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B  v4l-subdev3
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B  v4l-subdev2
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B  v4l-subdev1
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B  v4l-subdev0
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B       video3
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B       video2
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B       video1
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B       video0
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B       media0
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B   sunxi_eise
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B         spi3
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B         spi2
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B         spi1
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B         spi0
crw-rw-rw- root root 1970-01-01 00:00:00 0000000000B         disp
-rw-rw-rw- root root