Vì sao dev software ghét compile 30 giây… còn FPGA engineer sống chung với compile 1 tiếng

☕ Từ “build lâu quá” đến cú shock mang tên FPGA

Nếu bạn là dev software, chắc hẳn đã từng có lúc khó chịu vì project build quá lâu. Chạy npm run build vài chục giây đã thấy sốt ruột, Android Studio compile vài phút là bắt đầu đứng dậy đi pha cà phê, còn Docker mất cache hay CI/CD pending mãi chưa xong thì gần như đủ để cả team than trời. Mình cũng từng nghĩ compile vài phút đã là “cực hình” rồi. Cho tới ngày bắt đầu làm FPGA.

Trong thế giới FPGA, compile 20–30 phút là chuyện hoàn toàn bình thường. Những design lớn hơn có thể mất gần cả tiếng, thậm chí vài tiếng nếu timing khó hoặc resource utilization quá cao. Điều thú vị là phần “đau khổ” nhất lại không nằm ở thời gian chờ, mà nằm ở việc compile xong đôi khi chỉ để phát hiện thiếu một dòng reset, hoặc timing fail vì một thay đổi rất nhỏ.

🤔 FPGA thực ra không “compile code”

Lúc mới làm FPGA, mình từng nghĩ: “Ủa, compile cái gì mà lâu dữ vậy?”. Sau này mới hiểu rằng FPGA thực ra không “compile code” theo nghĩa thông thường của software. Nó đang cố biến code của bạn thành một mạch điện thật.

Đây chính là khác biệt lớn nhất giữa software và FPGA. Khi bạn viết một đoạn C++ hay Python, compiler chủ yếu parse code, optimize rồi generate machine code để CPU thực thi. CPU phía dưới gần như không thay đổi. Dù bạn viết web server, game hay ứng dụng AI thì phần cứng vẫn là CPU quen thuộc đó.

Nhưng với FPGA thì khác hoàn toàn. Khi bạn viết một dòng Verilog đơn giản như: assign y = a + b;

tool không chỉ dịch nó thành instruction. Nó phải quyết định sẽ dùng LUT nào, có cần DSP block hay không, đặt logic ở đâu trên chip, route tín hiệu như thế nào và quan trọng nhất là timing có đạt hay không.

Nói cách khác:

FPGA không chạy code của bạn — nó đang cố biến code thành phần cứng thực sự.

🏗️ Một lần compile FPGA đang làm rất nhiều việc phía sau

Và đây là lý do compile FPGA lâu đến vậy. Một lần compile thực chất gồm rất nhiều bước phía sau.

Đầu tiên là synthesis, nơi RTL được chuyển thành logic gate và netlist. Sau đó là place & route, khi tool phải quyết định đặt từng block ở đâu trên FPGA và nối hàng triệu tín hiệu nội bộ với nhau.

Điểm thú vị là FPGA là một con chip vật lý thật. Nó không phải “một đám logic vô hạn” như nhiều người mới tưởng tượng. FPGA có:

• LUT
• DSP
• BRAM
• routing resource

… tất cả đều nằm ở những vị trí vật lý cụ thể trên chip.

Điều này có nghĩa là khoảng cách giữa các block logic thật sự ảnh hưởng đến tốc độ tín hiệu. Nếu placement không tốt hoặc routing quá phức tạp, timing rất dễ fail. Đây là thứ mà phần lớn software dev không bao giờ phải nghĩ tới.

⏱️ Timing – nỗi ám ảnh lớn nhất của FPGA engineer

Timing cũng là khái niệm khiến rất nhiều người mới học FPGA bị “shock”.

Trong software:

logic đúng thường đồng nghĩa với chương trình chạy đúng.

Nhưng FPGA thì khác.

Bạn có thể:

• viết code hoàn toàn chính xác
• simulation pass hết
• synthesis thành công

… nhưng hardware thật vẫn chạy lỗi chỉ vì tín hiệu không kịp đi trong một chu kỳ clock.

Ví dụ, nếu design chạy ở 100 MHz thì mỗi chu kỳ chỉ có 10ns. Nếu tổng delay của logic và routing vượt quá 10ns, tool sẽ báo timing fail với một dòng rất đáng sợ như: Slack: -0.3 ns

Đây là lúc bạn nhận ra FPGA không chỉ liên quan đến code, mà còn liên quan tới:

• physics
• delay
• wire length
• khoảng cách vật lý bên trong chip

😵 Chỉ sửa một dòng code cũng có thể “toang”

Điều thú vị là đôi khi chỉ một thay đổi rất nhỏ cũng có thể làm toàn bộ timing thay đổi theo.

Ví dụ:

• thêm một signal debug
• đổi bus từ 32-bit sang 64-bit
• thêm một module nhỏ

… đều có thể khiến routing khác hoàn toàn.

Và rồi bạn phải chờ thêm 40 phút compile chỉ để biết rằng:

design vẫn fail timing như cũ 😄

Đó là lý do FPGA engineer thường rất ám ảnh với architecture, pipeline và dataflow ngay từ đầu. Trong software, nhiều khi có thể optimize sau. Nhưng với FPGA, architecture gần như quyết định mọi thứ.

🚀 Điều khiến FPGA vừa đau khổ… vừa thú vị

Dù vậy, đây cũng là điều khiến FPGA rất thú vị.

Khi design cuối cùng chạy đúng, cảm giác khá khác so với việc chỉ “run thành công” một chương trình software. Bạn không chỉ viết code, mà đang thiết kế pipeline, tối ưu dataflow và xây dựng một hệ thống phần cứng thực sự hoạt động theo đúng cách mình mong muốn.

Sau một thời gian làm FPGA, mình bắt đầu cảm thấy software abstraction đã che giấu rất nhiều thứ thú vị phía dưới. Timing, routing, latency hay data movement — tất cả đều là những vấn đề rất “thật”, và FPGA buộc bạn phải đối mặt trực tiếp với chúng.