能否让微处理器过时现象成为历史
——
能否让微处理器过时现象成为历史
在FPGA构造中加入嵌入式软处理器，是一种可有效地解决处理器过时问题的根本且稳健的方案。
设计人员所面临的最大的“过时”问题是微处理器和微控制器更新换代迅速。变化快速的消费类市场以及处理器速度的不断提高,使得处理器的生命周期变得前所未有地短暂，而且经常是在短暂的停产通告之后就中断了生产和供应。此外，在消费类产品中，有时过时现象是故意的，目的是为了推出规划中的平台而鼓励微处理器制造商放弃现有处理器，从而造成一种器件过时的连锁反应。即使对于用“C”代码（即“可移植代码”）编写的设计，也总有一些结构相关的指令和功能会妨碍从过时处理器向下一代器件的转变。制造工艺的改变使这一过程更为困难，因为新工艺制造的器件往往会采用不同的封装形式和I/O布局，从而可能需要对电路板进行重新设计。
在解决过时问题方面，传统方法既耗时耗力且成本高昂，而且无法保护过去的开发投资。与传统方法相比，软处理器内核可提供极具吸引力的替代解决方案。
传统方法的问题
汽车信息设备设计人员所面临的问题是此类问题中最具代表性的。尽管汽车信息设备系统的设计和开发时间已经从五年这样的尺度缩短到两年，但生产过程仍然要持续多年，而且产品的实际寿命则还要长十多年。只要想到汽车中的每个电子控制单元（ECU）都包括至少一个处理器，而一辆汽车可能包含多达60个ECU，我们就可以想象每次有某种处理器在时间相对很短的停产通告后就很快停止供应这种情况会带来多大的麻烦了。
通常设计人员解决处理器过时问题的方案有几种。特定解决方案的适用性依赖于几个因素：应用软件的价值、系统的生命周期以及解决问题所需要的时间和费用。
最激进也最昂贵的解决方案是围绕新的处理器对系统进行重新设计。根据代码的规模，重新设计可能需要耗费数百人年的时间，其中相当大的部分会花在验证和测试阶段。这种典型的“把孩子与洗澡水一起倒掉”的做法不仅损失了调试和优化现有软件时所做的大量投资，而且这样获得的解决方案本身也只能是“暂时较好地满足了要求”。如果系统生命周期较长，那么同样的问题每几年便会重复出现一次。
另一种解决方案是LTB, 即最后一次购买（The Last Time Buy）.表面看起来，这好象是最经济的选择。但问题是这一方法要求必须估计在整个项目的生命周期中需要购买多少产品。如果估计错误，可能会面临更困难的问题，可能会损失更大的投资，即不得不为估计错误付出巨大的代价。
采用新的处理器，并利用软件在新的处理器上模拟已过时的处理器也是一种方法。然而尽管这一概念看起来很有吸引力，并且确实已经有一定的应用历史，但目前其实际应用并没有理论上看起来那么好。这种方法保护了遗留软件，因此整个过程相对便宜和快速。但这种解决方案并非永久性的。如果系统的生命周期很长，那么每隔几年都必须重复开发一种新的解决方案。
更为重要的是，软件仿真本质上是一个串行过程。由于运行仿真过程需要消耗比应用本身多得多的资源和处理能力，因此这种解决方案速度比较慢。经验表明，平均来说执行每条所仿真的过时处理器指令需要大约20个新处理器时钟周期。
此外，仿真还会带来进一步的过时问题，由于用于仿真的处理器本身也会过时，因此可能需要完全重新编写仿真器。
现成商用解决方案仅仅是以一种新问题代替了老的问题。假设我们需要一种处理器，要求有10个UART、一个中断控制器并且可以访问外部闪存模块等功能。虽然有许多现成商用处理器可提供多个UART和其它所需要的外设，但通常他们拥有许多其它系统中用不到的外设。因此，设计人员不仅要为这些额外的外设支付更多的成本，通常还需要小心地将此类处理器中的未使用外设置于安全模式，或者通过软件禁止掉。 禁止掉用不到的外设为软件设计小组带来额外的负担，他们不仅要保证设计中用到的处理器外设正常工作，现在还必须为未用到的处理器外设编写代码。很明显，在这种情况下购买成品解决方案不仅浪费初始成本，还会在设计阶段浪费工程人员的时间。
解决方案：采用软处理器
软处理器解决方案可消除处理器过时问题并保护在遗留代码和开发方面的多年投资。这种新方法就是采用软处理器内核并将其嵌入在FPGA器件中。这样不仅可以将软处理器内核移植到多种FPGA平台，而且还可‘设计’所需要的外设集合来准确满足设计要求，从而避免结构折衷和浪费外设资源。
Xilinx MicroBlaze软处理器可为您提供不同方法的灵活性。首先可以从处理器内核开始，构建能够准确满足设计需要的外设集合。由于只需要实现自己所需要的部分，因此避免了芯片资源浪费。因为不需要编写代码来关闭/禁止不需要的处理器功能，因此降低了软件设计复杂性。创建专用处理器配置的工作也成为一项简单的任务，而为了满足技术规格的变化专用处理器配置随时可能需要改变。
即使在实际应用五到六年后，连FPGA硬件本身可能也已经接近其生命期的终点时，只需要简单的利用同样的C代码将软处理器内核移植到新的FPGA硬件中就可以了。硬件平台或许需要一定的PCB修改，但遗留下的代码仍然是可用的，不需要修改。
Xilinx公司同时提供32位MicroBlaze软处理器内核和8位PicoBlaze软件内核。PicoBlaze处理器运行速度为116 MHz，但占用芯片面积很小，仅需要35个可配置逻辑模块（CLBs）。（参看图1）
图1，Xilinx PicoBlaze和MicroBlaze软件处理器性能定位
MicroBlaze 32位软处理芯核运行速度为150 MHz，性能达100 D-MIPS。采用RISC架构和哈佛结构的独立32位指令和数据总线，可以全速度执行存储在片上存储器和外部存储器中的程序并访问其中的数据。支持CoreConnect总线的标准外设集合为MicroBlaze设计人员提供了兼容性和重利用能力。
开发工具支持
Xilinx及其分销合作伙伴提供包括软处理核心和标准外设集合在内的Xilinx嵌入式开发套件（EDK）。该套件包括基于GNU的全套软件工具，包括编译器、汇编器、调试器和链接器。Xilinx及其分销合作伙伴提供的MicroBlaze EDK还包括支持Virtex-E、 Virtex-II、Spartan-II和Spartan-IIE 系列FPGA的开发板。
设计人员所面临的最大的“过时”问题是微处理器和微控制器更新换代迅速。变化快速的消费类市场以及处理器速度的不断提高,使得处理器的生命周期变得前所未有地短暂，而且经常是在短暂的停产通告之后就中断了生产和供应。此外，在消费类产品中，有时过时现象是故意的，目的是为了推出规划中的平台而鼓励微处理器制造商放弃现有处理器，从而造成一种器件过时的连锁反应。即使对于用“C”代码（即“可移植代码”）编写的设计，也总有一些结构相关的指令和功能会妨碍从过时处理器向下一代器件的转变。制造工艺的改变使这一过程更为困难，因为新工艺制造的器件往往会采用不同的封装形式和I/O布局，从而可能需要对电路板进行重新设计。
在解决过时问题方面，传统方法既耗时耗力且成本高昂，而且无法保护过去的开发投资。与传统方法相比，软处理器内核可提供极具吸引力的替代解决方案。
传统方法的问题
汽车信息设备设计人员所面临的问题是此类问题中最具代表性的。尽管汽车信息设备系统的设计和开发时间已经从五年这样的尺度缩短到两年，但生产过程仍然要持续多年，而且产品的实际寿命则还要长十多年。只要想到汽车中的每个电子控制单元（ECU）都包括至少一个处理器，而一辆汽车可能包含多达60个ECU，我们就可以想象每次有某种处理器在时间相对很短的停产通告后就很快停止供应这种情况会带来多大的麻烦了。
通常设计人员解决处理器过时问题的方案有几种。特定解决方案的适用性依赖于几个因素：应用软件的价值、系统的生命周期以及解决问题所需要的时间和费用。
最激进也最昂贵的解决方案是围绕新的处理器对系统进行重新设计。根据代码的规模，重新设计可能需要耗费数百人年的时间，其中相当大的部分会花在验证和测试阶段。这种典型的“把孩子与洗澡水一起倒掉”的做法不仅损失了调试和优化现有软件时所做的大量投资，而且这样获得的解决方案本身也只能是“暂时较好地满足了要求”。如果系统生命周期较长，那么同样的问题每几年便会重复出现一次。
另一种解决方案是LTB, 即最后一次购买（The Last Time Buy）.表面看起来，这好象是最经济的选择。但问题是这一方法要求必须估计在整个项目的生命周期中需要购买多少产品。如果估计错误，可能会面临更困难的问题，可能会损失更大的投资，即不得不为估计错误付出巨大的代价。
采用新的处理器，并利用软件在新的处理器上模拟已过时的处理器也是一种方法。然而尽管这一概念看起来很有吸引力，并且确实已经有一定的应用历史，但目前其实际应用并没有理论上看起来那么好。这种方法保护了遗留软件，因此整个过程相对便宜和快速。但这种解决方案并非永久性的。如果系统的生命周期很长，那么每隔几年都必须重复开发一种新的解决方案。
更为重要的是，软件仿真本质上是一个串行过程。由于运行仿真过程需要消耗比应用本身多得多的资源和处理能力，因此这种解决方案速度比较慢。经验表明，平均来说执行每条所仿真的过时处理器指令需要大约20个新处理器时钟周期。
此外，仿真还会带来进一步的过时问题，由于用于仿真的处理器本身也会过时，因此可能需要完全重新编写仿真器。
现成商用解决方案仅仅是以一种新问题代替了老的问题。假设我们需要一种处理器，要求有10个UART、一个中断控制器并且可以访问外部闪存模块等功能。虽然有许多现成商用处理器可提供多个UART和其它所需要的外设，但通常他们拥有许多其它系统中用不到的外设。因此，设计人员不仅要为这些额外的外设支付更多的成本，通常还需要小心地将此类处理器中的未使用外设置于安全模式，或者通过软件禁止掉。 禁止掉用不到的外设为软件设计小组带来额外的负担，他们不仅要保证设计中用到的处理器外设正常工作，现在还必须为未用到的处理器外设编写代码。很明显，在这种情况下购买成品解决方案不仅浪费初始成本，还会在设计阶段浪费工程人员的时间。
解决方案：采用软处理器
软处理器解决方案可消除处理器过时问题并保护在遗留代码和开发方面的多年投资。这种新方法就是采用软处理器内核并将其嵌入在FPGA器件中。这样不仅可以将软处理器内核移植到多种FPGA平台，而且还可‘设计’所需要的外设集合来准确满足设计要求，从而避免结构折衷和浪费外设资源。
Xilinx MicroBlaze软处理器可为您提供不同方法的灵活性。首先可以从处理器内核开始，构建能够准确满足设计需要的外设集合。由于只需要实现自己所需要的部分，因此避免了芯片资源浪费。因为不需要编写代码来关闭/禁止不需要的处理器功能，因此降低了软件设计复杂性。创建专用处理器配置的工作也成为一项简单的任务，而为了满足技术规格的变化专用处理器配置随时可能需要改变。
即使在实际应用五到六年后，连FPGA硬件本身可能也已经接近其生命期的终点时，只需要简单的利用同样的C代码将软处理器内核移植到新的FPGA硬件中就可以了。硬件平台或许需要一定的PCB修改，但遗留下的代码仍然是可用的，不需要修改。
Xilinx公司同时提供32位MicroBlaze软处理器内核和8位PicoBlaze软件内核。PicoBlaze处理器运行速度为116 MHz，但占用芯片面积很小，仅需要35个可配置逻辑模块（CLBs）。（参看图1）
图1，Xilinx PicoBlaze和MicroBlaze软件处理器性能定位
MicroBlaze 32位软处理芯核运行速度为150 MHz，性能达100 D-MIPS。采用RISC架构和哈佛结构的独立32位指令和数据总线，可以全速度执行存储在片上存储器和外部存储器中的程序并访问其中的数据。支持CoreConnect总线的标准外设集合为MicroBlaze设计人员提供了兼容性和重利用能力。
开发工具支持
Xilinx及其分销合作伙伴提供包括软处理核心和标准外设集合在内的Xilinx嵌入式开发套件（EDK）。该套件包括基于GNU的全套软件工具，包括编译器、汇编器、调试器和链接器。Xilinx及其分销合作伙伴提供的MicroBlaze EDK还包括支持Virtex-E、 Virtex-II、Spartan-II和Spartan-IIE 系列FPGA的开发板。
评论