能否讓微處理器過時現象成為歷史
——
加入技術交流群
能否讓微處理器過時現象成為歷史
在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的開發板。
評論