目录
单板项目内部
流程
1）项目经理及成员。 项目立项会 确定项目交付时间。规划时间安排。
2）项目助理。项目名称命名。SVN路径创建。
若新做单板，增加：
3） 硬件设计原理图，配套测试板卡原理图。
4） 软件同步开始了解相关管脚的配置，例如管脚复用，I2C设备地址等，输出对应设计文档说明。输出功能清单。
5）原理图评审
6） layout工程师 绘制layout，
7） 结构工程师结构设计。
若非新单板项目，则直接从如下开始：
3） 物料管理，硬件工程师： BOM表生成。易犯错误，物料选型与设计不符号，例如封装错误，导致不能正常焊接，项目延期。
4） 采购、硬件工程师，国产化确认。
5） 物料管理，销售： 按照销售要求生成销售用BOM 表。并生成报价单。
6） layout，硬件：投板文件，PCB生产
7） 采购 ：同步发起物料采购。物料采购时间跟踪表。
8） 若前期物料错误，则由生产人员发起物料重买流程。
9）重买物料入库后，通知研发助理。并由项目经理申请领取，生产实际领取。
10）采购物料同时，制作线缆人员同步制作测试线缆。至少2套线缆。
11）生产助理 同步打印单板标签。单板标签内容有客户指定与公司内部规则两种。
12）单板生产人员，单板生产，贴标签。
13）软硬件人员： 单板调测。性能压测，高低温压测。
高低温分别保温 2个小时，再测试各项功能，包括内存压测
单板断电，合上温箱，开温箱电源，屏幕上设置温度，-40，然后运行，等温度降。
测试。
单板断电，温度设置85，保温烘干，测试。
14） 软硬件人员： 输出部署、软件测试说明、硬件测试说明文档。
15）硬件、结构： 出三防避让图。刷三防。
16） 软硬件： 三防后功能回归测试。
17） 工程测试人员： 按照软硬件测试 说明测试单板，输出测试报告及环境测试报告。
18） 入库，通知销售走交付。
补充：
1） 研发 同步输出验收文档。
2）研发同步输出接口使用例程，业务流程例程代码。
流程工具及流程图
BOM Management and PCB | Mermaid Chart
过程文档
记录除研发正常输出的常规文档，例如原理图，PCB生产图，钢网等文件之外的。
|-----------|---------|-----------------------------------------------------------------------------------------------------------|
| 文档名称 | 阶段 | 作用 |
| 详细功能清单 | 硬件原理图阶段 | 进度跟踪，任务交接。客户临时提及变更需求跟踪 |
| 软硬件接口设计 | 硬件原理图阶段 | 不是硬件设计，也不是软件设计。而是软件对硬件设计的依赖说明，例如I2C的地址，PHY的地址，GPIO的复用关系。 软件据此整理出DTS文件，采用正向调试，避免反向调试。反向调试即根据单板问题找到最后的配置问题。 |
| 对外接口说明 | 调试阶段 | 例如链接器丝印与软件设备节点的对应，例如网口丝印与ethX的对应。串口丝印、can等对应。 |
| 物料采购表 | 硬件设计中及后 | 跟踪物料的采购进度，明确物料的国产化及替代。 |
| 客户验收文档 | 调试完成后 | 调试完成同步输出客户验收文档，便于后续交付时客户验收。避免临时补写文档时带来的二次测试。 |
| 例程代码及接口文档 | 调试完成后 | 提供客户参考。包括简单的串口等，虽然网上都有例程，但建立自己的例程库才是服务好客户的王道，同时增加各项目的复用。 同时例程代码尽量完全模拟客户的流程，并跑通，进一步关注性能参数。 |
改进问题
1） 物料的封装。由于器件有不同封装，而一个单板物料又比较多，偶发物料封装选择错误，耽误生产进度；有时生产也没发现，问题流转到了研发调试阶段。
2） 配套调试线缆的制作晚。 通常单板已经生产完毕，但配套线缆还未出，需要再花费串行时间制作线缆。
单板项目外部流程
主要包括前期需求沟通、中间需求变动、交付后例程及接口使用说明、联调测试。
对于软件来说：
1） 明确操作系统，国产麒麟，还是ubuntu 22 ，欧拉等等。在某些技术说明文档里面只提及接口，对系统没有明确要求。
a. 以某替代项目为例子，以前为ubuntu 16的版本，目前需要替换，升高到ubuntu 新版本。技术需求里面并没有提给，技术协议里面必须确定好。后续变更带来工作量。
b. 以某国产替代为例子。项目第一批交付为Vxworks，但后续国产要求变更为国产实时系统，这带来了较多工作量。是否第一批交付时就引导客户进行变更? 避免二次开发。
2） 基础软件版本。 例如QT的版本。如果不是能直接安装或者系统自带的。则需要自编译。
3） 工作划分。以昇腾NPU某项目为例。推理功能的实现，某些客户做演示实验，简单的推理功能从华为官方下载，再进一步整合视频的输入，对相关接口流程就不熟悉，这些工作是客户完成，还是谁提供。
即整体工作流程的各个部分。
4）潜在任务。 以某项目为例。提出硬编码，但软件开发任务是否乙方提供未明确。
总体而言，从基础系统到业务流程，大概梳理下，即可了解基本的工作划分。只是确认基本的工作划分，实际交付时，还有额外支持，尤其国产化芯片的使用。
项目边界
每个单板或者整机项目都需要明确硬件及软件边界。硬件边界测试接口的兼容性与稳定性。
软件边界明确业务的输入输出，主要关心实际数据量大小及对硬件的压力、延时。
编码选型
前述博客已有说明，这里我们在实际开发时，对性能即编码延时关注不够，导致在3403上花费了些资源，造成研发资源浪费。后续基于经验，基于SOC编码最大支持能力的说明，即可大概了解其延时情况。
存储性能
NVME盘，虽然PCIE带宽足够，FIO测试的写带宽也超过了客户需求很多，但是文件系统默认格式为EXT4，用户视频流通过用户业务程序写入NVME盘时延时比较大。通过前述博客修改写入方式或者更换文件系统则正常解决。linux 参数众多，具体参数差异在此类项目中具象化了。
端端延时
例如从SDI 输入到显示输出延时，或者从前端视频解码后再输出到屏幕。
1） 桌面显示的影响。可以将桌面去掉，直接采用DRM显示。海思的SDK在这方面做的比较好，即处理后的视频不经过桌面。而我们一些客户基于QT开发，保留桌面，端端延时将此考虑进去。带桌面有200ms延时，不带桌面则更低。
2）GPU显示的影响。例如客户指标：X265， 60FPS RTSP流， 解码时间<30ms。但是实际测试时由于GPU显示没有被启用。导致性能不达标。这主要是由于国产GPU在使用时问题，和客户沟通后，采用GPU渲染显示后，问题解决。
低速端口
有两个项目，串口和can在客户应用时出现问题。主要是外设的工作差异导致SOC异常，本身SOC也有bug，在某些场景下就复现了。如前述博客所示。
这里低速端口很多采用逻辑进行电平转换，可以控制低速接口的通断及解析相关协议。利于规避问题，这在单板设计时为比较好的手段。
当然引入逻辑也可能带来新问题，例如我们SPI 接口引入逻辑。默认的逻辑状态将SPI控制器搞异常。
电源设计
多出现在新手设计单板中。
1） 某项目，NVME盘，1T可以正常上电，PCIE建链正常。但4T不行。由于4T功耗更高，需要电流更大，而单板设计上，整个电源设计链路上某型号芯片，电流上限过低，导致终端NVME盘电流需求高时不能被满足。
2） 某模块，在高温时，压力测试会死机。温度是影响LDO带载能力的关键因素。将原150mA输出的LDO更换为300mA的型号，以在高温下留有充足的电流裕量。
3） 某项目。采用昇腾310P模块。起初正常。后310P模块重新设计，同样的底板电流过冲，导致单板上电即被310p拉死。
端口稳定性
以整板项目为例，常见的PCIE。
其在常温下多次上下电的链路带宽、速率是否与设计一致。低温环境的稳定性。
我们今年的项目吃过一次亏。其实有些客户有上电自检的需求，例如检测硬件的状态，看起来很简单的功能，在此类稳定性上则容易提前发现问题。
PCIE的带宽，310p提供了一个好的参考：例如PCIE 2.0 X8 ，理论带宽4GB/s，而实际只有理论的80%左右。且是最大包32MB的情况下，如果包小，则实际带宽更小，例如512KB时，只有67%。
|-------|-------|
| 包大小 | 实际带宽% |
| 512KB | 67 |
| 1MB | 75 |
| 32MB | 82 |
如果链路与设计不一致，导致整体业务受影响。
LnkSta: Speed 5GT/s (downgraded), Width x8 (downgraded)
ascend-dmi --bw -t h2d -d 0 --et 100
This test will affect the business on this server. To ensure the correctness and accuracy of the test, perform the operation separately.
Do you want to continue?(Y/N)y
Host to Device Test
Device 0: Ascend 310P3.
----------------------------------------------------------------
Size(Bytes) Execute Times Bandwidth(GB/s) Elapsed Time(us)
----------------------------------------------------------------
2 100 0.000106 18.84
4 100 0.000210 19.07
8 100 0.000419 19.07
16 100 0.000839 19.07
32 100 0.001598 20.03
64 100 0.003121 20.50
128 100 0.006468 19.79
256 100 0.012937 19.79
512 100 0.025265 20.27
1024 100 0.050529 20.27
2048 100 0.097613 20.98
4096 100 0.209511 19.55
8192 100 0.409045 20.03
16384 100 0.780903 20.98
32768 100 1.195121 27.42
65536 100 1.696777 38.62
131072 100 2.122609 61.75
262144 100 2.574969 101.80
524288 100 2.714844 193.12
1048576 100 2.997987 349.76
2097152 100 3.138100 668.29
4194304 100 3.212011 1305.82
8388608 100 3.267494 2567.29
16777216 100 3.322885 5048.99
33554432 100 3.346431 10026.93
---------------------------------------------------------------总结
更一步 是对项目的整体把握，即销售与研发的协同，重点项目重点人力。目前有些项目看似重点项目，但实际实施存有大量研发问题，而销售端长期无此项目信息，临时想把此项目推为重点。
公司大了，只有许多年不变的项目；公司小了，各种项目均有，临时突击。或许两者中间才是一个发展壮大的过程。
具体的软件流程实施：通用测试库的建立；测试脚本的建立；例程库的建立。