虛驚一場

5/16是Final Paper上傳的Deadline
在這時間之前, 當然就是將原先審稿的內容
修改成conference的格式
也順便看看還有哪裡需要做補充說明的
所幸當初審稿時已經將全文稍做整理
以至於現在不需要花太多時間整理內容

文句上的修改是免不了的
畢竟這篇paper是登上IEEE這個最高殿堂
怎可隨隨便便用個破爛英文

不過IEEE也十分的貼心
有投過IEEE的人應該也都曉得
他們會提供一個PDF check的服務
也就是說當word轉檔成PDF檔時
可將PDF上傳至檢查的網站
檢查所轉檔的格式是否符合該conference的規格
我算是幸運的
第一次檢查時, 只是因為字型沒有包含進來
所以將相關的字型嵌入
就順利地通過檢查

5/14, 上傳前兩天
想說這次可以不用這麼匆忙地處理文件
於是再重新檢查了一次要上傳的paper
結果發現, 測試結果的圖竟然出錯了
嚇得我趕緊找老闆
這時老闆才發現我的圖有問題
於是叫我趕快再弄個正確的圖出來
並且找出問題發生在哪裡

於是我又回到了研究室
繼續使用著邏輯分析儀
不知道是我不太會用它還是它太笨
每次抓訊號的trigger都不是很準
需要多tune個幾次才會成功
成功抓到後, 將data export出來到mathematica
發現圖還是錯的
這個現象十分的詭異
因為paper裡面的兩張圖, 全是用我所設計的硬體跑出來的
沒理由case-1正確, 而case-2卻錯誤
於是我又試了幾次
結果還是不行

正當所有的方法已經用盡的同時
我發現到一個奇怪的現象
就是步進馬達在運轉的同時
竟然產生之前都沒發生過的"抖動"
而且開始發生怪聲
這是之前都沒發生的
於是我將控制器換一個新的
也是產生相同的狀況
剩下最後一種可能, 就是馬達壞了
於是我換了一顆新的馬達後再進行測試
果然, 是馬達故障了
因為這次, 圖形跑出來是正確的

我跟老闆說馬達故障的事
他相當難以至信
他覺得馬達是很堅固的東西
沒理由被我用了一年就掛了
但事實就是如此
只能說我太厲害了吧.......
不過換個好方面想
這樣我就有"正當"的理由來解剖這顆壞掉的馬達

當圖換成正確的後, Final Paper也順利上傳
接下來就是準備報告的投影片與演說內容了

等待...

等待的日子總是很難熬的
這點我現在終於明白
但是換個角度想想
上了也不過是順利取得畢業的點數
不上也沒差
反正國內研討會這麼多
隨便找個投就沒問題了
為何還要在意上與不上呢

起初還真的不是很在意
但是越接近錄取日期
還真的越來越在意
甚至於有點歇斯底里
也因為這樣
我找了我的partner學妹一起去拜拜

4/25是審稿結果公布
早在一個多月前
我的一群同學就已經說那天要唱歌慶祝了
我就說"如果我沒上怎麼辦"
大家的說法都是"照唱"
當時我真的無法想像沒上的心情會是怎樣

4/23　23:00
在檢查過SICE網站和收過信後
決定在4/25下午五點前不再收信
以及不看審稿結果
我想讓自己的心情稍微平靜一點
而我在4/25跟學妹去廟裡拜拜
會找她一起去的原因
是因為她通過元智研究所的初試
也希望藉此沾點好運

4/25　21:00
拜完之後回家小睡一下
睡到九點後出門吃晚餐
然而手養的我又連上研討會網站去看審稿結果
結果對我來說是好事
然後馬上聯絡我老闆
在接獲老闆的道賀之後
也準備著晚上夜唱的歌曲

接下來的日子呢
也沒那麼輕鬆
5/16前要上傳Final Paper
要更改一堆格式與設定
在上傳之前
又有了驚人的發現...

緣起

在去年(2007)年底
好不容易完成國科會計劃的報告後
靈機一動想把這計畫翻譯成英文
當此一想法閃過後
我便立即找老闆詢問他的意見
並且告訴他我想投國際研討會的念頭

之後選定了一個日本SICE協會所辦的研討會
SICE在日本算是控制方面最高權威的協會
同時這個研討會是IEEE所贊助
而且研討會的論文將會收錄在IEEE的雜誌中
對我來說　能在IEEE Xplorer中搜尋到自己的論文
也算是一個夢想
因此也開啟了IEEE之旅

在農曆年的前幾天
我除了趕稿外
就是製作替大學部專題上課用的投影片
整個農曆年假期加上寒假
我大概只有一週的休息時間

2008/2/25是截稿日期
在那一週裡
我翻譯的英文完全被老闆打槍
因此又重新用"英文思考"的方式撰寫
寫了修改　修了又修
在這一週內　我每天都陪著太陽起床
到了截稿那一天
終於順利上傳
上傳完成後
才發現截稿日期延後到2008/3/16
感覺這麼拼到底是為了什麼
不過心中的大石總算放了下來

在截稿的期間也發生了一些小插曲
就在原定的截稿日期前一天
實驗結果跑出來的跟演算結果不一樣
這讓我十分緊張
不過還好只是個小問題
順利的解決後就沒問題了

而剩下的時間呢
就是等待...

Altera Quartus II 7.1 與 7.2 在SOPC Builder與NIOS II IDE之差異

Quartus II是Altera所開發的一套EDA工具
基本上它的功能十分強大
當然也是要搭配上它所生產的FPGA

Altera這幾年主打教育界
慢慢地也看到一些成果
目前許多大專院校也漸漸使用Altera的工具進行開發
Altera之所以走紅
除了一開始的行銷策略正確之外
另一方面就是它的EDA工具較具親和力
對於剛接觸這領域的使用者
上手十分容易

既然如此
為何這篇文章會討論Altera的軟體呢
故事是發生在這一個月......

當大家開始接觸到新版本的Quartus II 7.1時
漸漸地也發現7版以後的bug並不少
因此7.1問世沒多久後
就推出了service package供使用者下載修正
但這似乎解決不了少數使用者的問題
因此也在短暫的時間內推出7.2及7.2的sp1與sp2

Quartus II 7.2版可說是一大改進
首先在SOPC Builder部分, 已完全移植到JAVA上
這麼做的原因是NIOS II IDE原本的開發平台Eclipse
原本就屬於JAVA的開發環境
如此一來會讓SOPC的元件與NIOS II IDE的連結性更高
也就能加速整個系統在編譯上的時間

這麼做看起來似乎不錯
那討論的地方又在哪裡??
其實Quartus II從7.0版開始, 就已經慢慢開始導向JAVA開發
還記得小弟在先前寫過一篇"有關7.1版的SOPC Builder "
這時的SOPC Builder就分成新舊兩介面
在舊介面所使用的是延續5.0版後到7.0版前
以SOPC Builder的說法, 舊介面稱為"classic"
直到目前版本, 仍可以使用上述連結內的方法設定新舊介面的選項

不過7.2開始後最大的改變
在於硬體component的資料存放區改變了
早期都是在quartus\sopc_builder\components\
使用7.2的朋友可以仔細觀看
sopc_builder資料夾裡的components這個資料夾已經不見了
再仔細看看
取而代之的是一堆.jar的java壓縮格式
換個方式說
先前以資料夾型式儲存的component
已轉為JAVA的物件使用

這對於使用舊版本的人會有很大的影響嗎???
我不敢說有, 但對我而言, 影響還頗大的

首先, 我是從5.0開始使用到現在
掐指一算, 也有兩年多的歷史
我一直都是在"classic"介面下開發
也早就習慣整個開發流程
但在這中間, 使用了DE2這塊板子
當然Altera也有提供University Program IP Cores
以利使用DE2的使用者開發
但, 就當7.0版的新介面出來後
University Program IP Cores卻無法在Components裡顯示已安裝
也就是可以使用的"綠點"沒有亮
不過說也奇怪
要使用是也可以使用
但將一個component加到system中卻要很長的時間
而且每當重開一次SOPC Builder
reload之前system的資料就變超慢的
不僅浪費時間
在NIOS II IDE build又產生錯誤
不過這個問題若是以"classic"產生的project
到NIOS II IDE build 就不會有問題

另一個就是轉換上的麻煩
如果您是以classic產生的project 要轉成新版本
很容易讓NIOS II IDE無法build
因為新介面並不支援University Program IP Cores
那麼舊介面的7.2可以使用嗎
我這一個月的測試心得是:無法正常使用
即使使用了舊介面, University Program IP Cores還是有問題
而且Altera自從去年7月後就沒有再更新University Program IP Cores
這對DE2使用者而言真是一大損失

這篇文章並不是要抱怨Altera的作風跟X軟一樣
我只是要提出一個想法
工具軟體這種東西, 不是新版本就一定好
而是看自己本身對它的熟悉度與接受度
雖然大家都說Quartus II 7.1很多bug
但目前我使用上沒有這方面的問題
當然7.2也新增了不少功能
不過這些功能對我來說也並非是必要
因此, 升級對我來說, 也並非必要

雖然很笨, 但這一個月來
讓我對Quartus II這個開發工具更為了解
換個方式說, 也算是值得啦
希望大家在使用軟體時能多加考量
以免重蹈小弟的覆轍

Embedded System與System on Chip的差異

這兩個名詞常會讓人搞混
當然不乏許多研究這方面的人士
在此我簡單的將這兩者區分一下

首先,嵌入式系統(Embedded System)
它是一個system
重點是在前面的那個單字embedded
我們要先考慮一件事
既然是嵌入式,那到底要嵌入哪裡?
舉個例來說
手機是最典型的嵌入式系統
這句話就點出這個系統是"嵌入"在手機上
也就是說
一個系統,"嵌入"在某個裝置上
那我們可以說這個裝置是"嵌入式系統"

相對的,"System on Chip"就十分明確
即表示系統是"嵌入"在晶片裡面的
舉個例說,8051就是個"System on Chip"

我們常知道的嵌入式系統
例如手機,數位相機,甚至是一些常見的裝置
那麼像SOC
例如8051,單晶片等等

因此,這兩著最大的差別
就在於一個系統,到底"嵌入"在哪裡
如果是嵌入在一個"裝置",那就是"嵌入式系統"
如果是嵌入在"晶片",那就是SOC

所以,SOC是嵌入式系統的一部分
但不能說嵌入式系統是SOC
這點請各位多多思考

軟體, 硬體, 還是韌體?(下)

首先我們來思考一個問題
如果我們使用的SOC是NIOS II
裡面包含了LCD模組
以及一些簡單的IO
那在使用LCD模組時
我們會如何使用呢

以下是NIOS II裡的一個範例:
void showLCD(unsigned int duty_cycle)
{//Initial LCD
FILE *lcd;
lcd = fopen("/dev/lcd_16207_0", "w");
if (lcd != NULL )
{
fprintf(lcd, "The duty cycle\nis: %d"
, duty_cycle);
}
fclose( lcd );
}

這是在NIOS II 中使用LCD的一個副程式
很顯然的, 它是採用fopen的方式來使用
我們知道利用C語言中所謂的"格式化IO"
基本上都會使用到指標
指標可說是C語言的精神象徵
曾有過一句話"沒學懂指標, 別說你會C語言"
而指標的用意往往是指向記憶體位址

現在問題來了
假如一個SOC的記憶體不大
或者是記憶體尚未規劃
指標可以運作嗎

很遺憾, 這個答案是否定的
因為C語言的指標
是使用在一個已將記憶體規劃完成的系統才能使用
也就是說
當你不清楚你寫的程式是軟體還是韌體時
若貿然的使用指標的方式
很容易就會造成"無法挽救的後果"
也就是Visual C中常出現的"Fatal Error"(強者可能不常出現啦...)
因為它沒辦法去找到相對應的記憶體位址
因此不管怎麼指, 永遠也指不到正確的地方
這一點要特別小心

就算今天系統內並沒有加記憶體
使用以上方式仍能將LCD正確使用
為什麼在NIOS II 中的LCD模組可以用此方法呢
原因在於LCD模組本身就有記憶體了
也就是說當我們利用上述程式碼執行
SOC在判斷上是去LCD模組內的記憶體抓資料
而非其他的記憶體
如此一來也不會造成LCD出現奇怪的文字

這個系列的文章到此接近尾聲
不知各位對程式語言的應用是否有更深一層的了解
因此當各位在撰寫SOC的程式時
一定要考慮到一個問題
你現在所寫的程式到底是軟體, 硬體, 還是韌體
多了這番考量
相信各位在撰寫時
也能慢慢體會這三種微妙的差異

軟體, 硬體, 還是韌體?(中)

要清楚區分SOC的軟體, 硬體
得先從SOC的架構來看
基本而言, SOC的架構可以想像成一個PC
SOC該有的, 基本上PC應該也不會少
PC中, 其架構分為軟體, 硬體, 韌體
SOC也沒有少
因此, 我們可以把架構以圖形的方式來表示:

由上圖中我們可以發現
所謂的韌體部分, 並不是獨立形成一個區塊
而是包含在硬體裡面
這點必須要解釋一下

在SOC裡面, 所謂的韌體是相等於"硬體的初始化程式"
我們知道在硬體之前, 必須要先對它做初始化的動作
就好比一般PC在開機時, BIOS會先自我檢測所有的硬體
在檢測的同時, 也將這些硬體"喚醒(Wake UP)"
也就是等同於告訴它們該準備工作了

一般的韌體是以"組合語言(Assembler)"來撰寫
當然現在很多也是藉由C語言撰寫後, 經由編譯器及組譯器轉成機械語言
再將機械語言存放至ROM裡面
開機的時候, BIOS會先到ROM去讀取初始化資料
如此一來才能將其他硬體喚醒

有了這基本的了解, 再來就是解釋所撰寫的程式是哪一層

以現在的C語言來說, 已經包含了軟體, 硬體及韌體
並不是C語言的能力比較強
而是許多的程式編輯軟體中
已經包括了各種硬體的編譯器及組譯器

換句話說, 不論寫的是硬體軟體, 甚至韌體
都有辦法轉換成該系統的機械語言執行
再加上C語言是大多數設計人員所能接受的語言
因此支援性也越來越廣

在本篇最後, 敝人整理一下這三大部份常用撰寫軟體及撰寫語言:
硬體 : VHDL, Verilog, SystemC, C
韌體 : C, 組合語言(依系統而異)
軟體 : C, JAVA

介紹到此, 是該為本篇下個結論了
當各位在撰寫程式的時候
需要多考量到所寫的程式是軟體還是硬體
因為在程式撰寫的時候, 這是相當重要的關鍵

怎麼說呢? 下一篇會有更深入的探討

軟體, 硬體, 還是韌體?(上)

對於一個工程師而言
寫程式是必經之路
從學校裡學寫C語言開始
就註定這輩子與程式脫離不了關係

學到目前, 本人只會兩種程式語言
一種是C, 另一種則是VHDL
前者相信大家十分熟悉
而後者對它的了解, 我想只有相關人士比較了解

VHDL是一種硬體描述語言
基本上跟所謂的"寫程式"是相同的
只是目的不一樣
C寫好的程式是在windows中執行
VHDL寫好的程式則是以實現一個硬體去執行
同樣是寫程式, 為何兩者差異性這麼大?

隨著SOC的快速竄紅
"跨平台"的特性也日驅顯見
大家都希望只學會一種程式語言就能在任何平台上執行
到目前為止, 這已不是夢想
JAVA成功的跨平台特性已為SOC打開了一扇門
接踵而至地便是大家熟悉的C語言

C語言有多好用?相信對程式設計的初學者並不了解
對它的印象應該也僅限於交作業前一天熬夜趕工的痛苦日子
但對一個SOC來說, C語言可說是它的精神所在
不管是NIOS II, ARM 或是TI的OMAP
都支援C語言的編輯
現在想想, 真有點後悔當初沒將C語言學好
不然的話我應該已在大公司上班了.......

廢話扯到這裡
不知各位看出些端倪了沒
本篇的主題是"軟體, 硬體, 還是韌體?"(先別管上中下...)
相信這三個名詞在計算機概論中都有提過
而在定義上也應該相當的明確
又為何會在這裡再次提出呢?

記得有一天在寫NIOS II 的程式時
老闆突然問我一個問題
"你現在寫的C是硬體還是軟體?"
當下我毫不考慮的回答是軟體
可是我老闆用十分懷疑的眼光看著我
"你確定是軟體嗎?"
我心想, C不就是用來寫軟體的嗎?但我沒答腔

事隔多日, 我才發現為何老闆會問這樣的問題
正如同先前所提的, 跨平台的時代已來臨
C已不僅僅是軟體, 甚至可以設計成硬體
換個方式來說, 我當時的情況, 撰寫的是NIOS II 的程式
那麼C在這裡應該是屬於硬體囉?

看到這裡, 各位是否對SOC中的程式語言感到疑惑呢?
軟體, 硬體, 還是韌體?
讓我們繼續看下去

淺談嵌入式系統(SOC)

嵌入式系統(SOC)算是近幾年來相當熱門的話題
許多人也紛紛朝這方向研究及分析
不過也有大多數的人不得其門而入
在此小弟簡單的介紹一下

要使用SOC之前 我們必須先考量一個問題
我們所建立的SOC功能為何 目的為何
如果說只是單純建立幾個基本正反器
或者是幾個簡單的邏輯閘組成的電路
小弟是認為這用硬體描述語言就可以解決
甚至於買塊麵包板跟IC回來插一插就搞定了
若說用到SOC 有點殺雞焉用牛刀之感
所以確定自己的需求 是相當重要之事

廢話不多說 我們趕快進入SOC的話題吧

SOC 顧名思義就是System on Chip
至於要在一顆chip上建立一個system而言
並不是可以用簡單的HDL就能處理的
我們先思考幾個問題

1. 既然是system 那麼是怎樣的system?
2. 什麼樣的物件(或硬體)算得上on chip?

在system部分分成兩部分

一個是硬體 一個是軟體

在硬體的部份 包含在SOC裡面有許多部份

我們以Altera NIOS II的架構來說(如下圖)

在框框裡面的即為一嵌入式系統

裡頭包含了CPU, Bus, On-Chip Memory 等等

這些全是硬體的部份

也就是說 要建立一個SOC的最基礎

就是要從這裡開始

我們可以這樣想

在框框外是實體的硬體

也就是真正看得見的chip或硬體(如LED, LCD等等)

而要讓它們動作,得靠我們所設計的controller或driver

而這方面的設計,可依我們的需求會有所不同

這也是NIOS II最大的特點

另外我們再來看另一個架構--ARM

這是一個很典型的ARM系統

我相信應該有人發現了幾個問題
首先是系統問題, 似乎ARM的系統遠比NIOS II複雜
且架構也比NIOS II大
感覺ARM的功能性比NIOS II強大
那麼兩者的差別到底在哪裡?

這個問題的解答正是各家SOC不同的地方
撇開CPU的架構而言,另一個差別就在於BUS
NIOS II的BUS名為Avalon Bus
ARM的為AMBA Bus
而ARM的AMBA又分為兩個:AHB和APB
從上圖中我們可以發現
AHB主要是掌管記憶體部分
APB是掌管硬體周邊
在兩個BUS的雙重使用下,可更容易降低CPU的負擔

感覺上在這方面似乎NIOS II的BUS遜色不少
但各位也別忘了,NIOS II的優點在於硬體是客製化的(Custom
也就是說,NIOS II也可以實現雙BUS架構
因此只要是在FPGA內的LE夠的話
想要擴充不是問題

那麼ARM是否就沒有缺點了呢
這個答案是否定的,ARM的缺點就在於硬體的彈性
在NIOS II裡,我們可以依據自己的需求而增加所要的硬體
而在ARM的話,硬體的設計是包好的
也就是說,BUS分成兩條就是兩條
而我們也不能將APB所連接的元件連到AHB上面
所以在限制上,ARM的硬體彈性比NIOS II低

先前說過,SOC分成兩大部分:硬體和軟體
剛剛已經稍微介紹了兩個平台的硬體
接著我們從軟體的角度來分析

首先在NIOS II上面,當硬體架設好後
就是要將軟體運行在所設計的硬體上
在NIOS II裡所採用的是MicroC/OS-II
而ARM上面的OS則可支援很多
例如uCLINUX, WINCE, VxWork等等
這並不是說NIOS II就不支援
只是在porting上比較複雜

另外一提, 在NIOS II上的OS是要自己規劃的
也就是說我們引進了OS的基本函式庫後
在什麼時間該執行哪個TASK是自行設定
這個設定跟一開始在硬體時的設定有關
所以在使用OS上就顯得麻煩了一點
相對於uCLINUX,就有點像是一般安裝LINUX
只要針對自己的硬體,給定相對應的參數即可

有了OS,再來談Application Software
在ARM上面開發軟體確實比NIOS II方便
它就像是一台小型的PC,而我們只需要在PC上安裝開發軟體即可
但在NIOS II上,光是要做一個軟體介面就不是十分容易
因此在軟體部分, ARM略勝NIOS II一籌

說到這裡,相信各位應該對SOC有了基本的認識
其實SOC的平台很多,在此雖然只舉出兩個例子供大家比較
而我們可以在此給兩者做個結論
若各位的設計是比較偏向硬體,可選擇NIOS II
若是偏向軟體,ARM是比較方便
我想這也是為何業界偏好使用ARM來開發商品而不用NIOS II

不過,誰好誰壞,還是看需求為主
這是沒有絕對的
但請記得,SOC的主體架構是相同的

差別只在於CPU與BUS的架構

這才是SOC的靈魂,也是主宰SOC效能的最大主因

參考文件:

1. Nios II Processor Reference Handbook
2. 基於ARM的SOC設計入門

有關7.1版的SOPC Builder

在7.1版的SOPC Builder使用的是新介面
也許先前習慣舊介面(也就是classic)的使用者
會發現有許多的component位置有些許不同
當然如果project是由先前版本建立的話可以選擇"open in classic"
如果要在7.1版中建立而又是以classic的方式開啟
請依照下列步驟設定(os為windows系列)


1.執行 控制台->系統 (或在 我的電腦 點滑鼠右鍵,選 內容 )
2.點 進階 標籤,選擇 環境變數
3.在 系統變數 的框架裡點選 新增
4.在 變數名稱 欄中填入 SOPC_BUILDER_PREVIEW
變數值 填入 0 , 之後按 確定
5.在按一次 確定 後離開
6.重新開啟Quartus II 7.1

此內容翻譯ALTERA的文件,以下為文件資料:
Solution ID: rd05082007_870
Last Modified: Jun 22, 2007
Product Category: Embedded Processors
Product Area: SOPC Builder
Product Sub-area: Other

若想參照原文,請參閱以下網址:
http://www.altera.com/support/kdb/solutions/rd05082007_870.html

以上內容若有錯誤,隨時歡迎各位先進留言更正
Thanks!!!