Tweet
Xin cống hiến các bạn một bài về tổng hợp mực cao. Tôi không rành từ Việt Nam trong lãnh vực này nhưng vẫn cố gắng, xin các bạn thông cảm cho. Nếu có gì thắc mắc, xin cứ hỏi.
Chào
Tony
----------------------------------
Nâng trình độ Xác Minh RTL với Tổng Hợp Mức Cao (High Level Synthesis)
1) Làm nhẹ gánh nặng của xác minh RTL
Xác minh là một thử thách lớn cho những người làm thiết kế về ASIC. Khi sang chế trở thành phức tạp hơn, cách khảo sát càng trở nên phức tạp hơn đến độ khó cai quản. Mặc dù đã có nhiều cách thức khảo sát đã ra đời để giúp đỡ cho đơn giản hơn nhưng cái gốc của vấn đề khảo sát vẫn là sự tạo ra nó. Khi cách khảo sát đã đi xa hơn bởi tận dụng những ngôn ngữ hạng cao (systemV và systemC), cách sang chế vẫn còn ở trình độ của 20 năm về trước. Chúng ta vẫn thiết kế dùng RTL để diễn tả những hoạt động chính gốc của C (C thường dùng để mô tả hoạt động của design) cho những thiết kế vô cùng phức tạp. Hãy mường tượng nếu hệ thống tân tiến của điện thoại thời nay phải dùng cách chuyển của con người (switch board operator) để bảo quản hàng triệu cú diện thoại mỗi giờ.
Kết quả của những lỗi khi thiết kế ở dạng RTL sẽ kéo dài thời gian để khảo sát. Càng nhiều lỗi càng mất nhiều thòi gian để khảo sát trong khi thời gian là vàng bạc cho những vị kỹ sư để nghiên cứu thêm cách để làm cho thiết kế của họ được hoàn hảo hơn (optimize for area, performance and power).
Thay vì kéo dài thời gian xốc óc để tìm kiếm những lỗi của RTL code, dòng thiết kế cần phải chỉnh hướng để có thể làm RTL một cách hoàn hảo hơn (bug free). Sự chỉnh hướng này đã được hiện thực bằng cách tự động hóa RTL từ mô hình chính xác của C/C++. Nếu làm đúng, tổng hợp mức cao (HLS) có thể sản xuất ra RTL code mà thực hiện đúng với hoạt động đã được đề ra, xóa bỏ những lỗi mà thường xẩy ra khi chuyển từ C/C++ qua RTL. Tất nhiên là RTL verififcation sẽ dễ dàng hơn và thời gian để khảo sát sẽ rút ngắn rất nhiều. Những kỹ sư thiết kế sẽ thoát nạn xác minh khổng lồ.
2 điều kiện cần phải có để có thể giảm bớt gánh nặng của RTL xác minh. Bài nguồn ở mức cao (C/C++) phải được khảo sát kỹ càng và sự hiện thực hóa RTL phải chính xác khi tạo dựng (correct by construction). Khảo sát ở mức C/C++ thì dễ dàng và nhanh hơn vì nó dễ hiểu và đơn dản hơn RTL. Ít chi tiết để khảo sát, ít code để tìm lỗi, simulation chạy lẹ hơn, sửa chữa cũng dễ dàng hơn. Tạo dựng chính xác ra RTL có thể tránh sự việc tìm lỗi, xóa bỏ sự nan giải của RTL xác minh đi khoảng 30 tới 40 phần trăm.
2) Những cạm bẫy khi tạo hóa RTL
Có 2 cạm bẫy thường ngăn cản hầu hết những HLS tools và những phương pháp (methodologies) để thành công trong sự tạo dựng chính xác ra RTL: Nguồn code dựa vào sự ngăn biệt thời gian (schedule dependent source code) và cắt gọn sự tổng hợp. Ngăn biệt thời gian là công cụ chính của HLS. Nếu sự hoạt động của thiết kế lệ thuộc vào một biểu thời gian cụ thể nào đó (latency sensitive) thì RTL từ tổng hợp có thể hoạt động không giống kỹ thuật.
Sự khác biệt này xảy ra vì công cụ căn bản của HLS là đem thời gian vào thiết kế. HLS bắt đầu từ mô phỏng, không có thời gian, để tạo ra RTL mà cần xung (clocks). Bởi vì HLS đem và chuyển hóa thời gian ở thiết kế cho nên phần mô phỏng không nên có lệ thuộc vào thời gian nào hết thì sự chính xác khi tạo dựng RTL mới được bảo tồn. Sự mô tả ở mức cao (high level description) không nên lệ thuộc vào biểu thời gian (schedule independent).
Rất tiếc là nhiều dòng HLS không thể bảo đảm về sự không nên lệ thuộc vào biểu thời gian. Ví dụ bằng thiết kế, systemC đưa ra mô tả có thời gian và sự đồng loạt. Khi nó có thể tạo mô tả không lệ thuộc vào biểu thời gian ở systemC, nó cũng rất dễ để viết những mô hình lệ thuộc vào biểu thời gian mà không nhận ra sự chính xác của thiết kế cho một thời điểm nào đó. Do đó, khi những systemC tổng hợp hiện nay đem vào và điều chỉnh thời gian trong mô tả ở mức cao, kết quả RTL không thể giống như đã mô tả. Mặc dù đã xác minh trước khi tổng hợp, xác minh bao quát ở RTL vẫn phải cần.
Ngay khi cả nguồn ngôn ngữ bắt buộc là không lệ thuộc vào biểu thời gian, một vài công cụ HLS vi phạm semantic về ngôn ngữ của riêng nó. Những công cụ này không màng đến việc liên tục sắp xếp bởi nguồn mã (source code) và ngắt đứt sự đồng bộ của thiết kế hay phần của thiết kế. Bởi vì bác bỏ tư cách thật của mã C, tạo RTL có thể không chạy giống như nguồn mã, buộc phải xác minh nhiều hơn ở RTL. Những cắt gọn này có thể vì muốn đạt chỉ tiêu của thiết kế hay vì sự thiếu sót của công cụ, nhưng không thể chấp nhận được khi ảnh hưởng quá cao đến việc xác minh ở RTL.
Rất là quan trọng để chắc chắn là không để ngôn ngữ ở mức cao hoặc công cụ HLS phá hủy sự tạo dựng chính xác RTL. Khi mô tả, xác minh và tổng hợp từ nguyên thủy C/C++, nguồn không thời gian, không thể để bị liên hệ về biểu thời gian. Khi công cụ HLS tôn trọng và thi hành sự kiện liên tục của biến số và hoạt động, sự chính xác của thiết kế phải được bảo toàn. Chỉ khi 2 điều kiện đã đề ra dược tuân theo mới có thể tạo dựng RTL một cách chính xác và hoạt động tương tự như chỉ tiêu đã đề ra. Nhờ đó có thể tránh được sự cần thiết xác minh lại.
3) Luồng xác minh ở mức C
Ràng buộc xác minh sau khi HLS và ở dạng timed netlist làm chậm khai triển rất nhiều và tạo nhiều phức tạp xác minh ở RTL. Tạo dựng chính xác RTL giải quyết vấn đề này. Để tạo ảnh hưởng lớn khi xác minh RTL, rất cần thiết là bảo đảm sự chính xác khi xác minh ở mã mức cao càng nhiều càng tốt. Ít chi tiết ở mã nguồn, tốc độ cao ở C simulation và full coverage của thiết kế không những chỉ mang lại thiết kế có chất lượng, mà còn tạo một mô hình tham khảo ở dạng C, thử nghiệm cao và testbenches có thể dùng lại ở RTL.
Gắn vào thêm chi tiết trong mã nguồn hơn cần thiết chống lại mục đích này. Ví dụ, mặc dù sự tổng hợp tự động tạo ra những phần cứng đồng loạt, một ngôn ngữ như systemC định rõ dứt khoát sự đồng loạt ở nguồn mức cao, đòi hỏi thay đổi mã nguồn khi nào những chi tiết về kiến trúc bị thay đổi khi tiến hành. Nhưng nỗ lực của xác minh ở mức cao sẽ không được tiện dụng bởi vì nguồn phải được xác minh trở lại.
Nói một cách khác, như với C++, nếu mã nguồn thực sự untimed và ngôn ngữ không dùng mã cứng đồng loạt (hardcode concurrency), công cụ tổng hợp có thể xây nhiều thiết kế khác nhau, tiến hành những bộ đồng loạt khác nhau từ cùng một mã nguồn, không đòi hỏi sự thay đổi của mã nguồn. Việc này tạo ra một lợi khí khổng lồ là không phải xác minh lại cho mỗi thay đổi này. Vì vậy thông tin về sự đồng loạt sẽ được điều khiển trong quá trình của tổng hợp như nhiệm vụ đã đề ra cho HLS. Thành quả cũng giống như sự thành lập IP ở mực cao, rất là linh hoạt và có thể được dùng để tiến hành nhiều mẫu thiết kế khác nhau từ cùng một mã nguồn.
Một cách tổng quát, vì giảm được chi tiết khi thiết kế, HLS làm giảm thời gian tổng quát xác minh. Tăng tốc độ simulation và hơn nữa, C++ mô hình chạy thẳng từ máy chủ, không đòi hỏi phải có event-based simulator hoặc nhân simulator nào hết. Simulation chạy nhanh hơn tạo điều kiện đẻ chạy thêm test vectors và xác định chu vi rộng lớn (greater coverage) của thiết kế. Việc này có lợi cho những người thiết kế RTL vì tổng hợp từ RTL sẽ được xác minh thông suốt và có nhiều trường hợp để khai phá và thử nghiệm. Rồi chúng ta không những tạo ra RTL một cách chính xác một cách tự động và trên mã được xác minh thấu đáo trước mà còn có một thiết kế tốt đẹp hơn.
Để hoàn tất xác minh, cần phải hiệu thực hóa độ chính xác của biến số (bit accuracy) ở mã nguồn. Trong thiết kế phần cứng, sự chính xác của biến số sẽ hiệu nghiệm thiết kế về năng lượng tiêu dùng, diện tích and độ chạy. Đây là l do mà độ dài tùy í của biến số (arbitray length variable) rất quan trọng trong HDL (Hardware Description Language). Tuy nhiên, native C datatype không cung cấp được sự linh hoạt (flexibility) và chính xác (precision). Dùng native datatype không thể mô tả chính xác về phần cứng mà định thiết kế. Vì vậy một số bit accurate datatype đã ra đời giúp chúng ta mô tả phần cứng một cách chính xác hơn. Trong lãnh vực điện toán, complex datatype, arithmetic và matrix trannsformation cũng rất thông dụng, cho nên đòi hỏi công cụ HLS phải trợ giúp trong vấn đề này luôn.
4) Luồng xác minh hiệu nghiệm của HLS
Công cụ HLS tốt nhất cho xác minh ở RTL cần phải dùng pure ANSI C/C++ là phần ngôn ngữ vào (input language) bởi vì càng ít chi tiết ở nguồn càng có lợi điểm. Không giống như nguồn vào systemC, ANSI C/C++ thực chất không có sự kiện đồng loạt, mà chỉ có sự kiện liên tục. Những chi tiết về thời gian và sự đồng loạt sẽ được đua vô trong khi tổng hợp. Đó là công việc của tổng hợp. Nhờ vậy, mã nguồn sẽ đơn giãn hơn nhiều và dễ xác minh hơn để bảo đảm hoạt động chính thức của thiết kế. Hoạt động của thiết kế không bị ràng buộc bởi biểu thời gian và trong khi tổng hợp, có thể biến hoạt động này thành nhiều khoản phần cứng khác nhau và tùy theo đòi hỏi, một khoản thích hợp sẽ được chọn để xây RTL.
Chào
Tony
----------------------------------
Nâng trình độ Xác Minh RTL với Tổng Hợp Mức Cao (High Level Synthesis)
1) Làm nhẹ gánh nặng của xác minh RTL
Xác minh là một thử thách lớn cho những người làm thiết kế về ASIC. Khi sang chế trở thành phức tạp hơn, cách khảo sát càng trở nên phức tạp hơn đến độ khó cai quản. Mặc dù đã có nhiều cách thức khảo sát đã ra đời để giúp đỡ cho đơn giản hơn nhưng cái gốc của vấn đề khảo sát vẫn là sự tạo ra nó. Khi cách khảo sát đã đi xa hơn bởi tận dụng những ngôn ngữ hạng cao (systemV và systemC), cách sang chế vẫn còn ở trình độ của 20 năm về trước. Chúng ta vẫn thiết kế dùng RTL để diễn tả những hoạt động chính gốc của C (C thường dùng để mô tả hoạt động của design) cho những thiết kế vô cùng phức tạp. Hãy mường tượng nếu hệ thống tân tiến của điện thoại thời nay phải dùng cách chuyển của con người (switch board operator) để bảo quản hàng triệu cú diện thoại mỗi giờ.
Kết quả của những lỗi khi thiết kế ở dạng RTL sẽ kéo dài thời gian để khảo sát. Càng nhiều lỗi càng mất nhiều thòi gian để khảo sát trong khi thời gian là vàng bạc cho những vị kỹ sư để nghiên cứu thêm cách để làm cho thiết kế của họ được hoàn hảo hơn (optimize for area, performance and power).
Thay vì kéo dài thời gian xốc óc để tìm kiếm những lỗi của RTL code, dòng thiết kế cần phải chỉnh hướng để có thể làm RTL một cách hoàn hảo hơn (bug free). Sự chỉnh hướng này đã được hiện thực bằng cách tự động hóa RTL từ mô hình chính xác của C/C++. Nếu làm đúng, tổng hợp mức cao (HLS) có thể sản xuất ra RTL code mà thực hiện đúng với hoạt động đã được đề ra, xóa bỏ những lỗi mà thường xẩy ra khi chuyển từ C/C++ qua RTL. Tất nhiên là RTL verififcation sẽ dễ dàng hơn và thời gian để khảo sát sẽ rút ngắn rất nhiều. Những kỹ sư thiết kế sẽ thoát nạn xác minh khổng lồ.
2 điều kiện cần phải có để có thể giảm bớt gánh nặng của RTL xác minh. Bài nguồn ở mức cao (C/C++) phải được khảo sát kỹ càng và sự hiện thực hóa RTL phải chính xác khi tạo dựng (correct by construction). Khảo sát ở mức C/C++ thì dễ dàng và nhanh hơn vì nó dễ hiểu và đơn dản hơn RTL. Ít chi tiết để khảo sát, ít code để tìm lỗi, simulation chạy lẹ hơn, sửa chữa cũng dễ dàng hơn. Tạo dựng chính xác ra RTL có thể tránh sự việc tìm lỗi, xóa bỏ sự nan giải của RTL xác minh đi khoảng 30 tới 40 phần trăm.
2) Những cạm bẫy khi tạo hóa RTL
Có 2 cạm bẫy thường ngăn cản hầu hết những HLS tools và những phương pháp (methodologies) để thành công trong sự tạo dựng chính xác ra RTL: Nguồn code dựa vào sự ngăn biệt thời gian (schedule dependent source code) và cắt gọn sự tổng hợp. Ngăn biệt thời gian là công cụ chính của HLS. Nếu sự hoạt động của thiết kế lệ thuộc vào một biểu thời gian cụ thể nào đó (latency sensitive) thì RTL từ tổng hợp có thể hoạt động không giống kỹ thuật.
Sự khác biệt này xảy ra vì công cụ căn bản của HLS là đem thời gian vào thiết kế. HLS bắt đầu từ mô phỏng, không có thời gian, để tạo ra RTL mà cần xung (clocks). Bởi vì HLS đem và chuyển hóa thời gian ở thiết kế cho nên phần mô phỏng không nên có lệ thuộc vào thời gian nào hết thì sự chính xác khi tạo dựng RTL mới được bảo tồn. Sự mô tả ở mức cao (high level description) không nên lệ thuộc vào biểu thời gian (schedule independent).
Rất tiếc là nhiều dòng HLS không thể bảo đảm về sự không nên lệ thuộc vào biểu thời gian. Ví dụ bằng thiết kế, systemC đưa ra mô tả có thời gian và sự đồng loạt. Khi nó có thể tạo mô tả không lệ thuộc vào biểu thời gian ở systemC, nó cũng rất dễ để viết những mô hình lệ thuộc vào biểu thời gian mà không nhận ra sự chính xác của thiết kế cho một thời điểm nào đó. Do đó, khi những systemC tổng hợp hiện nay đem vào và điều chỉnh thời gian trong mô tả ở mức cao, kết quả RTL không thể giống như đã mô tả. Mặc dù đã xác minh trước khi tổng hợp, xác minh bao quát ở RTL vẫn phải cần.
Ngay khi cả nguồn ngôn ngữ bắt buộc là không lệ thuộc vào biểu thời gian, một vài công cụ HLS vi phạm semantic về ngôn ngữ của riêng nó. Những công cụ này không màng đến việc liên tục sắp xếp bởi nguồn mã (source code) và ngắt đứt sự đồng bộ của thiết kế hay phần của thiết kế. Bởi vì bác bỏ tư cách thật của mã C, tạo RTL có thể không chạy giống như nguồn mã, buộc phải xác minh nhiều hơn ở RTL. Những cắt gọn này có thể vì muốn đạt chỉ tiêu của thiết kế hay vì sự thiếu sót của công cụ, nhưng không thể chấp nhận được khi ảnh hưởng quá cao đến việc xác minh ở RTL.
Rất là quan trọng để chắc chắn là không để ngôn ngữ ở mức cao hoặc công cụ HLS phá hủy sự tạo dựng chính xác RTL. Khi mô tả, xác minh và tổng hợp từ nguyên thủy C/C++, nguồn không thời gian, không thể để bị liên hệ về biểu thời gian. Khi công cụ HLS tôn trọng và thi hành sự kiện liên tục của biến số và hoạt động, sự chính xác của thiết kế phải được bảo toàn. Chỉ khi 2 điều kiện đã đề ra dược tuân theo mới có thể tạo dựng RTL một cách chính xác và hoạt động tương tự như chỉ tiêu đã đề ra. Nhờ đó có thể tránh được sự cần thiết xác minh lại.
3) Luồng xác minh ở mức C
Ràng buộc xác minh sau khi HLS và ở dạng timed netlist làm chậm khai triển rất nhiều và tạo nhiều phức tạp xác minh ở RTL. Tạo dựng chính xác RTL giải quyết vấn đề này. Để tạo ảnh hưởng lớn khi xác minh RTL, rất cần thiết là bảo đảm sự chính xác khi xác minh ở mã mức cao càng nhiều càng tốt. Ít chi tiết ở mã nguồn, tốc độ cao ở C simulation và full coverage của thiết kế không những chỉ mang lại thiết kế có chất lượng, mà còn tạo một mô hình tham khảo ở dạng C, thử nghiệm cao và testbenches có thể dùng lại ở RTL.
Gắn vào thêm chi tiết trong mã nguồn hơn cần thiết chống lại mục đích này. Ví dụ, mặc dù sự tổng hợp tự động tạo ra những phần cứng đồng loạt, một ngôn ngữ như systemC định rõ dứt khoát sự đồng loạt ở nguồn mức cao, đòi hỏi thay đổi mã nguồn khi nào những chi tiết về kiến trúc bị thay đổi khi tiến hành. Nhưng nỗ lực của xác minh ở mức cao sẽ không được tiện dụng bởi vì nguồn phải được xác minh trở lại.
Nói một cách khác, như với C++, nếu mã nguồn thực sự untimed và ngôn ngữ không dùng mã cứng đồng loạt (hardcode concurrency), công cụ tổng hợp có thể xây nhiều thiết kế khác nhau, tiến hành những bộ đồng loạt khác nhau từ cùng một mã nguồn, không đòi hỏi sự thay đổi của mã nguồn. Việc này tạo ra một lợi khí khổng lồ là không phải xác minh lại cho mỗi thay đổi này. Vì vậy thông tin về sự đồng loạt sẽ được điều khiển trong quá trình của tổng hợp như nhiệm vụ đã đề ra cho HLS. Thành quả cũng giống như sự thành lập IP ở mực cao, rất là linh hoạt và có thể được dùng để tiến hành nhiều mẫu thiết kế khác nhau từ cùng một mã nguồn.
Một cách tổng quát, vì giảm được chi tiết khi thiết kế, HLS làm giảm thời gian tổng quát xác minh. Tăng tốc độ simulation và hơn nữa, C++ mô hình chạy thẳng từ máy chủ, không đòi hỏi phải có event-based simulator hoặc nhân simulator nào hết. Simulation chạy nhanh hơn tạo điều kiện đẻ chạy thêm test vectors và xác định chu vi rộng lớn (greater coverage) của thiết kế. Việc này có lợi cho những người thiết kế RTL vì tổng hợp từ RTL sẽ được xác minh thông suốt và có nhiều trường hợp để khai phá và thử nghiệm. Rồi chúng ta không những tạo ra RTL một cách chính xác một cách tự động và trên mã được xác minh thấu đáo trước mà còn có một thiết kế tốt đẹp hơn.
Để hoàn tất xác minh, cần phải hiệu thực hóa độ chính xác của biến số (bit accuracy) ở mã nguồn. Trong thiết kế phần cứng, sự chính xác của biến số sẽ hiệu nghiệm thiết kế về năng lượng tiêu dùng, diện tích and độ chạy. Đây là l do mà độ dài tùy í của biến số (arbitray length variable) rất quan trọng trong HDL (Hardware Description Language). Tuy nhiên, native C datatype không cung cấp được sự linh hoạt (flexibility) và chính xác (precision). Dùng native datatype không thể mô tả chính xác về phần cứng mà định thiết kế. Vì vậy một số bit accurate datatype đã ra đời giúp chúng ta mô tả phần cứng một cách chính xác hơn. Trong lãnh vực điện toán, complex datatype, arithmetic và matrix trannsformation cũng rất thông dụng, cho nên đòi hỏi công cụ HLS phải trợ giúp trong vấn đề này luôn.
4) Luồng xác minh hiệu nghiệm của HLS
Công cụ HLS tốt nhất cho xác minh ở RTL cần phải dùng pure ANSI C/C++ là phần ngôn ngữ vào (input language) bởi vì càng ít chi tiết ở nguồn càng có lợi điểm. Không giống như nguồn vào systemC, ANSI C/C++ thực chất không có sự kiện đồng loạt, mà chỉ có sự kiện liên tục. Những chi tiết về thời gian và sự đồng loạt sẽ được đua vô trong khi tổng hợp. Đó là công việc của tổng hợp. Nhờ vậy, mã nguồn sẽ đơn giãn hơn nhiều và dễ xác minh hơn để bảo đảm hoạt động chính thức của thiết kế. Hoạt động của thiết kế không bị ràng buộc bởi biểu thời gian và trong khi tổng hợp, có thể biến hoạt động này thành nhiều khoản phần cứng khác nhau và tùy theo đòi hỏi, một khoản thích hợp sẽ được chọn để xây RTL.
)
Comment