Mấy nay 2 anh DV lead với PD lead viết bài nhiều quá nên nay phải viết bài về RTL design cho cân bằng lại mới được 
. Tính ra nợ bài này cũng lâu rồi, y như cái cách nợ Học Vi Mạch Cùng ICTC lớp RTLA vậy
. Mời các bạn xem bài viết về một ngày làm việc tương đối nhàn nhã của mình nhé.
—
Mỗi công ty sẽ có một môi trường làm việc khác nhau, và ngay trong cùng một công ty, công việc của một kỹ sư RTL Design cũng không phải lúc nào cũng giống nhau. Tùy vào tính chất của từng project, module mình đang handle, hay từng giai đoạn của dự án (đầu phase, giữa phase hay giai đoạn tape-out), mà khối lượng và loại công việc mỗi ngày sẽ thay đổi khá nhiều. Có những ngày chủ yếu là design, có ngày ngập trong debug, có ngày thì chỉ xoay quanh meeting và hỗ trợ các team khác. Bài viết này chỉ đơn giản là chia sẻ một ngày làm việc điển hình của mình ở thời điểm hiện tại để các bạn có cái nhìn thực tế hơn về công việc của một kỹ sư RTL Design.
Một ngày của mình bắt đầu khá sớm. Việc đầu tiên không phải là mở laptop hay check mail, mà là…lo cho thằng nhóc chuẩn bị đi học. Khác với hai anh lead bên DV và PD, mình không có thói quen uống cà phê buổi sáng. Có lẽ do uống vào là tim đập nhanh, đầu óc hơi bay bay 
Đưa con đi học xong, về nhà mình sẽ dành khoảng 30 phút để tập thể dục nhẹ: chạy bộ, cardio… Nay có tuổi rồi phải ráng giữ sức khỏe, không để overweight và reset đầu óc trước khi bước vào một ngày làm việc dài, nhiều logic, nhiều timing và cũng nhiều… bug.
Mình bắt đầu làm việc lúc khoảng 9h sáng. Dự án này mình đang handle cũng kha khá module cùng lúc nên việc đầu tiên là sắp xếp lại timeline trong đầu: hôm nay ưu tiên module nào, việc gì cần làm trước, việc gì có thể để sau.
Buổi sáng hôm nay mình dành để làm spec. Với nhiều bạn, spec có vẻ là phần khá chán, toàn chữ, diagram, timing, chưa được code dòng nào. Nhưng với RTL Design, đây là giai đoạn quan trọng nhất. Spec quyết định rất nhiều thứ phía sau: code có trơn tru không, sau này debug có dễ không, vào review có bị sếp “sấy” không …
Dạo này mình đang design một module converter để thực hiện một phép chuyển đổi số học trong chip. Module này phải dùng pipeline, nên khi làm spec phải consider nhiều yếu tố.
Đầu tiên là timing: mỗi pipeline stage có bao nhiêu logic là vừa? Nếu nhồi quá nhiều logic vào một stage thì khả năng timing violation rất cao, mà sửa timing sau này khi mọi thứ đã xong xuôi thì thì khá là mệt, nên phải xem xét kĩ càng. Tiếp theo là performance: throughput có đảm bảo không, data có bị nghẽn không, dùng FIFO depth bao nhiêu là hợp lý. FIFO sâu quá thì area tăng, đôi khi dư thừa. FIFO ít quá thì dễ nghẽn data. Rồi tới phần control FIFO: khi nào FIFO nên stop, khi nào resume. Phải tính tới các trường hợp early empty, almost full. Vì khi FIFO dừng, pipeline phía trước vẫn có thể tiếp tục đẩy data xuống. Nếu control không cẩn thận thì data mới có thể overwrite lên data cũ trong FIFO, debug rất là mệt sau này…
.
Sau khi cân nhắc các yếu tố timing, performance và area, mình quyết định chọn 3 pipeline stages và FIFO depth = 8 để cân bằng mọi thứ. Hoàn thành spec xong, mình cũng khá là ưng ý vì mọi thứ được viết theo template chuẩn, logic rõ ràng.
Sếp review spec và khá hài lòng với ý tưởng. Sếp chỉ nhắc là lúc code nên parameterize FIFO depth để sau này có thể reuse cho các dự án khác. Đây cũng là một kinh nghiệm hay, khi design thì chúng ta cũng nên nghĩ tới chuyện reuse, hỗ trợ nhiều configuration khác nhau để hạn chế việc phải modify về sau.
Buổi chiều mình chia thời gian cho hai việc chính.
Việc đầu tiên là study để implement một feature mới cho một IP từ dự án trước. Owner cũ đã resign, thứ còn lại chỉ là document và spec. Mình đã đọc spec và hiểu được ý tưởng design tổng thể rồi, nhưng như vậy là chưa đủ. Bước tiếp theo là chạy simulation và xem waveform để hiểu IP này hoạt động thực tế như thế nào. Với RTL Design, đọc spec chỉ là bước đầu. Muốn sửa hay thêm feature cho một IP, bạn bắt buộc phải nhìn waveform, theo dõi từng signal, từng FSM state. Đây cũng là một điểm khác biệt khá rõ giữa RTL Design và DV. DV thường quan tâm nhiều tới interface, testcase và behavior ở mức IP. Còn designer thì phải hiểu bên trong mạch hoạt động như thế nào, các tín hiệu liên quan với nhau ra sao, FSM trigger lúc nào, FIFO push/pop trong điều kiện nào. Chỉ cần sửa sai một chỗ nhỏ thôi cũng có thể ảnh hưởng tới cả module hoặc thậm chí là system.
Sau đó mình chuyển sang debug cho một module khác mà bạn DV đã bó tay nhờ debug giùm. Module này khá đặc biệt vì nó liên quan trực tiếp tới system, không thể chỉ nhìn riêng từng block. Muốn debug được thì phải hiểu cách các khối xung quanh tương tác với nhau, luồng data đi qua chip như thế nào. Những issue kiểu này thường khá là khó nhằn, nhưng bù lại, đây chính là cơ hội để mình hiểu sâu hơn về cách toàn bộ con chip hoạt động. Một RTL designer giỏi không chỉ hiểu rõ module của mình, mà còn phải có cái nhìn tổng thể về system và whole chip.
Đang debug hăng say thì chuông báo reng – tới giờ họp status. Ở những giai đoạn căng thẳng thì daily meeting là chuyện bình thường, còn hiện tại project đỡ hơn nên chỉ họp khoảng…3 lần một tuần . Meeting là lúc các sếp nắm tình hình, tháo gỡ các vướng mắc, unblock cho team. Tuy nhiên, nói thật là cũng khá áp lực. Nếu status không rõ ràng, không đúng tiến độ thì rất dễ bị “sấy” ngay trong meeting.
Họp xong cũng tầm 6h chiều. Đây là lúc mình tạm ngưng công việc để dành thời gian cho bản thân và gia đình: ăn tối, dạy con học, chơi với con rồi cho con đi ngủ. Khoảng 10h tối, mình bắt đầu “ca đêm”. Dạo này project hơi bận nên mình tranh thủ làm thêm một chút để kịp tiến độ và có status “đẹp đẹp” cho ngày hôm sau.
Kết thúc ngày làm việc lúc khoảng 12h đêm.
Các bạn thấy một ngày làm việc của kỹ sư RTL Design như thế nào? Có thấy thú vị không nè?
Nếu bạn nào muốn xem lại bài viết về một ngày làm việc của kỹ sư PD hoặc DV, cứ comment bên dưới nhé, mình sẽ gửi lại cho các bạn.
