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 需求部分 对硬件project师提出需求 提供硬件信息，包含芯片所需电源，时钟，控制总线和数据总线信息 避免软件和硬件设计不匹配，方便排查低级错误。 对于FCT需求 帮助MFGproject师确定FCT需求。 提供FCT设计草案。并提供每一个測试环节数据流图，使MFGproject师在了解系统的情况下合理确定FCT需求。
    
3.3 项目中做的不好的地方 3.3.1 support部分 support花费时间较多，眼下已占33%。 个人觉得原因是架构设计时将RTM-DSP定位为黑盒系统，导致没有安排DSPproject师负责。
尽管，以 {MOD}列执行RTM-DSP系统7年时间，说明其足够稳定和可靠。 可是。硬件和APP都有修改。硬件和APP对自己的部分也不是非常熟。出问题后都想从RTM-DSP系统获取信息。 还有，RTM-DSP缺乏对应的測试工具证明自己工作正常。 不应该将RTM-DSP定位为黑盒系统。应该安排DSPproject师负责，降低对RTM-DSP系统猜疑。节省时间和精力，加快进度。 3.3.2 设计部分 尽管和硬件相关项目不太适合使用敏捷开发，可是需求不会100%完整，也不会没有需求变更。 须要借鉴敏捷开发。灵活应对需求变化。 3.3.3 debug部分 缺乏各层通信验证工具 此次因为底层通信涉及L3 L4。验证工具开发平台project师无法独立完毕。 假设可以尽早开发出合适的验证工具，一旦验证通过，一方面能排除平台软件问题，给予APP信心。定位问题时不走错方向，还有一方面平台软件project师可尽早抽出精力做其它部分工作。