why use verilator....

今天被問到一個有趣的問題."為什麼要用verilator 來跑模擬呢?".就用以下幾點來回答這個問題好了. Answers: 1. simulation time SystemC(gcc) < Verilog(VCS + PLI) 2. license SystemC(free), Verilog(nc-sim/nc-verilog) 3. library 公司之前的 project 沒有 high level 的 model lib,為了要跟現有的 project 結合,且又要加快驗證流程. 4. dumper 在 SytemC 上寫 dump function 比 Verilog 簡單.可以用 c++ 的語法,做成個class 可重複使用.而 Verilog 則比較困難,還要考慮每個 cycle(timing) 的關係,且 dump waveform 的時間太久.連我自己看 waveform 都要眼花了...XD design flow 大致長這樣,我們會跳過 SystemC 的 cycle accurate time model, 畢竟這跟 RTL 的 verilog 類似, 爾且我們在前端已經做過 TLM 的 verify, 所以更可以確保 RTL 的 Verilog 的正確性, 之後再用 verilator 轉成 SystemC 的 cycle accurate time model 來加速驗證. Refs: Verilog to c++/ SystemC @ Verilator Design Automation Tool from Behavior Level to Transaction Level System Level - SystemC

spirit @ iphone JB case study

有 JB 過 iphone 的人,應該對 spirit 不陌生. 底下就針對 spirit 的 JB flow 做簡易的分析. 在之前的 post IPhone Case Study 有大概介紹過, 如何用 libimobiledevice 來 access iphone 的 file system, 可參考 iphone wiki 是如何使用 MobileDevice. flow charts step1. find top flow

    idevice_get_device_list() //透過'usblib'取得 idevice(iphone) 的位置
    memset()                  //建立個 mem space 給 idevice
    memcpy()                  
    idevice_device_list_free()//free device list
    idevice_new()             //建立 idevice
    time()                    //建立 time stamp
    send_files_thread()       //把 dylib 放到 (idevice)iphone 上
    restore_thread()          //同時 backup (idevice) 的資料
    idevice_free()            //free idevice

step 2. call 'idevice_get_device_list()' @ libimobiledevice 會去 call 'usbmuxd' lib 來取得 dev_list

idevice_error_t idevice_get_device_list(char ***devices, int *count)
{
...
 if (usbmuxd_get_device_list(&dev_list) < 0) {
                debug_info("ERROR: usbmuxd is not running!\n", __func__);
                return IDEVICE_E_NO_DEVICE;
        }
...

        for (i = 0; dev_list[i].handle > 0; i++) {
                newlist = realloc(*devices, sizeof(char*) * (newcount+1));
                newlist[newcount++] = strdup(dev_list[i].uuid);
                *devices = newlist;
        }

}

而usbmux為 iphone 跟 pc 間的主要橋樑,流程可參考 usbmuxd 內的 README, 從流程中大概可以知道 usbmuxed 會建立起一組 tcp (ssl) 的連線. 利用這個 channel 來做 synchronous iphone and pc 的動作. 而 channel 間彼此是用 XML Message @ Mac OS X 的 format 來溝通.利用 plist @ python 的 lib 當 XML parser, 把上層的 command 跟底層 Transport layer 的 info 做溝通.

0. iTunes opens a connection to usbmuxd and asks it for device notifications
1. User inserts phone into computer
2. usbmuxd notices the phone and pings it with a version packet
3. phone replies
4. usbmuxd now considers the phone to be connected and tells iTunes
5. iTunes opens another separate connection to usbmuxd and asks it to connect
   to, say, the afc port on the device
6. usbmuxd sends a pseudo-TCP SYN packet to the phone
7. the phone's kernel driver receives the SYN packet and itself opens a
   TCP connection to localhost on the afc port
8. the phone replies with a pseudo-TCP SYN/ACK indicating that the port is open
   and the connection can proceed
7. usbmuxd sends a final ACK to the phone
8. usbmuxd replies to iTunes with a "connection successful" message
9. any data that iTunes writes to the usbmuxd socket from now on is forwarded,
   through pseudo-TCP, through USB, back into a more regular TCP connection to
   localhost, to the afc daemon on the phone, and vice versa

 plist_t n = plist_dict_get_item(props, "DeviceID");
             plist_get_uint_val(n, &val);
             dev->device_id = (uint32_t)val;
//建立到上層的 dev struct 中
  
         n = plist_dict_get_item(props, "ProductID");
         n = plist_dict_get_item(props, "SerialNumber");
         n = plist_dict_get_item(props, "LocationID");

//取得 DeviceID, ProductID...後,利用 SSL 產生 private key 建立加密的socket 連線

step 3. 把 dylib 透過底層的link 加載到 idevice(iphone)的 file system 上. 結論 Level 1. usblib usb connect Level 2. usbmuxd socket connect Level 3. libimobiledevic application/usr space ps: 如果你很懶的話,可以直接用 ubuntu 提供好的 package + source code Refs: iphone wiki libimobiledevic

MESI emulator @ cache protocol

在傳統 single core 下, Cache 只需要考慮 hit/miss 的狀態.但進入 multi cores 的世代, Cache 除了要考慮 hit/miss 之外,還要考慮是否是Share memory part or local(private) memory part. 所以Intel 提出了 MESI 的架構來解決share memory data read/write 的問題. 其實想法很簡單, 如果是share part的部份.有write update 就 broadcast 出去,叫其他的 Cache update, 順便把data 寫回 memory, 如果是 read update 就只要 update 自己本身的 Cache 就好. 底下我們用sample emulator 來實現 MESI 的架構. constrains: CPU 的 schedule 為已知, 避免同時有兩個CPU 的 race condition. cache 架構不是正式的 tags,block, valid. 只有考慮 address 跟 valid 的判斷. 有興趣的人可以抓來玩玩. ^_^ download here. Refs: Memory part 2: CPU caches Cache工作原理-5 Cache Coherence CMP中Cache一致性协议的验证 Optimizing the MESI Cache Coherence Protocol for Multithreaded Applications on Small Symmetric Multiprocessor System Cache is King -or- Things are about to get MESI MESI Cache Coherency Protocol