聯發青春職記|My Days in MediaTek:Part-4

懊悔與遺憾

張懸《關于我愛你》:『我得到的都是僥倖,我失去的都是人生』。長大後才知道講的多麼真實,哪有青春是沒有懊悔與遺憾的?我習慣把自己沒有去做的事情稱為懊悔(主動),結果不如自己預期的事情稱為遺憾(被動)。

懊悔

  • 沒有把握機會增進程式能力、建立軟體工程的觀念、熟習工具
  • 沒有搞清楚自己想要過怎麼樣的生活
  • 沒有有系統地學習投資理財

沒有把握機會增進編程能力、建立軟體工程的觀念、熟習開發工具

我之前看到這句話「如果工作日學習 2 個小時,假日學習 5 個小時,那麼一周就是 20 個小時,堅持一年,大約就是 1000 個小時」,我自己覺得很後悔就是沒有把這些『帶著走』的『編程能力』、『軟體工程的觀念』、『熟習開發工具』培養好。

韌體開發基本上也已經是半個軟體開發,我不但程式能力非常基礎,基本連軟體工程的觀念都沒有。寫程式而言,儘管工作上絕大使用C編程,5G時會碰到CSD在host-side的C++ code,我當時有點抱著,反正多學也用不到的心態,下班自學我反而吃虧,就沒有花時間在基本的程式編寫,想當初我連C++裡vector這種資料結構都不清楚,現在想想真是不寒而慄。然而,程式的技巧是需要累積程式的思維更是要刻意培養,我都沒有好好把握,要是我當初已經有把C++資料結構學到一定程度,之後來德國刷題就不會壓力這麼大。事實上,每一個程式都由一個個片段的代碼(snippet of code)所組成,這些片段看似簡單,不外乎就是if/else判斷、for/while迴圈,然而要確保每個片段都正確,整個程式才會正確,進而整個模組才會正確。我現在喜歡舉的例子就是leetcode 69,看似簡單直覺的binary search要是搞不清楚邊界條件,就會造成overflow或是無限迴圈!所以,務必練習到寫法固定,對自己的代碼才有信心。此外,我也沒有意識到軟體工程觀念的重要性,module、function要怎樣安排整個程式才好維護,在設計程式的時候就應該要考慮到驗證的問題,所謂test-drive design(TDD),怎麼樣的系統架構才是合理的?驗證的流程為什麼是叫Unit Test、Integration Test?

另外,工作中會碰到許多常見的工具,如自動化Python與shell script腳本、版本管理Perforce、CD/CI Tool如Jenkins、Linux command,我許多時候就是會用幾個常用的command,知其然不知其所以然,雖然有自學一陣子Python,但是也都只達到會使用、可維護的程度,並沒有真正獨立開發(畢竟大公司分工細緻,不必要樣樣都會也可以混的好好的)。這些看似無關緊要的軟實力,都是整個職涯專業能力的一部分,應該要都存在自己的專業抽屜中。在這邊我非常推薦MIT的《The Missing Semester of Your CS Education》,裡面很有系統的介紹有哪些『好用』的工具,像是git就是透過用bottom-up的方式來教(什麼是 Git?為什麼要學習它?),雖然上手慢但是觀念建立得很扎實(我自己一開始也貪圖方便只倚賴IDE內建的git,但遇到一些進階的問題牽扯到reset, rebase, merge就覺得很頭痛,後來才痛定思痛花兩天好好學),身為一個敬業的軟體工程師就應該要在意選擇並且會使用能夠增加生產力效率的工具。再舉個例子,我從第二學期修課開始就會把每個程式作業用git作版本管理,我的同學有些人會覺得麻煩沒必要,事實是,好的版本管理不但有助於協作, 更是避免科技債。直到今日,我連自己的履歷都用LaTex編寫並且做版本管理,還可以針對不同公司拉不同branch,完全不需要擔心哪個版本是最新版,哪個版本適用哪個公司的問題!我想就是這些看似一點點的進步,逐漸堆砌成一個獨當一面的工程師!

更多參考:程式設計師的時光傳話筒:過去的我,希望你能夠在工作前學會這 9 件事!

我自己一開始也貪圖方便只倚賴IDE內建的git

沒有搞清楚自己想要過怎麼樣的生活

人生跟考試不一樣,不是選擇題,如果硬要把人生當成一場考試,每個人的考卷也都是獨一無二的,抄別人的答案也沒有任何意義。

沒有有系統地學習投資理財

從出社會到結婚的這段時間,是人生中現金流最充足的時候,我一開始上班的時候有做一些小研究,那個時候也就跟絕大多數的同學一樣,隨便買買賺了就跑,沒有意識到投資是一件長期的事情,也沒有有系統地學習投資,財報要看哪寫指標,投資有什麼標的,最後我的投資程度也就停在國外基金定期定額、台股金融股跟台積聯發(投資理財),直到去年,美股台股創新高,我才意識到時間過很快,如果沒有及早投資就錯過更多機會。

遺憾

難忘

這篇文章寫在離職將近一年半之後,動機是來自於準備亞馬遜的Behavior Question,方便整理自己三年半工作的總結與亮點。發哥每年的打考績(pmd)分成兩個階段,年初的時候會要每個人自己列出目標與工作項目,簡單跟二級主管討論過後才可以送出,年中的時候會有一次更新,年底的時候會要求在期限內完成年度總結的成果,再次跟主管討論,主管會透過每個人的pmd決定出當年的考績,考績分成五個等級(E, I+, I, I-, N)(我忘記最差的是什麼),E代表execellent,I是average,N是請你準備走人,每個人最後只會拿到等級,但等級背後是有分數的,所以同樣是I,也可以從分紅看出來自己的I是不是高分的I,當然這些都是從事後的口耳相傳推敲出來。總之,看是形式的打考績,隨著時間累積,如果沒有有意識的記錄下來,工作時間一久,很容易忘記自己過往到底都在忙什麼,想一想也滿恐怖的,我因為準備申請學校的資料,才有機會在公司期間回顧把2016, 2017, 2018的pmd紀錄,由於我當初沒有全部複製下來,今時今日部分細節只能靠記憶,著實可惜,這也提醒自己紀錄(documentation)的重要性,沒有紀錄,科技債就在無形中累積!PMD的撰寫跟準備BQ基本一樣,首先必須列出自己的工作成果,按照STAR(Situation、Task、Action、Result)原則紀錄,紀錄務必以成果為導向與呈現量化結果,最後再根據成果決定符合哪幾個公司核心價值。聯發科有六大核心價值,亞馬遜則稱為Leadership Principles,洋洋灑灑有21條,基本上把所有優點都寫進去(有時候我有幾點也是互相衝突,像是Frugality跟Insist on the Highest Standards就有種又要馬兒好又要馬兒不吃草的慣老闆既視感)

公司每年都會把一年日曆跟核心價值印成小卡讓可以放在名牌裡面

總之,我準總共整理出來以下的四個亮點:

4G Massive MIMO Feature (4g-mimo)

Situation

  • Customer (Samsung) wants new feature from 4G LTE spec, called Massive MIMO to be supported on their legacy products MediaTek Helio P20, MT6757 (Olympus).
  • The feature was included in the original project and during the development most operator didn’t support this advanced feature during the mass-production.
  • However, by the end of development more and more advanced 4G LTE are supported by vendors and started retest with legacy product. By the time this issue is reported, this project has already been put the project under maintenance status and no feature are developing.
  • 這個問題就是Throughput不達標,跟對比機(高通)與93(MTK下一代),原因是原有的手機沒有針對Massive MIMO的beam-forming做support

Task

  • developed patch for new feature (4G LTE Massive MIMO) with limited HW capability
  • the project was so old that simulation platform is no longer maintained, also no pattern
  • only log analysis
  • target and lab equipment
  • 我當時身為DMRS的module owner,同時也是91, 92 project supporter, 臨時被從5G project內抽離處理這個計畫
  • 第一次的測試地點在大陸,是外場field trial針對Massive MIMO測試,

Action

  • clarify test scenario with customer and field trial tester 由於沒有MTK的RD在現場,只有tester,場景判斷能力有限,所以必須來回與vendor跟客戶釐清場景,確認log是有效的
  • discuss possible solution from algorithm team 跟CSD討論如何辨識到Massive MIMO的場景,CSD提出一個計算DMRS correlation並且卡一個threshold,只要達標就切換場景
  • evaluate HW/FW capability from the given scenario 由於設計的時候沒有這個場景,所以現有HW沒有辦法支持通道估計,必須使用DSP的IMC(inner main core, 這一代DSP總共有三顆架構相似的內核專門供inner運算)去單點計算DMRS,效率很差但是因為HW已經寫死,這是沒有辦法的辦法,我大概評估IMC剩下的MIPS(Million instructions per second),還能夠支援1CC(LTE的最寬載波是20MHz),後來issue就有打到2CC場景,直接time-violation,後來assert掉。
  • implement patch with limited environment (without simulation environment direct to smartphone in emulation mode, (work until 2pm) 當時91都已經量產,基本上UT, IT, Co-Sim環境全部都已不復存,只剩下少數一個量產load有在跑regression,所以最後採取土法煉鋼的作法,直接拿target,開debug mode接JTAG直接單步執行,看到底是死在哪裡,由於manual也是很簡陋,還要請教資深的學長或是參考類似算法在不同module的實作,常常HW或是DSP CR(Control Register) 有沒有下對,現場就assert給你看,有一個晚上為了搞這個離開公司的時候已經超過晚上兩點。
  • reconstruct test environment in internal lab and test and verify the result 再來是在實驗室要找到合用的load,找到搭配的工程機,嘗試重建環境,此時的自己很像是在玩大探險,要在茫茫regression 跟MTBF report中撈到。
  • release patch and analyze the log for bug and improvement for several round。

Result

  • Downlink data rate by 300% (42Mbps) in LTE Massive MIMO feature
  • Release patch on time and new feature is merged to legacy project
  • Customer is satisfied with my patch delivered

符合價值

  • Customer Obsession, Ownership, Frugality, Deliver Results

講起來輕描淡寫,但許多事情都是魔鬼出在細節裡,我特別佩服我的Mentor Ted,他很有實驗精神並且非常有毅力,一起跟他debug到半夜也是很難忘!再補充一點,所謂分析log講起來容易分析起來難,首先先要定位出時間點,然後檢查場景,timing跟freq有沒有估計正確,flow有沒有走對,到量產時期log大部分的filter都被關掉,為了節省功耗。再者同樣的一個功能,今天的解法是用韌體直接吃下來,客戶只知道這個測項有過,並不知道功耗的差異,同一時期高通的對比機在一開始就能夠過,也很有可能來自於他們在設計時就考慮到彈性,而91是聯發科前期的產品,整體的架構並沒有優化,這在後面5G也有做檢討

MediaTek’s first 5G Modem Helio M70 (World’s fastest) development (first-5g)

5G Module Cycle Optimization (5g-opt)

Situation

 After first 5G phone call, the existing code is flexible yet low HW u-rate and high cycle

  • 5G Control Channel code is not optimized, low utilization of hardware DSP
  • We even have several review meeting, my supervisor let me handle this independently
  • The reason is that, in the beginning, we are only aiming at functionality

Task

improving HW u-rate and reduce cycle

Action

  • evaluate the potential optimization in the current HW/FW architecture
  • discuss coordinate with CSD algorithm team, HW designer, Modem Architect
  • review the code module by module , scenario by scenario
  • implement and verify with UT and IT
  • validate the result with phone call test, and measure cycles for improvement
  • independently handle the review process

Result

  • Reduced computation cycle by 72% (less than 1K cycles) in 5G control channel decoding
  • u-rate is high

符合價值

Keysight-MediaTek 5G NR Data Demo Camp in Beijing (5g-onsite)

從軟體開發生命週期(Software Development Life Cycle)回顧我的職涯

  • Requirement analysis
  • Planning
  • Software design such as architectural design
  • Software development
  • Testing
  • Deployment

參考:

https://stackify.com/what-is-sdlc/

https://www.softwaretestinghelp.com/software-development-life-cycle-sdlc/

從抽象概念再探聯發科的創立與成長

https://finance.technews.tw/2020/07/31/mediatek-faced-severe-competition-in-2015/#more-628572

https://corp.mediatek.tw/corporate-social-responsibility/talent/employee-development

聯發青春職記|My Days in MediaTek:Part-4 有 “ 3 則迴響 ”

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s