-- BẠN CÓ THỂ TẢI CODE VÍ DỤ Vivado HLS TẠI ĐÂY:GG DRIVER
2. Kiểm tra chương trình C.
- Bước đầu tiên trong một project HLS là để kiểm tra code C chạy đúng. Quá trình này được gọi là C Validation hoặc C Simulation. Trong project này, các test bench so sánh các dữ liệu đầu ra của hàm FIR với các giá trị cho trước.
- Bước 1. Mở rộng thư mục Test Bench trong cửa sổ Explorer.
- Bước 2. Nhấp đúp vào tập tin fir_test.c để hiển thị nó trong Information pane.
- Bước 3. Trong cửa sổ Auxiliary pane, chọn main() trong tab Outline để nhảy trực tiếp đến hàm main().
-- Các file test bench, fir_test.c, chứa hàm main() ở mức top-level, nó sẽ gọi hàm được tổng hợp (FIR). Một đặc điểm hữu ích của test bench này là nó là selfchecking:
• Các test bench lưu đầu ra từ các hàm FIR vào file đầu ra, out.dat.
• Các file đầu ra được so sánh với kết quả golden, được lưu trữ trong tập tin out.gold.dat.
• Nếu đầu ra phù hợp với dữ liệu golden, một thông báo xác nhận rằng quả là chính xác, và giá trị trả về test bench hàm main() được thiết lập là 0.
• Nếu đầu ra là khác nhau, một thông báo chỉ ra điều này, và giá trị trả về của hàm main() được thiết lập là 1.
-- Công cụ Vivado HLS có thể tái sử dụng test bench để thực hiện kiểm tra RTL. Kết quả RTL sẽ được tự động check trong quá trình xác minh RTL. Vivado HLS tái sử dụng test bench trong quá trình xác minh RTL và xác minh thành công RTL nếu test bench trả về giá trị 0.
- Bước 4. Nhấp vào nút Run C Simulation, hoặc sử dụng dự án menu> Run C Simulation để biên dịch và thực hiện các thiết kế C.
- Bước 5. Trong hộp thoại C Simulation, bấm OK.
-- Hình dưới đây là thể hiện quá trình mô phỏng thực hiện thành công
-- Chú ý: Nếu mô phỏng C thất bại, hãy chọn tùy chọn Debug trong hộp thoại C Simulation.
3. High-Level Synthesis
-- Trong bước này, bạn Synthesis thiết kế C thành một thiết kế RTL và xem xét thông tin tổng hợp liên quan.
- Bước 1. Nhấp vào nút Run C Synthesis hoặc menu> Run C Synthesis để bắt đầu tổng hợp.
- Bước 2. Nhấp vào Performance Estimate trong tab Outline (Hình 12).
- Bước 3. Trong phần Details của Performance Estimates, mở rộng khung Loop.
-- Trong cửa sổ Performance Estimates, thể hiện trong hình 12, bạn có thể thấy rằng chu kỳ xung clock là 10 ns. Mục tiêu của Vivado HLS nhắm đếm là xung clock Estimated được tính bằng Clock Target - Clock Uncertainty( trong ví dụ này là 10.00-1.25 = 8.75ns).
-- Trong phần Summary, bạn có thể thấy:
• Thiết kế có độ trễ là 78-clock cycles: phải mất 78-clock để cho ra kết quả.
• Interval là 79 clock cycles: các bước tiếp theo của đầu vào được đọc sau 79 clock. Đây là một cycle
sau khi kết quả cuối cùng được viết. Điều này cho thấy thiết kế không có pipeline. Việc thực hiện các hàm tiếp theo chỉ có thể bắt đầu khi hàm hiện tại hoàn thành.
• Thông báo "thiết kế không pipeline" cũng được thể hiện trong mục type pipelined.
Các chi tiết phần chương trình:
-- Trong phần Details:
• Không có sub-blocks trong thiết kế này. Mở rộng phần Instance cho thấy không có các submodules trong hệ thống phân cấp.
• Tất cả sự chậm trễ là do quá trình tổng hợp logic RTL từ các vòng lặp tên Shift_Accum_Loop. Logic này thực hiện 11 times (Trip Count). Mỗi thực hiện đòi hỏi 7 Send Feedback clock cycles, với tổng số 88 clock cycles, để thực hiện ttất cả các bước lặp của logic tổng hợp từ vòng lặp này.
• Tổng độ trễ là một clock cycle lớn hơn độ trễ vòng lặp. Nó đòi hỏi một clock cycle để nhập và thoát khỏi vòng lặp (trong trường hợp này, kết thúc thiết kế khi kết thúc vòng lặp, như vậy không có exit cycle).
- Bước 4. Trong tab Outline, bấm Utilization Estimate (Hình 13).
- Bước 5. Trong phần Details của Utilization Estimates, mở rộng Instance.
-- Các thiết kế sử dụng một bộ nhớ duy nhất thực hiện là LUTRAM (vì nó chứa ít hơn 1024 phần tử), 4 DSP48s, và khoảng 200 flip-flops và LUTs.
• Tổng hợp RTL có thể thực hiện tối ưu hóa thêm, và những con số này có thể thay đổi sau khi tổng hợp RTL.
• Số lượng các DSP48s dường như lớn hơn so với dự kiến cho một bộ lọc FIR. Bởi vì các dữ liệu là một kiểu số nguyên C 32-bit. Nó đòi hỏi nhiều hơn 1 DSP48 để nhân các giá trị dữ liệu 32-bit.
• Bộ multiplier là một multiplier pipelined. Nó xuất hiện trong phần Instance cho thấy nó là sub-block. Bộ multiplier tổ hợp tiêu chuẩn không có hệ thống phân cấp và được liệt kê trong phần Expressions.
- Bước 6. Trong tab Outline, nhấp vào Interface (hình 14).
-- Phần Interface hiển thị các cổng và giao thức I/O được tạo ra bằng cách synthesis interface:
• Các thiết kế có cổng clock và reset(ap_clk và ap_reset). Chúng được kết hợp với Source Object fir: the design itself.
• Có cổng additional liên quan đến việc thiết kế như Source Object. Synthesis đã tự động thêm một số cổng kiểm soát mức độ block: ap_start, ap_done, ap_idle và ap_ready.
• Bài viết về Interface Synthesis sẽ cung cấp thêm thông tin về các cổng này.
• Đầu ra y bây giờ là một cổng dữ liệu 32-bit với tín hiệu chỉ thị y_ap_vld.
• Đối số đầu vào c (một mảng) được thực hiện như một khối bộ nhớ RAM với cổng địa chỉ đầu ra là 4-bit, một cổng đầu ra CE và một cổng dữ liệu đầu vào 32-bit.
• Cuối cùng, đối số đầu vào x chỉ đơn giản là thực hiện như một cổng dữ liệu không có giao thức I/O (ap_none).
2. Kiểm tra chương trình C.
- Bước đầu tiên trong một project HLS là để kiểm tra code C chạy đúng. Quá trình này được gọi là C Validation hoặc C Simulation. Trong project này, các test bench so sánh các dữ liệu đầu ra của hàm FIR với các giá trị cho trước.
- Bước 1. Mở rộng thư mục Test Bench trong cửa sổ Explorer.
- Bước 2. Nhấp đúp vào tập tin fir_test.c để hiển thị nó trong Information pane.
- Bước 3. Trong cửa sổ Auxiliary pane, chọn main() trong tab Outline để nhảy trực tiếp đến hàm main().
-- Các file test bench, fir_test.c, chứa hàm main() ở mức top-level, nó sẽ gọi hàm được tổng hợp (FIR). Một đặc điểm hữu ích của test bench này là nó là selfchecking:
• Các test bench lưu đầu ra từ các hàm FIR vào file đầu ra, out.dat.
• Các file đầu ra được so sánh với kết quả golden, được lưu trữ trong tập tin out.gold.dat.
• Nếu đầu ra phù hợp với dữ liệu golden, một thông báo xác nhận rằng quả là chính xác, và giá trị trả về test bench hàm main() được thiết lập là 0.
• Nếu đầu ra là khác nhau, một thông báo chỉ ra điều này, và giá trị trả về của hàm main() được thiết lập là 1.
-- Công cụ Vivado HLS có thể tái sử dụng test bench để thực hiện kiểm tra RTL. Kết quả RTL sẽ được tự động check trong quá trình xác minh RTL. Vivado HLS tái sử dụng test bench trong quá trình xác minh RTL và xác minh thành công RTL nếu test bench trả về giá trị 0.
- Bước 4. Nhấp vào nút Run C Simulation, hoặc sử dụng dự án menu> Run C Simulation để biên dịch và thực hiện các thiết kế C.
- Bước 5. Trong hộp thoại C Simulation, bấm OK.
-- Hình dưới đây là thể hiện quá trình mô phỏng thực hiện thành công
-- Chú ý: Nếu mô phỏng C thất bại, hãy chọn tùy chọn Debug trong hộp thoại C Simulation.
3. High-Level Synthesis
-- Trong bước này, bạn Synthesis thiết kế C thành một thiết kế RTL và xem xét thông tin tổng hợp liên quan.
- Bước 1. Nhấp vào nút Run C Synthesis hoặc menu> Run C Synthesis để bắt đầu tổng hợp.
- Bước 2. Nhấp vào Performance Estimate trong tab Outline (Hình 12).
- Bước 3. Trong phần Details của Performance Estimates, mở rộng khung Loop.
-- Trong cửa sổ Performance Estimates, thể hiện trong hình 12, bạn có thể thấy rằng chu kỳ xung clock là 10 ns. Mục tiêu của Vivado HLS nhắm đếm là xung clock Estimated được tính bằng Clock Target - Clock Uncertainty( trong ví dụ này là 10.00-1.25 = 8.75ns).
-- Trong phần Summary, bạn có thể thấy:
• Thiết kế có độ trễ là 78-clock cycles: phải mất 78-clock để cho ra kết quả.
• Interval là 79 clock cycles: các bước tiếp theo của đầu vào được đọc sau 79 clock. Đây là một cycle
sau khi kết quả cuối cùng được viết. Điều này cho thấy thiết kế không có pipeline. Việc thực hiện các hàm tiếp theo chỉ có thể bắt đầu khi hàm hiện tại hoàn thành.
• Thông báo "thiết kế không pipeline" cũng được thể hiện trong mục type pipelined.
Các chi tiết phần chương trình:
-- Trong phần Details:
• Không có sub-blocks trong thiết kế này. Mở rộng phần Instance cho thấy không có các submodules trong hệ thống phân cấp.
• Tất cả sự chậm trễ là do quá trình tổng hợp logic RTL từ các vòng lặp tên Shift_Accum_Loop. Logic này thực hiện 11 times (Trip Count). Mỗi thực hiện đòi hỏi 7 Send Feedback clock cycles, với tổng số 88 clock cycles, để thực hiện ttất cả các bước lặp của logic tổng hợp từ vòng lặp này.
• Tổng độ trễ là một clock cycle lớn hơn độ trễ vòng lặp. Nó đòi hỏi một clock cycle để nhập và thoát khỏi vòng lặp (trong trường hợp này, kết thúc thiết kế khi kết thúc vòng lặp, như vậy không có exit cycle).
- Bước 4. Trong tab Outline, bấm Utilization Estimate (Hình 13).
- Bước 5. Trong phần Details của Utilization Estimates, mở rộng Instance.
-- Các thiết kế sử dụng một bộ nhớ duy nhất thực hiện là LUTRAM (vì nó chứa ít hơn 1024 phần tử), 4 DSP48s, và khoảng 200 flip-flops và LUTs.
• Tổng hợp RTL có thể thực hiện tối ưu hóa thêm, và những con số này có thể thay đổi sau khi tổng hợp RTL.
• Số lượng các DSP48s dường như lớn hơn so với dự kiến cho một bộ lọc FIR. Bởi vì các dữ liệu là một kiểu số nguyên C 32-bit. Nó đòi hỏi nhiều hơn 1 DSP48 để nhân các giá trị dữ liệu 32-bit.
• Bộ multiplier là một multiplier pipelined. Nó xuất hiện trong phần Instance cho thấy nó là sub-block. Bộ multiplier tổ hợp tiêu chuẩn không có hệ thống phân cấp và được liệt kê trong phần Expressions.
- Bước 6. Trong tab Outline, nhấp vào Interface (hình 14).
-- Phần Interface hiển thị các cổng và giao thức I/O được tạo ra bằng cách synthesis interface:
• Các thiết kế có cổng clock và reset(ap_clk và ap_reset). Chúng được kết hợp với Source Object fir: the design itself.
• Có cổng additional liên quan đến việc thiết kế như Source Object. Synthesis đã tự động thêm một số cổng kiểm soát mức độ block: ap_start, ap_done, ap_idle và ap_ready.
• Bài viết về Interface Synthesis sẽ cung cấp thêm thông tin về các cổng này.
• Đầu ra y bây giờ là một cổng dữ liệu 32-bit với tín hiệu chỉ thị y_ap_vld.
• Đối số đầu vào c (một mảng) được thực hiện như một khối bộ nhớ RAM với cổng địa chỉ đầu ra là 4-bit, một cổng đầu ra CE và một cổng dữ liệu đầu vào 32-bit.
• Cuối cùng, đối số đầu vào x chỉ đơn giản là thực hiện như một cổng dữ liệu không có giao thức I/O (ap_none).