作者onlykals (相摩)
看板Tech_Job
標題Re: [請益] APR 工程師
時間Thu Nov 7 22:04:41 2013
※ 引述《kdy0963 (kdy)》之銘言： : 最近接到立錡的APR工程師面試邀請 : 請問APR工程師就是等於LAYOUT工程師吧? : 想請問一下工作內容以及待遇與未來發展 : 希望給小弟一點意見 先謝了 我想應該是有人誤會cutetoto大推文的意思了... 身為一個鍵盤APR是該跳出來回個文. cutetoto大所謂熟悉後可以做各種design的意思是... 在digital ic 下, 基本上產品別(網通/driver/power)對flow的差異並不大, 當然bottleneck不盡相同, 不過對APR整體上的概念來說是不變的. 這點就跟fully layout比較不同. 反而technology node對APR的影響會比較大. 第二個... APR 很少跳到 frontend... 這倒是真的, 因為專精的東西並不相同, digital RD會專注在電路架構, 以及如何使用HDL語言來實現. APR則會以比較physical的角度來看. stdcell usage, constraint, lib, floorplan, clock tree. 基本上APR不知道RD想要的是什麼, 但是APR要有能力去告訴RD如何才能做到他們要的 以constraint的觀點: case analysis, false path, boundary constraint, clock tree 第三個... APR的發展 APR其實跟CAD並不相同... 但是很多公司是將這兩個職位放在同一個部門的 也許是APR要有能力使用script/perl/tcl等方式去增加他們自己工作效率有關 因為APR會跟Tool比較熟一點. 發展的話, 如果不想只做APR, 基本上可以往front-end CAD, back-end CAD, DFT engineer, 或者Command file方向走. 我自己的見解是... technology node在推進的同時, DRC rule是成倍數在成長的, 所以以後Command file寫得好應該不會餓死 再來erc的check也不會只要求人眼確認了, 若能利用一些通則透過程式去協助判斷, 那寫perc的人... 這邊我語帶保留 XD 至於front-end, back-end CAD原本就是design house建立in house tool重要的人才 我也不認為這些發展會不好 只是歸回現實面, 在台灣的確是RD >> support team, 而CAD又是相對小的pool... so... 有機會當RD還是去當RD吧! 不過當APR應該是不會讓你餓到就是... -- 有時候覺得筆記本就像我們的人生， 縱使荒唐、輕狂、悲傷、喜悅、痛苦在上頭無秩序的散佈，但那又如何？ 一本被寫滿的筆記本至少曾經裝載過感情， 比徒留空白就隨手置於那疊筆記本墳的來的幸運。 --
※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 111.243.146.35
→ sux0116:技術層次似乎較低啊 11/07 22:15
→ wumingxian:發展層面: 從前端要往後端走相對容易，後端要往前端走 11/07 22:21
→ wumingxian:難度很高! 白話點就是，今天design RD想往後端，主管幾 11/07 22:22
→ wumingxian:乎都願意給機會，APR工程師要去前端做design，難如登天 11/07 22:23
→ wumingxian:認識很多design RD對後段CAD甚至APR都略懂，因為碩班就 11/07 22:25
→ wumingxian:有到CIC下線的經驗，但一堆APR工程師搞不懂前端在幹麻! 11/07 22:26
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at fivefilters.org/content-only/faq.php#publishers. Five Filters recommends:
留言列表
留言列表