IC 設計公司買 IP 的時候要考慮什麼呢？我的朋友 Yiyung 給了我一些忠告. 我怕我很快就會忘光光, 所以編了個口訣來幫助記憶. 這個口訣就叫做 problem.
P – power consumption, price issue. people handles it.
R – reference, 問問用過的人. 對 video IP 又指 reference frame 的數目, 存放方式是 tile 還是 raster scan.
O – 需要 over-clock 嗎？達到我們需要的功能, 需要多少 clock frequency? Open to public SW library?
B – bandwidth, 它需要多少? 能不能配合 bus arbiter.
L – latency, 對外部的記憶體存取需要多少 μsec?
E – error, 發生 error 時怎麼處理？
M – memory size, 它會用到多少 memory, 包括內部的 SRAM.
這兩天在想一個問題, 我們養一個工程師比較划算? 還是買 IP, 不要用工程師比較划算? 這裡面的變數有很多: 1. 工程師的薪水, 2. royalty (授權金), 3. 出貨量, 4. 匯率, 5. IP 授權合約中的 royalty fee 的飽和曲線, 以及上下限在哪裡? 6. 產品毛利等等.
先不考慮合約中的 NRE (Non-Refundable Engineering) 或是頭期款, 也不管第 5、6..等項的影響. 假如美金兌台幣的匯率是 1:30, 工程師的平均月薪是 7 萬 5 台幣, 公司的 overhead 是兩倍, 也就是年薪是月薪的 24 (12×2) 倍. 那麼下表可以速查每一個 IP 的 royalty 是 0.1~0.5 USD, 出貨量每個月 10K~1M 個單位時, license IP 所花的錢, 可以請得起幾位工程師?
| K pcs\USD | 0.1 | 0.2 | 0.3 | 0.4 | 0.5 |
| 10 | 0.2 | 0.4 | 0.6 | 0.8 | 1 |
| 50 | 1 | 2 | 3 | 4 | 5 |
| 100 | 2 | 4 | 6 | 8 | 10 |
| 150 | 3 | 6 | 9 | 12 | 15 |
| 200 | 4 | 8 | 12 | 16 | 20 |
| 300 | 6 | 12 | 18 | 24 | 30 |
| 400 | 8 | 16 | 24 | 32 | 40 |
| 500 | 10 | 20 | 30 | 40 | 50 |
| 750 | 15 | 30 | 45 | 60 | 75 |
| 1000 | 20 | 40 | 60 | 80 | 100 |
當然, 在產品開發初期, 重點是搶 time-to-market 的時間. 不管挖角也好, 買 IP 也好, 都在趕著上市. 只有東西賣出去, 才有損益兩平的機會. 如果一個東西要做 12 人年, 市場有單月 200K 的規模, 花多少錢的 royalty 是划算的? 0.3 USD 嗎? 其實以搶錢的觀點, 花更多錢也是合理的.
關鍵在於本來這個 200K 根本賺不到, 必須等東西做出來. 所以該比較的是頭期款和自行開發的費用, 而是不是 royalty. 而 IP 的廠商本身就是一物多賣, 所以底價應該低於公司自行開發的費用. 當然, 這個技術如果難度很高, 或是歐美日公司的 IP, 所報的價錢難免會高一點.
換個時間點來看, 就算是產品已經量產了, IP 的 royalty 費用仍然可以談到低於自行 maintain 的費用. 更何況當初就沒有投人在開發的話, 合約沒談好才嫌 royalty 貴, 自己想做也來不及了.
因此重點不在於 royalty 的費用倒底可以養幾個工程師, 而是公司多麼善用這些工程師的價值. 假如這些人做完高科技 A 還會做高科技 B, 他們價值絕對高! 根本不需要跟 IP 比價, 儘量養就對了.
可惜人們本身有慣性的, 很多人不想學完這個又學那個. 從客觀的角度來看, 公司並沒有給予終身僱用制度做保障, 或者萬一公司倒了, 那種什麼都做過的履歷表還不一定討喜. 因此叫人不停換專長的事情頗為違反人性.
照理說, 和大家做不一樣的事情才會成功. 所以我對這個標題的結論是: 1. license IP 去. 2. 找到什麼都能做的人, 包養他到退休. 3. 買下有能力的小公司, 雖然沒省到後續的人事費用, 但買到了 time-to-market.
我的 Office for Mac 用起來還 OK, 但是有一件事情非常困擾我. 那就是只要打開 spelling and grammar check, Word 裡面就是滿江紅！而且它建議我改的字, 都是些我不認識的, 只有極少數不會被畫上紅色的波浪底線. 這麼一來, 真正拼錯的字就找不出來了！
我本來以為是字典的問題, 或是語言設定的問題, 又或者是使用者自定字典 (custom dictionary) 引起的? 不過今天我赫然發現, 原來一切都是荷蘭人惹的禍！！！ 我這個 Word 所打開的第一份文件就是荷蘭人寫的, 所以 Word 就自動把荷蘭文寫進 normal.dot. 從此以後, 它就自動以荷蘭文為標準來檢查我的拼字. 這個問題在我 select all –> 選 tool/language/English(US) –> 選 default 之後就測底解決了. 這麼怪異的 bug, 難怪我在網路上都找不到解答！
另外一個發現是我重灌 word press, 也就是我的部落格的時候. 發現 2.5.X 和 2.6.X 都不認識 Windows Vista. 雖然看似安裝起來了, 但是進到 phpMyAdmin 就出不來了. 無奈之下只好去裝 2.4.9 版, 僅僅比 2007 年建部落格時用的 2.4.5 版高級一點點而已. 但 2.4 支持 PHP4, 2.5 支持 PHP5, 2.6 支持 PHP6, 不相容也勉強不來. 此外, 雖然書上書, 安裝部落格的時候, 在 Appserv 這個套件裡面要輸入 Web server 的 IP, 而且 IP = localhost = 127.0.0.1. 但對於 PPPoE 撥接的人可不是這樣.
假設我向中華電信申請了一個固定 IP: 1.2.3.4. 撥接上去之後, PC 看到自己的 IP 並非這個值, 而是內部虛擬的另外一個 IP, 比方說: 9.8.7.6, 所以在 AppServ 裡面固然要填第一個 1.2.3.4 的 IP, 但不要以為 localhost 就是它, localhost 是 9.8.7.6. 如果要進入 phpMyAdmin, 就要指定 9.8.7.6 才對, 我試過用外網的 IP 或是 localhost 都看不到東西.
這樣裝起來之後, 不需要 port forwarding 也可以在本機編輯自己的 blog. 當然, 此時還要執行動態 IP 程式, 先告訴 DNS http://www.cash.idv.tw = 1.2.3.4 才能用 domain name 代替 IP address. 以上就是最近兩三天的新發現, 希望對大家有用.
對了! 以安裝 Apache 的套件來說, Xamp 雖然比較酷炫, 但是 AppServ 還是不錯用. 幸好有這些好心人提供免費軟體, 我們才能省下大把的時間. 雖然利用套件還是有很多要摸索的地方, 但時光若倒退 30 年, 能架 httpd server 的人就是高手高手高高手, 或許可以進 FBI 工作了. 更遑論複雜地多的 blog, 若不是累積眾人的智慧也無法變得如此普及. 往好處想, 我們能享受科技帶來的便利真是幸福～～～
因為最近沒有什麼比較軟的書可以讀了, 又需要用到網路的知識, 所以乾脆把這本讀了 1/3 的書一口氣讀完.
本書對於讀者建立網路的相關觀念很有幫助, 我就舉五個地方來做重點複習.
1 封包的觀念
網路上一筆 http 的 data, 會因為 MTU 或 MSS (maximum segment size) 的限制而切割在不同的 LAN 封包當中. 當路由器對 IP 的大小有所限制, 這些封包還會再切割一下, 並記錄在 IP header 裡面以便重組, 此時 TCP header 算是 IP data 的一部分, 所以 TCP header 可能會和 data 分在不同的 IP packet 裡面. 出了 LAN 之後, MAC address 和 Ethernet 的 preamble, start frame Delimiter, FCS 都沒有用了.
| Preamble | SFD | MAC addr. | IP Header | TCP header | data | FCS |
| MSS (e.g. 切割過的 http data) |
||||||
| 可以打散再重組 | ||||||
| MTU |
||||||
如果用專線連接, 自然就不需要 MAC address, ARP (address resolution protocol) 了.
| flag | HDLC header | PPP header | IP Header | TCP header | data | FCS | flag |
[note] HDLC = high-level data link control
2. 轉址的觀念
無論路由器或是防火牆, 都具有轉址的觀念, 把內部的位置轉換為外部的位置. 那麼轉址的時候要不要轉通訊埠 ( port) 呢?
如果 port 不轉的話, 那麼內部位址和外部位址就只能是一對一了, 因此 port 也是要轉比較好 這麼一來, 雖然網際網路上的 port number 是 80, 但是到了 LAN 的裡面可能就變成 8080.
3. 撥接的觀念
使用電話撥接上網的那個年代, 通常用 PPP (point-to-point protocol) 進行通訊. 到了 ADSL 的時代, 上網的訊號大概經過幾個步驟:
| PC | IP+data | ||
| 路由器 (加 MAC header) | MAC | IP+data | |
| 路由器 (去 MAC header, 加 PPP header) | PPP | IP+data | |
| ADSL modem | ATM cell | ||
| analog | |||
| DSLAM 局端集合式數據機 (DSL acess Multiplexer) | ATM cell | ||
| ATM 網路 | ATM cell | ||
| BAS 寬頻存取 (路由器) | PPP | IP+data | |
| 網際網路 | (MAC) | IP+data | |
如果最後的網路網路換成 ethernet, MAC 才有需要.
ADSL modem 如果兼具 router 功能, 就可以省略掉額外的路由器. 如果家裡只有一台 PC, 那麼可以用橋接式 (bridge) 的 ADSL modem.
撥接的時候, 需要做 user name 和 password 的認證, 此時 PC + TA 數據機和遠端存取伺服器 (RAS) 之間, 就是使用 HDLC + PPP 的方式, 類似專線的連接.
但 ADSL 的認證就不一樣了. 在上面的表格中, RAS 放在 ATM 網路之上, 因此要經過漫長的轉換, 最後又轉回 PPP 才能認證成功. 這個過程叫做 PPPoA (PPP over ATM).
PPPoA 如果遇到橋接式 ADSL 會有點麻煩. 因為密碼認證之後, BAS 才會把全與網址等設定訊息放進 PPP, 因為橋接式是左手進右手出, 所以 PPP 的訊息就直接到了 PC. 此時 PC 需要設定全域的網址, 而且好像得認識 ATM cell.
上述的產品的確存在, 讓 PC 用 USB 連到橋接式的 ADSL modem. 但比較普及的方法是用 PPPoE (PPP over Ethernet). 也就是把 PPP 放進 Ethernet 裡面, 再把 Ethernet 送給 ATM. 至於路由器式的 ADSL modem, PPPoE 就沒有甚麼意義了.
[note] PPP 用來認證與設定網路. 除了 PPP 之外, 設定網路可以用大家熟知的 DHCP.
4. Proxy 的觀念
Proxy 是在 user 端還是伺服器端呢?
放在 user 端的叫做 forward proxy, 用途是減少網路上的資訊量, 但是伺服器端的 cache server 就完全用不到了.
伺服器端為了增加頻寬, 有時候會用多個 cache server 來加速 user 的存取. 但是這些 cache server 的 ip address 可以相同或是不同. 如果 ip address 不同, 則 server name 會相同. 這樣 user 連上 server 的時候, 並不知道自己連上那一個 ip address. 此時會遇到的問題是, 如果 user 正在網上購物, 最後要輸入信用卡的時候, CGI (common gateway interface) 已經換到另外一個 ip address 執行, 可能就會認證失敗.
如果派出一個固定 ip address 當代表註冊到 DNS, 則應該啟用 load balance 的功能, 讓不同的 user 固定存取到最適合的一台 server. 為了避免發生中途換 server 的問題, 只要是同一個事件, 不管 server 多忙, 都不會被切換走.
此外 forward proxy 導致 user 要自己設定 proxy 的訊息, 通常我們在 browser 裡面設定的 proxy 都是 forward proxy. 比方說交大, 可能就會提供一台 proxy server, 要求同學設定到他們的 browser 裡面. 不過設定 forward proxy 這件事並不是人人都會, 為了避免出問題, 所以產生了 reserve proxy.
reserver proxy 有很多方法可以直接連到 web server, 或者說 cache server. 比方說, 它可以偷看 IP 封包, 或者要求在 http 規格中加入 host 的標頭欄位, 如此一來, reserve proxy 就知道哪些 host 可以用外部的加速.
Proxy 放在 user 端, server 端, 甚至是 ISP 端, 或是 CDSP (content delivery service provider) 端都各有利弊.
5. 防火牆的觀念
防火牆的做法可以有很多種, 最常用的一種叫做 "封包過濾".
因為 router 中紀錄的 ip-router 對應表會因日久 (其實只要幾分鐘) 被刪除的關係,假如公司不讓外面的封包進到公司來,公司的 ip 也就連不出去了.
根據 source, destination 的ip 與 port number, 大致就可以設定出防火牆的 rule. 有一個很有趣的問題是, 假如公司設立了 web 網站, 當然希望大家來瀏覽, 所以 web server 可以對外通訊. 但是如果 web server 中毒了, 我們要避免 web server 亂發 connection 要怎麼辦呢?
因為 connection 的建立, 需要在 TCP 的控制位元裡面設定 SYN, ACK 才會開始. 因此第一個動作如果來自外部, 可以視為 user 看公司的網頁. 但是第一個動作是 web server 自己發的, 就應該要攔下來. 這個是我以前沒想過的, 相當有趣.
我們部門本來是做多媒體的, 可是多媒體不是從網路上拿來, 就是有可能再傳到網路上, 所以我們也愈來愈像是在做網路了.
在網路上傳送多媒體, 如果是即時的應用, 就會使用 UDP (user datagram protocol). 一個 UDP 封包最小是 8 bytes (只有 8 bytes header), 最大是 65535 bytes (64KB, 包括 8 byte header). 它的長相如下:
| bits | 0-15 | 16-31 |
| 0 | Source Port Number | Destination Port Number |
| 32 | Length | Checksum |
| 64 | data |
|
Checksum 的部分相當神奇, 根據 IP v4 或是 IP v6 的不同, 它還要想像它前面還有 IP header, 一起做 checksum. 因為想像中的 IP header 並不在 UDP 的協議中, 所以那個想像中的 header 就叫做偽頭 (pseudo header). 顯然地, IP v6 的偽頭比 IP v4 要來得大! 如果不要那麼麻煩去算 checksum, 填 0 也可以, 那就表示 "我沒算 checksum".
如果加上 IP 層的頭, overhead 又多了 20 bytes. 所以原來號稱最大可以傳 65535 bytes, 減去 UDP header 8 bytes 和 IP header 20 bytes, 就剩下 65507 bytes.
| bit offset | 0-3 | 4-7 | 8-15 | 16-18 | 19-31 |
| 0 | Version | Header length | Differentiated Services | Total Length | |
| 32 | Identification | Flags | Fragment Offset | ||
| 64 | Time to Live | Protocol | Header Checksum | ||
| 96 | Source Address | ||||
| 128 | Destination Address | ||||
| 160 | Options ( if Header Length > 5 ) | ||||
| 160 or 192+ | UDP, TCP (for example) | ||||
如果是 TCP 的話, 用來取代 UDP 那個位置. 不過 TCP 光是 header 就有 20 bytes 以上, 幾乎和 IP v4 header 等量齊觀.
MTU (Maximum transmission unit) 又是啥呢? 無論我們選了 UDP 或是 TCP, 對傳輸系統來說, 都是 IP 的封包. MTU 就是能夠傳送最大封包的 size. 比方說 IPv4 建議值是 576 bytes, IPv6 建議值是 1280 bytes. 最大的狀況大概是 Ethernet Jumbo frame 的 9000 bytes, 基本上都不會太大, 連 10 KBytes 都不到.
當然, MTU 設得愈大, 系統就要等更多的 data 才能發送, 造成資料的延遲. 如果 MTU 設得很大, 對 TCP 或許是有意義的, 但是對於 UDP 就有點不知所云了. 畢竟即時和延遲是對立的關係.
[ref]
1. http://en.wikipedia.org/wiki/User_Datagram_Protocol
2. http://en.wikipedia.org/wiki/Maximum_transmission_unit
Cash Chou's Blog 