ESL Design Flow

感覺台灣的 RD 對這塊 "ESL Design Flow "很不重視, 只重視所謂的 "成品" 跟 "Code", 有做出來就好, 不管 Performance 跟 Power issue..., 等到要 Real Time Display or Real Time Work 時候,再來修修改改, 不外乎就加個 counter 或者是訊號亂拉一通, 反正只要能夠 function OK, 這也是為什麼台灣 RD 永遠也沒有做完的一天, 有改不完的 code, 跟燒不完的Rom code, 還有永不止息的SoftWare 戰爭. ESL Design Flow 可參考

System Level - SystemC Eclipse + SystemC + Cygwin

Design Automation Tool from Behavior Level to Transaction Level for Virtual Bus-Based Platforms virtual platform with OpenRisc ESL DESIGN Flow 1.System Golden Model : 當我們的function Check 的比對檔, 至少function 要work 吧. 不然搞什麼IC design 阿. 2. HW Algorithm Model : 利用符合 HW Design 的演算法來做硬體層面的實現, 在現今SOC的世代中, 系統的效能跟功率是很重要的課題, 如何減少Access 的次數 跟有效率的 Target Rate 不僅能簡化 Software 的複雜度,也能讓 PMU , MMU 更有效率. PS: 必須考慮 Communication + Computation Cycle Time 的關係. 3.HW Model : 實現 HW Algorithm 到實際的 "code" , 當然最好加入 Communication 跟 Software 的 issue, 最後要跟 golden 做驗證, 在此之中可加入 Power or Communication Monitor 來做 Performance and Power Estimation Power Monitor power monitor part1 power monitor part2 peak power Communication @ AMBA BUS AMBA 4 ARM AHB Master emulator @ SystemC AHB Slave emulator @ SystemC 4. RTL @ Verilog 等 HW 架構決定後, 開始RTL coding, 這樣可以很清楚的知道 Data Flow 跟 each control Path, 把每個 Time Stage 清楚的描述出來,就可以免去東拉西扯的 Signal 跟模糊不清的 Module Interface, 不然每次要亂七八糟開個 Port 給其他新的 IP, 真是只有 XXX 的想說. 4. GATE @ Verilog 這就要靠 Synthesis 的功力摟,看誰的 Design 夠力還有 constrain 夠好.... 不然 Garbage in = Garbage out...是很嚇人的, 明明就同樣的function code, 用同樣的 tool 為啥別人的就是比較好, 心中只會浮現 XXX PS：小弟對這塊比較不熟XD , PS: 自己有時候也為了趕時間,直接衝 RTL Design, 最後下場當然是 "砍掉重練"....