Ở hai bài trước, chúng ta đã tìm hiểu về thiết kế vật lý – Physical Design là gì, cũng như các bước trong quy trình thiết kế. Chắc là các bạn đã có một chút khái niệm cũng như hình dung rõ ràng hơn về công việc này rồi đúng không? Hôm nay chúng ta sẽ đổi gió một tí, cùng xem một ngày làm việc của kỹ sư PD sẽ diễn ra như thế nào qua bài viết của anh leader PD tại ICTC – IC Training Center Vietnam nhé.

Cà phê sáng trên tay, gõ vài dòng lệnh trong terminal, mắt liếc nhanh qua màn hình report từ tool – một buổi sáng “điển hình” của kỹ sư Physical Design (PD) bắt đầu như thế đó. Dù nghe thì có vẻ giống dân văn phòng ngồi máy tính cả ngày, nhưng công việc của kỹ sư PD lại chẳng hề nhàm chán như bạn nghĩ đâu.

Mỗi buổi sáng mở máy lên, thứ đầu tiên kỹ sư PD sẽ kiểm tra không phải Facebook hay TikTok, mà là… email và log file. Đọc kỹ các thông tin cập nhật từ team RTL, STA, hoặc DFT để xem có thay đổi gì về netlist, constraint, hay yêu cầu kỹ thuật mới không. Những dòng chữ đơn giản kia đôi khi là “điềm báo” cho một ngày bận rộn đang chờ phía trước.

Sau phần khởi động nhẹ nhàng là lúc bước vào vòng lặp thần thánh: chạy tool – xem kết quả – debug – chạy lại. Mỗi bước như placement, clock tree synthesis (CTS), routing hay sign-off đều có thể mang đến niềm vui vỡ òa… hoặc cơn đau đầu âm ỉ kéo dài cả buổi chiều. Nhìn thì đơn giản, nhưng để một design đạt đủ mọi tiêu chí về timing, area, DRC, congestion,… thì giống như xếp hình mà các mảnh liên tục bị thay đổi, chỉ khác là mảnh ở đây là hàng chục ngàn cell, cổng logic, và dây nối chằng chịt.

Khi một bước nào đó cho kết quả “đỏ lè” (như timing fail, DRC lỗi tùm lum), kỹ sư PD sẽ phải vào vai “thám tử”, soi từng dòng log, mở layout, zoom từng đoạn net, xem có phải clock bị lệch không, cell bị đặt sai vị trí không, hay scan chain team DFT gắn vào bị đứt gánh giữa đường… Từng lỗi debug ra như giải được một câu đố hóc búa, và cảm giác khi nhìn thấy số lỗi giảm dần đúng là không gì sánh bằng. Nếu mà để so sánh thì cũng giống như niềm vui khi mấy bạn sinh viên nạp code vào mà mạch điều khiển chạy đúng như mong muốn vậy.

Nhưng đừng nghĩ kỹ sư PD là những con người sống biệt lập với layout và terminal. Mỗi ngày, họ vẫn có những cuộc họp với leader, các team liên quan như RTL, STA, DFT, IR/EM… để trao đổi, cập nhật tiến độ hoặc thảo luận cách xử lý những vấn đề hóc búa. Khi design bị “nghẽn cổ chai”, meeting với team RTL sẽ giúp chỉnh lại logic. Khi timing khó đạt, cần bắt tay ngay với STA để gỡ từng path. Và nếu routing bị loằng ngoằng vì test logic, thì đừng ngại “gọi điện thoại” sang team DFT.

Những cuộc họp này vừa là nơi để báo cáo, vừa là dịp để học hỏi từ các anh chị giàu kinh nghiệm, vì mỗi người đều đã từng đối mặt với hàng đống lỗi giống mình. Không ít bạn PD junior từng kể rằng họ học được nhiều mẹo hay ho nhất không phải từ sách vở, mà từ những buổi check-in team 15 phút mỗi ngày.

Một phần công việc khác tuy không ai muốn nhưng luôn phải làm – viết report. Báo cáo kết quả từng bước, phân tích lỗi, đề xuất hướng xử lý. Đôi khi còn phải chụp layout minh họa, dán log vào, vẽ sơ đồ… Nhìn qua tưởng như làm slide thuyết trình, nhưng đây chính là cách giúp team hiểu bạn đã làm gì, gặp vấn đề gì và cần hỗ trợ ở đâu.

Tất cả những việc đó đều không thể thiếu người bạn đồng hành – Linux Terminal, cùng các EDA tool chuyên biệt. Làm việc với tool không chỉ là thao tác chuột, mà là cả một nghệ thuật với hệ thống script shell, TCL giúp tự động hóa cả một flow thiết kế. Khi script chạy mượt, tool vận hành trơn tru, PD engineer sẽ có thêm chút thời gian… để uống thêm ngụm cà phê.

Một ngày làm việc của kỹ sư PD là chuỗi hoạt động giữa kỹ thuật, quan sát, suy luận, giao tiếp, và không ít lần… tự động viên tinh thần. Công việc này đòi hỏi sự chính xác, kiên nhẫn và một chút đam mê với việc “sắp xếp lại thế giới tí hon” trong con chip. Mỗi block hoàn thiện là một chiến tích, mỗi bug debug xong là một chiến thắng. Và cũng chính những điều đó đã giữ chân bao nhiêu thế hệ kỹ sư PD gắn bó với nghề.