RTM-DSP项目总结

1.  项目介绍

在NINJA设备上支持RTM-ISDN卡

RTM-ISDN卡硬件组成

主要组成单元

C6415: DSP

PEB383（上图中的PEX8112改为PEB383，因为后者具有NT功能）: PCIE2PCI bridge

PEF22554: FALC E1/T1 framer

LC4256V: CPLD

2. 完成情况及时间

number	item	class	status	date	used
1	RTM-ISDN study	design	finished	9	9
2	RTM-ISDN card platform software design	design	finished	5	5
3	RTM-ISDN setup development environment	coding	finished	1.5	1.5
4	RTM-ISDN card PCIE bridge setting	coding	finished	2	2
5	RTM-ISDN card RTM-DSP loading coding	coding	finished	4	4
6	RTM-ISDN card PCIE bridge bring up	debug	finished	2.5	2.5
7	RTM-ISDN card RTM-DSP loading bring up	debug	finished	2	2
8	RTM-ISDN card host communicate coding	coding	finished	5.5	5.5
9	RTM-ISDN card host communicate debug	debug	finished	8	8
10	RTM-ISDN card new feature for HQA	coding	finished	2	2
11	RTM-ISDN setup DSP Debug environment	debug	finished	2	2
12	RTM-ISDN QuadFALC HQA PRBS test support	support	finished	6	6
13	RTM-ISDN diag and monitor	coding	finished	12	12
14	RTM-ISDN diag and monitor debug support	support	ongoing	5	0
15	RTM-ISDN code rebase	support	finished	3	3
16	RTM-ISDN FCT	coding	finished	12	12
17	NINJA FCT V3.5 debug	debug	ongoing	3	0
18	RTM-ISDN hardware debugging support	support	suspend	10	6
19	RTM-ISDN software debugging support	support	ongoing	10	8

3. 项目总结

3.1 统计

Row Labels	Sum of date
coding	39
debug	17.5
design	14
support	34
Grand Total	104.5

3.2 项目中做的好的地方

3.2.1 design部分

前期design工作很有效果，后期工作都采用design的预设方案。

coding部分和debug部分工作量对比37:17说明了预设方案的成熟与可靠。

架构设计采用五视图方法

系统架构设计中五视图的功能

逻辑架构：关注功能。不仅包括用户可见的功能，也包括一些基础模块以及辅助模块。

开发架构：关注程序包，不仅包括要编写的程序，还包括可以直接使用的第三方SDK或者现成的框架、类库以及开发的系统将运行于其上的系统软件或者中间件。

运行架构：关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。

物理架构：关注‘目标程序及其依赖的运行库和系统软件’最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。

数据架构：关注持久化数据的存储方案，不仅包括实体及其实体关系的数据存储格式，还包括数据传递、数据复制和数据同步等策略。 

平台软件架构中五视图的功能

逻辑架构：关注功能。从需求提炼出平台软件功能，注重功能的逻辑性和完整性。

开发架构：关注模块。分解组合平台软件功能到各个功能模块，注重功能模块间关系，确定开发顺序。

运行架构：关注平台层机制运行时逻辑。

物理架构：关注功能模块和功能模块组成程序包的部署。

数据架构：关注数据的存储方案。

物理架构图，体现功能模块在各个子系统中的部署情况。

RTM-DSP时钟同步机制运行架构

RTM-DSP stream 通信数据架构

RTM-DSP系统的bootup，recover和upgrade逻辑架构

RTM-DSP平台软件开发架构

3.2.2 需求部分

对硬件工程师提出需求

提供硬件信息，包括芯片所需电源，时钟，控制总线和数据总线信息

避免软件和硬件设计不匹配，方便排查低级错误。

对于FCT需求

帮助MFG工程师确定FCT需求。

提供FCT设计草案，并提供每个测试环节数据流图，使MFG工程师在了解系统的情况下合理确定FCT需求。

    

3.3 项目中做的不好的地方

3.3.1 support部分

support花费时间较多，目前已占33%。

个人认为原因是架构设计时将RTM-DSP定位为黑盒系统，导致没有安排DSP工程师负责。

虽然，以色列运行RTM-DSP系统7年时间，说明其足够稳定和可靠。

但是，硬件和APP都有改动，硬件和APP对自己的部分也不是很熟，出问题后都想从RTM-DSP系统获取信息。

还有，RTM-DSP缺乏相应的测试工具证明自己工作正常。

不应该将RTM-DSP定位为黑盒系统，应该安排DSP工程师负责，减少对RTM-DSP系统猜疑，节省时间和精力 ，加快进度 。

3.3.2 设计部分

虽然和硬件相关项目不太适合使用敏捷开发，但是需求不会100%完整，也不会没有需求变更。

需要借鉴敏捷开发，灵活应对需求变化。

3.3.3 debug部分

缺乏各层通信验证工具

此次由于底层通信涉及L3 L4，验证工具开发平台工程师无法独立完成。

如果能够尽早开发出合适的验证工具，一旦验证通过，一方面能排除平台软件问题， 给予APP信心，定位问题时不走错方向 ， 另一方面平台软件工程师可 尽早抽出精力做其他部分工作。