|
Re: [請益] APR 工程師
Nov 10th 2013, 23:24, by realchic
作者realchic (沒有暱稱)
看板Tech_Job
標題Re: [請益] APR 工程師
時間Sun Nov 10 23:24:46 2013
大可叫Digital Designer 自己RTL code完自己去做P&R 再自己去跑Prime time 但可能需要 半年才會做完這整個flow 一家想要賺錢的公司不會做這種傻事，所以會多找個 更懂P&R的人來加入 時程可能只縮短到 三個月 大可叫Analog Designer 自己設計完一顆DDRPHY，然後再自己去畫Layout，清DRC，LVS 但可能需要 整整一年，才畫的完 這時若有個mixed mode Layout老手來幫忙，或許 半年就搞定 Gain出來的時間，就是這間公司未來產品競爭力的所在 工作沒有好或不好，只有你覺得適不適合 做Designer 也好 APR也好 Layout也好，都是一份工作， 都是收入遠大於22K的工作，都是業界很需要的工作 尊重別人的專業，當然...別人也會尊重你的專業 正所謂.....聞道有先後～術業有專攻... ※ 引述《onlykals (相摩)》之銘言： : ※ 引述《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: 1.34.176.202 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:
|
留言列表
留言列表