[轉貼]我要點一塊半的漢堡、可樂加薯條！

我要點一塊半的漢堡、可樂加薯條！
在上個月Scrum Master的課程中，我們的老師巴斯講了以下這個故事：

美國某條公路邊，開了一家小小的漢堡店。店裡就只有一個老闆，負責點餐、也要負責廚房裡做漢堡。有一天早上，漢堡店開門沒多久，一個流浪漢模樣的客人走了進來。店老闆看他一付沒有錢的樣子，正要趕他出門，流浪漢說話了：

「我有錢！我有一塊半！我要點一塊半的漢堡、可樂加薯條！」

店老闆看了看流浪漢，指了指櫃台上的菜單，「Mr. Customer，漢堡全餐有附可樂和薯條，可是全餐要五塊錢哦！你要不要改成單點一個漢堡，只要三塊錢。」

流浪漢好像沒聽到店老闆的話，還是回答：「我有一塊半！我就是要點一塊半的漢堡、可樂加薯條！」

店老闆眉頭一皺，覺得這個流浪漢並不單純。漢堡、可樂加薯條，明明就要五塊錢，他怎麼就是要點一塊半的漢堡、可樂加薯條？如果你是店員，你會怎麼做？

老師要我們分組討論了，身為一位優秀的漢堡店老闆，我們可以用什麼方法，來滿足這位Mr. Customer呢？

有一組說，我們賣他半個漢堡！因為一個漢堡三塊錢，半個漢堡就是一塊半啦！

老師搖搖頭，「不！我要的不是半個漢堡。我要點一塊半的漢堡、可樂加薯條！」

我這一組說，「Mr. Customer，反正你的目的也就是想吃飽，不是嗎？我今天就算你特價，一塊半，薯條可樂吃到飽！好不好？」

老師還是搖搖頭，「不！我要的不是薯條可樂吃到飽。我要點一塊半的漢堡、可樂加薯條！」

另一組說，把他趕出去！這種賠本生意不做了！

老師用力地搖搖頭，「我要點一塊半的漢堡、可樂加薯條！！！」

喂~~~老師你很盧耶，這種客人也太澳客了吧？

「你們想知道，這位漢堡店老闆是怎麼做的嗎？」老師反問。大家也點頭如搗蒜，我們的答案都已經這麼有創意、這麼agile了，還會有什麼更好的答案？

漢堡店老闆的答案很簡單：「No Problem! Mr. Customer!」 轉身就往後頭的廚房去備餐了！

怎麼回事呢？難道是老闆要做慈善事業、賠本生意嗎？

原來，在開店之前，老闆在餐廳後面看到了一隻凍死的松鼠，順手就把松鼠丟到垃圾箱裡。這時，老闆跑去翻垃圾箱。。。

太好了！松鼠還在！

就把松鼠拎起來，剝了皮、剁一剁、煎一煎，松鼠肉漢堡排就好了！(此時，我們每個人的臉上，已充滿了噁心、反胃、想吐的表情...)

老闆再繼續去翻垃圾箱，找到了隔夜丟掉的麵包、薯條，甚至還有喝剩的可樂，拚拚湊湊，OMG，一份漢堡、可樂加薯條就上桌了！

「Mr. Customer! 您的漢堡全餐來了！」

流浪漢付了一塊半，拿起他的松鼠漢堡，大口咬下。。。。

「嗯~~~~ 這個漢堡真好吃啊！」 (我們每個人都快要吐了。。。)

--------------------------------------------------------------------------------

「你們覺得這個流浪漢會發生什麼事？」

食物中毒、挫賽、 嘔吐，各種淒慘的狀況都有人說。雖然，也有人覺得，說不定還好，反正松鼠也已經煎熟了，流浪漢也常常翻垃圾筒的食物吃，抵抗力夠，應該死不了！

「那你們覺得這個店老闆怎麼樣？」

「騙子！」、「黑心！」大家倒是有志一同。

「各位專案經理，大家想一想，你們有沒有做過那一種 scope、schedule 都不可以改變的專案？」

大家默默地點頭。

「而且，還是一個難以在固定時間裡，完成所有需求的專案？」

大家繼續默默地點頭。

「你們會好好地為老板、產品經理、顧客好好地分析 scope、評估時間、以及專案風險嗎？」

「你們還會向老板、產品經理、顧客討論其他的可能性，像是半個漢堡？可樂薯條吃到飽？或者，直接跟老板說，你辦不到，不幹了？」

「或者，你們會說：No Problem，卻跑回去用死松鼠做出 $1.50 的【漢堡全餐】，交給你的老板、你的產品經理、你的 Mr. Customer？」

「你都不會擔心，你的老板、你的產品經理、你的 Mr. Customer，吃了死松鼠做的漢堡，會不會生病嗎？會不會中毒嗎？」

「你們做這樣的專案，跟那漢堡店老闆還不是一樣，都在欺騙你們的 Mr. Customer 嗎？」

--------------------------------------------------------------------------------

其實，在課堂上聽了這個松鼠漢堡的故事，我的心情是五味雜陳的。我承認，我曾經為了『使命必達』，為了準時，為了完成，而做出了這種死松鼠漢堡，不管這種漢堡有沒有人想吃，不管有人吃了會不會有事。看起來，我是交出了成果，但實際上呢？

來把目光放遠一點吧！不要只推眼前的骨牌，不要只會如期如質如預算，不要只為了找點事來做、而硬做了一個產品，要做些對得起自己的事、真正對顧客有價值的事、對組織有意義的事。

讀者，你又有賣過死松鼠漢堡嗎？

後記：查了一下，好像美國人真的有在吃松鼠的。 請自行向孤狗大神查詢 squirrel pie 的圖片與食譜，內容可能令人不悅，莫怪言之不預啊！

**********
作者：喲哪桑
原文請見作者部落格：喲哪桑Speaking之專案工作日誌

[轉貼]基於SystemC/TLM方法學的IP開發及FPGA建模

基於SystemC/TLM方法學的IP開發及FPGA建模

2009-11-11 19:37:46 作者：D.Singh, N.Sharma, V.Upadhvava 來源：意法半導體

　　隨着系統級晶片技術的出現，設計規模正變得越來越大，因而變得非常複雜，同時上市時間也變得更加苛刻。通常RTL已經不足以擔當這一新的角色。 上述這些因素正驅使設計師開發新的方法學，用於複雜IP(硬體和軟體)以及複雜系統的驗證。ST公司建立了一個設計流，它從高級抽象開始，易於將模型寫入 IP的精密周期或RTL模型中。當轉入低級抽象時，建模變得複雜，故IP驗證也複雜。我們的方案最適合於這種應用場景，因為它允許人們在各地相似的環境中 運行相同的測試平台和測試場景，因而允許在整個開發周期裏高效地復用所有的測試範例和環境。
　　在半導體領域，開發產品的第一步就是以高級抽象開發規範的模型，通常用C/C++來實現。這裏，SystemC和C++函式庫提供了很大幫助。它簡化了共存的硬體和軟體設計的概念化。再加上實現事務級模型間對口連接的TLM傳送庫，SystemC加速了整個驗證過程。另一個重要方面是所有不同抽象架構中經過增強的可移植性。同一測試配置可以無縫地用於不同抽象級的設計。
　　本文將討論一種此類的方法學。最終的目標是設計和實現UWBMAC(媒體訪問層)IP。出於架構開發的目的，決定用SystemC來實現整個 IP。還開發了抽象級具有不同程度變化的不同架構。所付出的努力比較少，最後得到的仿真速度很快，軟體的實際編寫也可以在設計周期非常早的階段開始。該 IP的RTL結果被移植到了SPEAr系列的FPGA中。除了ARM內核和相應的一系列IP，SPEAr還提供一個可配置邏輯塊，這為用戶在實現其邏輯功能時提供了無與倫比的靈活性。從而縮短了上市時間，同樣也實現了空前的成本節省。

　　設計開發方法學
　　圖1所示的該方法學實現了開發的內核中的事務級建模(TLM:Transaction-Level Modeling)。TLM是一種對數字系統進行建模的高級方案，這裏將模塊之間的具體通信與功能單元或通信架構的具體實現分離開。把總線(Bus)或FIFO這類通信機制模型化成信道，用SystemC接口類將這些信道提供給模塊和部件。這些信道模型的信令接口 功能將取代事務請求，這將減少具體的低級(Low-Level)信息交換。

　　圖1：IP開發方法學流程。

　　在事務級建模時，
　　*更加注重數據轉移的功能-即轉移的是什麼數據，從那裏來，到那裏去
　　*不太關注實際的實現-即不太關注數據轉移所用的實際協議
　　該方案使得系統設計師的實驗變得更加容易，例如，可以利用不同的總線架構(所有都支持公共的抽象接口)，不一定需要對與任意總線進行交互的模型進行重新編碼，只要這些模型能夠通過公用接口與總線進行交互即可。
　　在我們的方法中，起始點是對整個功能系統平台進行建模。這是利用SystemC並通過scfifo接口實現的。為了描述通信接口間的數據流，採用了各種架構。這些架構基本上都是協議需要遵守的參數和幀格式信息。圍繞IP創建了一個測試環境，環境中開發了測試平台，來傳輸分別來自兩側的輸入，即發送和接收。在這兩種範例中，利用這種配置產生了預期的結果或參考。在抽象層，與平台一起使用來進行修改，快速並有效地做試驗時將變得很容易，不過精度會降低一些。

　　圖中所示為用於開發中下一級輸入的配置平台。這裏的核心思想是確定系統的瓶頸並執行軟硬體劃分。該方案在進行軟硬體劃分方面是有效並安全的，因為平台 提供能夠用來識別出整個系統瓶頸的原始統計信息。該階段中，實現了IP的功能模型，使其具備了具體的接口，並嵌入了功能性。而在軟硬體劃分階段將對該方法 學中所用的方案進行具體化。附加到該平台上的另一個是DMA-PL080的TLM模型，下一步是用MACHWRTL替代整個MACHWSystemC功能 模型，如圖2所示。整個周邊環境是一樣的，因此測試注入與其他步驟中的注入一樣。與之前環境的變化是採用了負責到信號變換的事務處理適配器。由於該系統基於ARM，適配器的書寫必須遵從信號級AHB總線接口。實際上，該平台將相同的環境表征為現實系統，不過與此同時，開始面對仿真性能方面的問題。顯然，我們還不能用該配置來執行廣泛的調試/驗證，不過可以運行簡單的測試(具有較短的仿真時間)。

　　圖2：從SystemCMACHW向VHDLRTLMACHW適配器的轉換。

　　由於在當前仿真環境中發現瓶頸，我們對基於硬體模擬XTREME服務器的平台進行評估，該平台基本提供了硬體所需的FPGA塊，並提供了軟體與 整個環境的無縫集成。基於XTREME服務器中早期平台的移植只需要很少工作量，並且相對於基於ncsim的仿真環境，實現了5倍的仿真速度。很顯然，這 使得我們能夠調試並執行VHDL，RTL設計的驗證，否則將會浪費過多時間。同時，基於Xtreme服務器的平台還提供了同等調試能力。

　　硬體/軟體劃分
　　系統中軟硬體劃分決策是最為重要的一個方面。之所以硬體/軟體劃分變得如此關鍵，是因為如下一些因素，如系統的即時處理需求，應用軟體的存儲限制以及其他因素。許多時候，設計開發階段一些決策依賴於直覺判斷或者先前的經驗。但當某些事情發生錯誤時這將蘊含一個風險。隨着系統複雜度以及流片成本的 增加，這種決策方法可能會鑄成大錯。強調需要一種有助於實現更好軟硬體劃分決策的方法學具有許多原因。
　　在UWBMAC系統開發範例中，具有很多必須很好遵守的時間約束，這是因為應用層完全依賴於空中——即來自射頻天線的全局廣播定時。實現決策的 方案建立在我們從具體的系統級平台的執行中所獲取的經驗。我們能夠分析流水線數據通道中的數據流，能夠有效地發現它們是否將對系統構成任何瓶頸。通常，當系統中的數據流發送時，數據幀必須從MAC發送到PHY，而對於接收，所產生的數據幀則從PHY到MAC，並存入到存儲器中由軟體進行進一步的分析。在仿真場景分析過程中，能夠識別出是否需要在硬體中進行一些協議解析以採取及時的措施。

　　圖3：系統中着重硬體支持需求的應用場景。

　　圖3中詳細給出了一個決策範例。根據協議的需求，接收數據中有一個控制包，它通知下次發送事件的通用定時，即何時發送下一個數據包。考慮到 MAC硬體是一個典型的數據通道，並將控制幀傳送到存儲器中，軟體對控制幀進行處理並決定打開發送窗口。在發送窗口打開出現問題時，用這種方案就能發現瓶頸。系統平台結果被用來確認這一理解，於是能夠做出更好決策來實現效率更高的系統。圖3中的另一個場景顯示了軟硬體劃分後的結果。
　　第一個範例中，當軟體處理控制幀時，全局定時如下：
　　寫視窗程式時間=T+tRP+tPM+tintr+tsw_lat>T+texp，故在系統中，SW沒有對及時打開發送視窗的指令進行寫程式。
　　在第二個範例中，當MACHW處理控制幀時，全局定時為：
　　寫視窗程式時間=T+tprg_winexp，故系統中，HW對及時打開發送視窗的指令進行寫程式。
　　與此同時，現有的SPEAr板起到了很大的幫助作用，因為在板上測出了AES-CCM引擎的性能。因此能夠推斷出硬體中存在AES-CCM，因為AES-CCM軟體算法給不出所需要的性能。

　　挑戰
　　被測設計(DUT)或被測單元(UUT)的測試對任何設計方法學來說都是最關注的一個方面。在開發的初始階段，即架構評估階段，必須需要一個高 性能的性能仿真環境。具有行為功能TLM平台能夠滿足這一需求，並對將要執行的功能進行功能檢查。當進入到低級抽象設計階段時，仿真性能大大降低，這成為有效驗證IP的一個問題。
　　軟硬體的系統級仿真與軟硬體的協同仿真一塊進行。ST有自己的平台，這是一個包含硬體(RTL)的混合平台，軟體利用SystemC書寫(見圖 2)。該平台的瓶頸是環境中所引入IP的RTL，而且注意到這將大大地降低性能。正如預期，這是所遇到的約束，而且對是否能夠比主仿真運行更快的可能性進行了評估。該方案基於Xtreme服務器硬體仿真，使得運行速度至少要比NCSIM仿真快10倍。

　　圖4：配有軟體的Xtreme服務器配置。

　　圖4所示的該技術對第一次仿真特別實用，不需要任何有關環境配置方面的工作量。其概念是在Xtreme的FPGA中運行RTLIP。開始時，引入的時鐘(Clock)為軟體時鐘，但結果相當可喜，還簡化了RTL的系統驗證和調試。配置過程中，整個仿真環境是類似的，僅有的改變是用VHDL，RTL IP替代 SysCIP。試驗結果是仿真速度快了10倍。因此，Xtreme服務器平台滿足了RTL驗證/調試所用平台的需求。最重要的方面是具有與ncsim同等 水平的調適能力。還提供了與SystemC環境的無縫集成。

　　調試功能
　　硬體方面的一個更具挑戰性的問題是調試。當自檢失敗時，就需要一個相關的測試範例。為了驗證該測試範例，在檢查失敗原因時必須檢查所有的主要信號。所以需要對信號進行存放，驗證，從而找出具體的原因。利用基於XTREME服務器的平台可以很容易地執行所有這些功能，無須額外的工作量。通過將實際 硬體移入獨立的FPGA，可以很容易地改善仿真速度，不過這種方法提供的調試功能較少。因此，基於XTREME服務器的平台不僅改善了仿真速度，還能提供 非常好的調試功能。圖5給出了分析結果。

圖5：A）不同平台上的仿真性能。B）不同平台上的調試複雜性。

　　FPGA建模
　　該功能驗證方法學中的下一步是對設計進行實時測試。雖然以高級抽象對硬體進行建模能提供高速仿真，但無法對軟硬體集成中存在的潛在問題進行放大。同樣，利用實際激勵在FPGA上運行設計能夠實現詳盡得多的和更實際的功能覆蓋，還能實現與軟體的早期集成。

　　圖6：一種普通的SPEAr(SPEArHead)SoC架構。

　　SPEAr(結構化的處理增強架構)提供一個強大的數字引擎，能夠以很少的時間和很少投資提供特殊的用戶功能(圖6)。該SoC系列具有大量的功能，包括外設，連通性選擇，以及允許採用定制IP，從而有助於縮短上市時間。SPEAr採用一個或兩個先進的ARM926處理內核，帶16k(數據)和16k(指令)高速緩存，主頻為333MHz(最壞條件)。它還提供600，000門(與ASIC等效)的嵌入式可配置邏輯，還配有支持DDR/DDR2存儲器的存儲器接口，以及一個大型的連通性IP(知識產權)系列。這種強大的配置為當今的設計提供了一站式解決方案，同時，通過利用板上能夠映射SPEAr內部可配置邏輯塊的FPGA，可以將時間和資源需求最小化。

　　圖7：Xtreme服務器箱配置優化。

　　目標IP(UWB-MAC)被分入兩塊SPEAr板：MACRTL被分入一塊板，而將PHY仿真代碼分到另一塊中。利用一塊仿效MAC-PHY 接口的連接板將這兩塊板連接到一起。利用PC上的軟體並通過各自的以太網接口來控制這兩塊板。板上的FPGA有三個接口，分別為AHB，DMA和中斷。
　　定制邏輯(本例中為MACRTL和PHYEmu)與膠合邏輯(連接三個接口所需的邏輯)一道被成功地移植進FPGA。先前開發的軟體在帶有SPEAr的ARM平台上得到成功的運行。集成了相同的測試套件，結果顯示，功能性與其他架構的結果一致。

資料來源:
http://www.eeworld.com.cn/FPGA/2009/1111/article_798_1.html
http://www.eeworld.com.cn/FPGA/2009/1111/article_798_2.html
http://www.eeworld.com.cn/FPGA/2009/1111/article_798_3.html
http://www.eeworld.com.cn/FPGA/2009/1111/article_798_4.html

第六感驚人的潛力

第六感驚人的潛力
Talks Pranav Mistry: The thrilling potential of SixthSense technology



TED大會誕生於1984年，其發起人是里查德·沃曼（Richard Saul Wurman）。TED是一個縮寫，它代表技術（technology），娛樂（entertainment）與設計（design）。2002年起，Chris Anderson[1]接管TED大會。他創立了種子基金會（The Sapling Foundation），TED大會的運行就是由這一非盈利機構做的，每一年的三月在美國彙集眾多科學家、設計師、文學家、音樂家等領域的傑出人物，在TED大會上分享他們關於技術、社會、人的思考和探索。

資料來源:
Filmed Nov 2009;Posted Nov 2009
Talks Pranav Mistry: The thrilling potential of SixthSense technology
TED大會