标签: 架构设计

      流水线，最早为人熟知，起源于十九世纪初的福特汽车工厂，富有远见的福特，改变了那种人围着汽车转、负责各个环节的生产模式，转变成了流动的汽车组装线和固定操作的人员。于是，工厂的一头是不断输入的橡胶和钢铁，工厂的另一头则是一辆辆正在下线的汽车。这种改变，不但提升了效率，更是拉开了工业时代大生产的序幕。      如今， 这种模式常常应用于数字电路的设计之中，与现在流驱动的 FPGA 架构不谋而合。举例来说：某设计输入为 A 种数据流，而输出则是 B 种数据流，其流水架构如下所示：               每个模块只负责处理其中的一部分，这种处理的好处是， 1 、简化设计，每个模块只负责其中的一个功能，便于功能和模块划分。 2 ，时序优化，流水的处理便于进行时序的优化，特别是处理复杂的逻辑，可以通过流水设计，改善关键路径，提升处理频率，并能提升处理性能。      各个流水线之间的连接方式也可通过多种方式，如果是处理的是数据块，流水模块之间可以通过 FIFO 或者 RAM 进行数据暂存的方式进行直接连接、也可以通过寄存器直接透传。也可通过某些支持 brust 传输的常用业界标准总线接口进行 点对点 的互联，例如 AHB ， WISHBONE ， AVALON-ST 等接口，这种设计的优点是标准化，便于模块基于标准接口复用。每个模块的接收接口为从接口（ SLAVE ），而发送接口为主接口（ MASTER ）。 架构流水的好处一目了然，但另一个问题，对于某些设计就需要谨慎处理，那就是 时延 。对于进入流水线的信息 A ，如果接入的流水处理的模块越多，其输出时的时延也越高，因此如对处理时延要要求的设计就需要在架构设计时，谨慎对待添加流水线。架构设计时，可以通过处理各个单元之间的延时估计，从而评估系统的时延，避免最终不能满足时延短的需求，返回来修改架构。 流水架构在另种设计中则无能为力，那就是带反馈的设计，如下图所示：     图中，需要处理模块的输入，需要上一次计算后的结果的值，也就是输出要反馈回设计的输入。例如某帧图像的解压需要解压所后的上一帧的值，才能计算得出。此时，流水的处理就不能使用，若强行添加流水，则输入需等待。          如上图中，如在需反馈的设计中强加流水，则输入信息 Ai 需要等待 Ai-1 处理完毕后，再进行输入，则 处理模块 1 ，就只能等待（空闲）。因此，问题出现了，流水线等待实际上就是其流水处理的的效果没有达到，白白浪费了逻辑和设计。   流水应用在调用式的设计中，可以通过接口与处理流水并行达到。即写入、处理、读出等操作可以做到流水式架构，从而增加处理的能力。 流水是 FPGA 架构设计 中一种常用的手段，通过合理划分流水层次，简化设计，优化时序。同时流水在 模块设计 中也是一种常用的手段和技巧。这将在后续重陆续介绍。，流水本身简单易懂，而真正能在设计中活用，就需要对 FPGA 所处理的业务有着深刻的理解。正如那就话，知晓容易，践行不易，且行且珍惜。

    敏捷开发宣言中，有一条定律是“可以工作的软件胜过面面俱到的文档”。如何定义可可以工作的，这就是需求确定后架构设计的首要问题。而大部分看这句话的同志更喜欢后半句，用于作为不写文档的借口。 FPGA 的架构设计最首先可以确定就是外接接口，就像以前说的，稳定可靠的接口是成功的一半。接口的选择需要考虑几个问题。 1，   有无外部成熟 IP 。一般来说， ALTERA 和 XILINX 都提供大量的接口 IP ，采用这些 IP 能够提升研发进度，但不同 IP 在不同 FPGA 上需要不同 license ，这个需要通过代理商来获得（中国国情，软件是不卖钱的）。 2，   自研接口 IP ，能否满足时间、进度、稳定性、及兼容性的要求。 案例 1 设计一个网络接口在逻辑设计上相对简单，比如 MII 接口等同于 4bit 数据线的 25MHZ 样，而 RGMII 可以使用双沿 125Mhz 的采样专用的双沿采样寄存器完成（使用寄存器原语）。但是如何支持与不同 PHY 连接一个兼容性问题（所谓设计挑 PHY 的问题，这个问题后面详述）。       案例 2:CPU 通过接口连接 FPGA 时，如果 CPU 此时软复位，则有管脚会上拉，此时如果该管脚连接 FPGA 接口是控制信号且控制信号高电平有效，则此时 FPGA 逻辑必然出错。同样 FPGA 在配置时，管教输出高阻，如此时 CPU 上电且板级电路管脚上拉，则同样会导致 CPU 采样出错（误操作的问题）。 不能只是考虑编写 verilog 代码仿真能对就行，接口设计应该站在系统的角度来看问题，问题不是孤立的，还是互相联系。 设计中，如果需要存储大量数据，就需要在外部设计外部存储器，这是因为 FPGA 内部 RAM 的数量是有限的。是采用 SRAM 、 DDR2 、 DDR3 。这就需要综合考虑存储数据大大小，因为 SRAM 的容量也有限，但是其接口简单，实现简单方便，且读取延时较小。 DDR2 、 DDR3 的容量较大，接口复杂，但 FPGA 内部有成熟 IP 可用，但是读取的延时较大，从发起读信号到读回数据一般在十几个时钟周期以上。如果对数据时延有要求，需要上一次存储数据作为下一次使用，且数据量不太大（几百 K 到几兆），则 SRAM 是较好的选择。而其他方面 DDR2/DDR3 是较好的选择。为什么不用 SDRAM 或者 DDR 。这是因为设计完毕，采购会告诉你，市场上这样老的芯片基本都停产了。 FPGA 接口在设计选择的原则就是：能力够用，简单易用。特别值得一提的是高速 SERDES 接口，最好使用厂商给的参考设计，有硬核则不选择软核，测试稳定后，一定要专门的位置约束，避免后面添加的逻辑拥挤后影响到接口时序，也可避免接口设计人员与最终的逻辑设计人员扯皮（不添加过多逻辑，接口是好用的）。一个分析高速 SERDES 的示波器，采样频率至少 20G 甚至更高以上，动辄上百万，出现问题，不一定有硬件条件可调试。 回到开头，如何定义“可用的”设计，稳定我想是前提，而接口的稳定性更是前提的前提。这里稳定包括，满负荷边界测试，量产、环境试验等一系列稳定可靠。而在架构设计中，就选择成熟的接口，能有效的避免后续流程中的问题，从源头保证产品的质量。

芯片系统建模与分析   在最初开始确定一颗芯片的需求之后，需要进行系统分析，确定系统的架构。这个过程的方法，我相信是很多系统架构设计者苦苦思索，一直追求的事情。一般从学习标准开始，了解协议，研究算法，确定整个系统的框架，然后分析各个模块可能存在的行为模式，模块之间可能发生的通信与同步关系。最后逐步落实到可能用以实现该系统的芯片的架构是什么样的。   有很多问题需要在这个过程中，确定下来。如果越精确，对于芯片的设计者来说就越能做出精确无误的，经济实用的芯片。例如，cache需要多大，内存需要如何分布多大的空间，模块之间的互联关系如何，互联关系网络里面的数据流量有多大等等……不是所有的模块都需要互相访问，于是为增加吞吐量，系统分析的过程需要精确地得出哪些模块之间需要互联，否则会多出成倍的互联关系，使得最后系统的实现非常复杂，且面积很大，功耗很大，不可以被市场接受。   但就是这个过程本身要求蛮高，系统架构师设计者们可能都会寻求一些方法来完成。曾经，我也了解过synopsys的类似这方面的系统仿真工具。这样的工具使用的过程，需要基于它已有的模块库来搭建你可能设计出的芯片原型，基于systemC等工具。例如模块库里面内核是ARMXX就选择之，然后matrix是什么version，也选择之，然后有usb之类的模块等等。这样搭建处理的系统，其实有了很多前提条件，就是系统仿真的行为其实是你选择的这些模块的行为的集合体。跟真正你希望设计的系统并不一定能对应上。   那么，用通用的芯片搭建一个系统原型如何。例如，TI的6XXX的芯片如此强大，能用软件实现很多的系统原型机了。这个主意其实比上面那个要接近实际情况很多。但同样的问题是6XXX芯片的内核，例如可以同时发射8条指令，总线，以及他本身芯片所拥有的资源很大程度上确定了这个系统运行的行为模式。当然，确实的一个系统实现后，很多数据已经是可以参考的了，虽然他们存在误差。   所以，在最初的系统分析，架构设计阶段，其实借助与已经存在的仿真工具或者芯片原型机，会获得一些参考数据，但都存在各种误差，例如内核的pipeline不同，中断响应的速度不同，内存访问的速度不同，cache的效率不同等等，误差来自各个方面，精确是很难，只能做个范围。但事实上，我认为这个阶段的评估与分析，确实也不需要特别特别的精确。有一些基础数据做参考即可开始架构设计了。只要不是数量级上的错误就行。那么既然是这样，为什么要花昂贵的代价去购买仿真工具，并花很大的力气在仿真环境上去搭建系统，同样都是成本的。关键是系统架构师是否有足够的经验，知识与技能，包括信心来完成此项工作。   看来这个话题，说起来确实很长。FPGA是否为一个好的方法呢？其实FPGA的验证已经不属于架构设计阶段的内容了，属于芯片验证阶段的内容了。且通常FPGA的作用在于功能验证，性能验证希望在FPGA上做得很完整也是徒劳的。简言之，FPGA上要把完整的复杂的一颗SOC映射上去，可能就做不到；要运行到足够高的频率也存在问题。于是，FPGA能帮助的是已经基本完成设计的芯片的功能验证工作。全系统是不能通过FPGA来得以充分的仿真实现的，这并不是否则FPGA平台在芯片设计和验证过程中的作用，他是不可替代的，但他不是架构设计的工具。   所以，经过几年的学习和尝试，我弄明白了一件事，每个系统设计之初的分析与构建过程，需要的就是你的经验，知识与你自己的建模分析方法，行之有效，且不必付出太大的代价。      

      最新版 Android框架与HMTL5开发平台PhoneGap架构设计与深度定制培训   在软硬整合领域， Android以其对软件和硬件的高度开放性引领了当今的软硬整合潮流，全世界正在进行一场轰轰烈烈的Android运动，Android以不可思议的速度渗透越来越广的领域，Android智能手机、Android智能电视、Android微波炉、Android平板电脑、Android智能机器人、Android车载系统等越来越多的Android产品涌入人们的工作和生活中，自从Google的Android@Home战略发布以来，更是让世界对Android充满了怦然心动的期待，可以预测，未来的家庭智能化和物联网时代将是Android的天下！ 谁，将成为软硬整合时代的新主人？ 谁，将彻底掌握Android从底层开发到框架整合技术在到上层App开发的全部技术？ 谁，将彻底洞悉HTML5的技术源泉和精髓，进而在HTML5游刃有余？   中国电子标准协会 http://www.ways.org.cn 恭喜你，当别人还在雾里看花，你却有机会彻底掌握Android软、硬、云整合技术。 这是一次彻底的Android架构、思想和实战技术的洗礼。 彻底掌握Andorid HAL、Android Runtime、Android Framework、Android Native Service、Android Binder、Android App、Android Testing、HTML5技术的源泉和精髓等核心技术，不仅仅是技术和代码本身，更重要的是背后的设计思想和商业哲学。   聪明如你，请尽快研习。   一、课程特色    贯通Android软硬整合和HTML5端云整合技术整个体系； 全程案例驱动，重在剖析案例代码背后的设计思维和商业密码； 彻底掌握Android HAL的背后的密码； 彻底掌握Android HAL的实现机制和技术 彻底掌握Android Framwork的背后的密码 彻底掌握Android Framwork的设计思维和理念 揭秘Android系统的运行的基石Binder 以Camera实例来彻底剖析Native Service和Binder 彻底实战编写Andorid应用程序的一切技术 掌握HTML5技术的源泉和精髓 二、培训对象 对Android软硬整合感兴趣的人员； 希望迅速了解和掌握Android应用和底层技术的人员； Android底层开发者； Android框架设计和开发者； Android产品架构师； Android系统架构师； Android应用程序开发者； 欲从事HTML5系统工作的人员（浏览器的开发、PhoneGap的的Plugin开发等） 希望从事移动终端开发的爱好者、工程师、程序员、以及相关行业的工程技术人员 培训目标 致力于打造在软硬云整合时代具有独立思考能力和实践能力的高素质IT人才； Android高级工程师 Android移植工程师 Android框架开发工程师 Android项目经理 Android架构师 HTML5系统架构和开发人员 四、学员基础       1) 具有Java基础；       2) 具有C和C++基础更佳；       3）对设计模式有所有了解对提升听课效果会大有裨益；   六、培训方式 本课程共计3天，内容涵盖Android底层、Android HAL、Android Runtime、Android Framework、Android Native Service、Android Binder、Android App开发、Android的Web开发等软硬云整合的的几乎所有核心技术并揭秘HTML5技术的源泉和精髓，致力于打造在软硬云整合时代具有独立思考能力和实践能力的高素质IT人才；授课是以案例驱动为基础重在讲解代码背后的设计思维和商业密码； 七、培训内容     第一天 第1个主题：Android架构揭秘 1,1 Google是如何通过Android支持、掌控全球的硬件厂商和应用程序开发者的？ 1,2 Android控制力的源泉是什么？技术上如何实现？ 1,3 Android的Linux Kernal、HAL、Libararies、Runtime、Application Framework设计的理念和实现技术； 1.4 Android平台与硬件、云的微妙关系；   第2个主题：Android开机流程揭秘 2,1 第一个用户进程剖析； 2,2 ServiceManager与Binder的关系； 2,3 Zygote揭秘及其运作方式； 2,4 Android中的第一个Java进程揭秘，第一个Java进程和ServiceManager的关系及代码实现；   第3个主题：Android中启动一个新的应用程序揭秘 3,1 当我们触摸Android屏幕中Launcher上的一个应用程序的图标的时候到底发生怎样的调用过程？ 3,2 应用程序的执行入口到底在哪里？ 3.3 一个新的Android应用程序的进程到底是怎么产生的？   第4个主题：HAL揭秘 4.1 HAL被加入Android中的真正历史原因分析 4.2 HAL的意外价值揭秘 4.3 HAL的Stub 4.4 hw_module_t与hw_device_t 4.5 C语言如何实现继承来满足HAL Stub的设计目的？包括内存结构分析和代码风格讨论等 4.6 如何避免HAL Stub实现时的Dirty Code？   第5个主题：HAL Stub实战 5.1 用面向对象的思想分析、设计、实现Stub 5.2 hw_module_t的子类和hw_device_t的子类的关系以及这种关系的优势 5.3在结构体中如何实现C函数的调用?hw_module_t的子类在代码中又是如何和hw_device_t的子类交互的？ 5.4 类型转换问题   第6个主题：HAL和Linux Kernel 6.1 HAL Stub访问和控制硬件 6.2 Android下的Linux Kernel剖析 6.3 Android 硬件的Driver 6.4 访问Linux内核空间的Driver   第7个主题：Service与HAL Stub整合 7.1 以面向服务的观点和方式与HAL交互 7.2 Library的中so库文件的类型及C/S结构剖析 7.3 hw_get_module 7.4 获取HAL Stub对象的代码流程剖析 7.5 为何HAL Stub的open方法必须提供supporting API（对设备的操作接口）给runtime；   第8个主题：Service、ServiceManager和Binder交互关系揭秘 8.1 Binder的第一号服务是谁？为何要这样设计和实现？ 8.2 如何编写Service 8.3 新的Service产生与ServiceManager和Binder交互流程 8.4 如何获取一个Service？ 8.5 Binder的生产者与消费者模式剖析     时间 內  容 备注 第二天 第9个主题：Binder与Shared Memory 9.1 Binder源代码剖析 9.2 Shared Memory剖析 9.3 Binder是如何使用共享内存来完成进程间通信的？ 9.4 从代码的角度来分析Binder使用Shared Memory的生产者与消费者模式   第10个主题：Dalvik VM 10.1 Dalvik VM的特点，Dalvik VM和JVM的比较 10.2 Dalvik VM的内存分布及OOM(Out of Memory)的根本原因和解决方案是什么？ 10.3 Preload Classes和 Preload Resources，ClassLoader到底在哪里？ 10.4 Dalvik与Java和C/C++   第11个主题：Android中的JNI编程 11.1 Java调用C/C++ 11.2 JNIEnv、JVM、JObject揭秘 11.3 C/C++创建Java对象、调用Java属性和方法 11.4 JNI中的多线程编程 11.5 Facade Pattern在JNI中绝妙应用剖析 11.6 PnP(Plug and Play)   第12个主题：Android中的NDK编程 11.1 NDK与JNI关系揭秘 11.2 NDK开发的流程 11.3 采用NDK方式开发出的程序安装和运行的内幕 11.4 NDK中的Java与C/C++相互调用 11.5 NDK中的多线程编程 11.6 关于Android软件开发的标准化和可替换性揭秘   第13个主题：SystemServer与Framework中的Service 13.1 Zygote与SystemServer 13.2 SystemServer开启Java世界的过程揭秘 13.3 Android Service和Native Service是如何关联起来的？ 13.4 Android Service与ServiceManager 13.5 如何把自己的服务加入到ServiceManager中？   第14个主题：把Java写的 Service加入到Applciation Framework中 14.1 IInterface与CTS 14.2 Binder 14.3 AIDL 14.4 Java Service与Manager 14.5 SystemServer、ServiceManager   第15个主题：Android框架移植移植时的事件驱动机制 15.1 Android Service是如何应对硬件阻塞的？ 15.2 开辟新的子线程并不断的poll 15.3 Listener注册 15.4 Callback 15.5 Application Framework中的Handler、Message、Looper、MessageQueue、 15.6 事件驱动机制实例   第16个主题：Manager、Service和完整的数据流 16.1，Manager和Service分离的原则 16.2，ANR问题 16.3，阻塞式的操作和非阻塞式操作 16.4，以实例说明Android中的从最底层到最上层的数据流   第17个主题：Android软、硬、云三位一体整合 17.1 从技术角度揭秘云，包括云的关键技术和实现方法 17.2 在Native Service中整合Android与云 17.3 在Application Framework中整合Android与云 17.4 Android软、硬、云三位一体整合，包括模式、策略、实现技术             时间 內  容 备注 第三天 第18个主题：Android Application Framwork和App的关系 18.1 Framework和App的具体关系是什么？ 18.2 Framework和App的交互过程？ 18.3 Framework如何掌控App的？ 18.4 Framework与Android的四大组件；   第19个主题：Android Application Framwork和App的关系 19.1 Framework和App的具体关系是什么？ 19.2 Framework和App的交互过程？ 19.3 Framework如何掌控App的？ 19.4 Framework与Android的四大组件；   第20个主题： Handler、Looper、Message、MessageQueue 20.1. Android的事件驱动模型 20.2. Looper、MessageQueue、Hanlder、Message等源码深度剖析 20.3. Looper、MessageQueue、Hanlder、Message及多线程实战案例 第21主题：AsyncTASK异步线程技术 21.1. 使用AsyncTask的原因及对AsyncTask的思考 21.2. AsyncTask代码示例 21.3. AsyncTask源码剖析   第22个主题：Android测试 22.1.Android代码测试的好处，测试的方式 22.2.JUnit框架解析 22.3.测试用例的生命周期 22.4.自动化测试 22.5.源码剖析   第23个主题：广播接受者BroadcastReceiver，短信***案例（接受到短信后上传到服务器或发送到指定的号码或者发送到指定的邮件中） 23.1.剖析广播接收者，与JMS的比较，广播接受者的IoC原理 23.2.短信监听Android客户端 23.3.服务器端搭建 23.4.通过网络把接收到的短信上传到服务器 23.5.把接收到的短信发送到指定的手机号码或者邮件中 23.6.BroadcastReceiver的的生命周期和注意事项以及5秒钟生命响应时间的解决方案   第24个主题：服务Service，电话***（每次开机的时候自动开机，电话来时录音并上传到服务器） 24.1.详细剖析Service 24.2.构建电话监听的Service 24.3.使用BroadcastReceiver监听开机事件，并在开机时启动电话监听的Service 24.4.上传音频文件到服务器 24.5.关于Android安全体系的思考   第25个主题：ContentProvider背景、用途，如何构建ContentProvider，UriMatcher，ContentUris，对CotentProvider进行单元测试、源代码分析 25.1.ContentProvider背景、用途 25.2.构建ContentProvider的详细步骤 25.3.对URI的彻底剖析 25.4.分析UriMatcher，ContentUris 25.5.对ContentProvider的业务层代码进行单元测试 25.6.ContentProvider的源代码剖析 第26主题：基于通讯录的开发 26.1. 通讯录的数据库和数据表分析 26.2. 通讯录ContentProvider的源码剖析 26.3. 获取所有的联系人信息 26.4.添加联系人 26.5.如何处理添加通讯录记录时的事物问题   第27个主题：断点续传（一）类似迅雷的多线程下载器（适用于任何类型的文件下载） 27.1，多线程下载断点续传原理和流程图 27.2，下载文件时Http协议协议详解 27.3，多线程下载断点续传程序：设计服务端和Android端 27.4，Android端的内容涉及IoC、多线程、SQLite数据库、Handler、Http协议、缓存处理、意外关机时候的处理、编写框架、MVC、Service、Android中的I/O流、代码调试、Activity的生命周期等 27.5，单元测试 27.6，软件调试   第28个主题：断点续传（二）多线程断点文件上传器（适用于任何类型的文件上传） 28.1，断点续传原理和流程图 28.2，上传文件的Http协议详解 28.3，自定义自己的文件传输协议 28.4，服务端程序的编写：文件的下载与实时数据的记录、监听模式、乱码问题的处理、并发问题、黑客安全问题 28.5，客户端程序的编写：Android内存溢出问题，Android中的Socket编程、大文件的传输、大文件传输时候的安全问题 28.6，单元测试 28.7，软件调试 第29个主题：Android客户端表单数据的上传 29.1，上传基本的数据类型 29.2，上传图片等附件 把代码重构为能够上传任意数量的字段和任意数量的附件的工具类   第30个主题：Android中Java与WebView中Javascript相互沟通 30.1，制作Android界面的新大陆 30.2，Java调用Javascript 30.3，Javascript调用Java   第31个主题：浏览器开发和自定义 31.1 浏览器定制和开发的核心原理剖析 31.2 浏览器定制和开发的技术手段剖析 31.3 浏览器定制和开发实战   第32个主题：HTML5时代：Device、Browser、Cloud 32.1  HTML5时代谁最重要？ 32.2  HTML5与Device 32.3  HTML5与Cloud 32.4  什么主导了HTML5时代？   第33个主题：HTML5开发平台----PhoneGap框架的技术基石是什么？ 33,1 使用WebView 33,2 在WebView中使用JavaScript 33.3 创建本地Java API 33.4 使用JavaScriptInterface 33.5 JavaScript调用Java 33.6 Java调用JavaScript 33.7 PhoneGap是如何使用JavaScriptInterface的 第34个主题：PhoneGap的Plugin开发 34.1如何扩展PhoneGap的功能？ 34.2 IPlugin接口 34.3 Proxy-Stub模式在Plugin开发中的应用及价值 34.4 Plugin开发中如何控制硬件厂商和Web开发者 34.5 Plugin核心代码剖析及开发实战