Luận văn thạc sĩ Khoa học máy tính: Hiện thực tái cấu hình từng phần FPGA cho hệ thống nhận dạng virus tốc độ cao

TÓM TẮT LUẬN VĂN Tái cấu hình từng phần động TCHTP FPGA là một kỹ thuật hiện thực cho phép chỉ một bộ phận được chỉ định của thiết bị FPGA được tái cấu hình trong khi phần còn lại không

GIỚI THIỆU LUẬN VĂN

Tính cấp thiết của đề tài

Trong một thế giới “kết nối” ngày nay, Internet là một trong những cơ sở hạ tầng không thể thiếu, nếu không nói là quan trọng bậc nhất đối với cuộc sống của nhân loại

Với nhiều lợi ích lớn mà Interent mang lại, thì số lượng người dùng đã không ngừng gia tăng Theo Wiki, thì đến năm 2013, tổng số người sử dụng Internet chiếm 39% dân số thế giới Đặc biệt là ở các nước phát triển, tỷ lệ dân số kết nối internet đã tăng khoảng bốn lần; từ 8% trong năm 2005 lên 31% trong năm 2013 Riêng ở Việt Nam, theo WordBank, sự xâm nhập của Internet chỉ là 3.8% tổng dân số trong năm 2003

Nhưng sau chỉ một thập kỷ, vào năm 2013, con số này là 39.5%, tức là tăng hơn 10 lần Đi đôi với sự phát triển, Internet mặt khác lại là phương tiện hữu hiệu để phát tán các virus máy tính Các virus này có thể lấy cắp các thông tin bảo mật, nhạy cảm của người dùng, xóa các dữ liệu quan trọng, hay nguy hiểm hơn là tạo điều kiện cho người phát tán virus đột nhập chiếm quyền điều khiển hệ thống máy tính Do đó an ninh thông tin, hay cụ thể hơn là chống virus máy tính là một vấn đề tối quan trọng Thêm vào đó, nếu như trước đây các virus máy tính chủ yếu lan truyền qua các thiết bị lưu trữ cá nhân như đĩa mềm, đĩa CD thì ngày nay nó có thể dễ dàng và nhanh chóng lan truyền đến hàng loạt máy tính kết nối Internet qua các trang web, thư điện tử Từ đó, có thể nói rằng việc xây dựng và phát triển các chương trình hay hệ thống chống virus máy tính là điều rất cần thiết, nhất là đối với các doanh nghiệp, các tổ chức lớn, các cơ quan của chính phủ, quân đội, nơi mà sự xâm nhập của virus nếu không được ngăn chặn có thể dẫn đến thiệt hại rất lớn

Hiện nay, có rất nhiều giải pháp phần mềm chống virus như Kaspersky, Avast, BKAV, ClamAV… Các giải pháp này có tính uyển chuyển cao do dễ dàng cập nhật khi cần cải tiến thuật giải hay thay đổi cơ sở dữ liệu virus Tuy nhiên với sự phát triển lớn của các loại virus thì giải pháp phần mềm khó có thể đáp ứng được yêu cầu về tốc độ, đặc biệt là đối với các hệ thống máy chủ, các gateway đòi hỏi băng thông dữ liệu nhiều Gbps, và phải đồng thời phục vụ hàng trăm ngàn người dùng Vì vậy cần có các giải pháp tăng tốc dùng phần cứng Thiết bị phần cứng khả lập trình (Field

Programmable Gate Array - FPGA) là lựa chọn phù hợp trong trường hợp này do khả năng uyển chuyển rất cao so với các giải pháp phần cứng dùng ASIC (Application Specific Integrated Circuit) mặc dù tốc độ thường là thấp hơn ASIC Việc sử dụng

- 2 - FPGA có thể đảm bảo việc cập nhật hệ thống là dễ thực hiện, trong khi đó tốc độ xử lý là vượt trội so với phần mềm Dẫu vậy tài nguyên phần cứng trên các thiết bị FPGA là hữu hạn, nên không phải tất cả các công việc đều có thể được hiện thực bằng phần cứng Do đó một giải pháp tổng thể thường cần phải kết hợp cả phần mềm và phần cứng để tận dụng điểm mạnh, khắc phục điểm yếu của cả hai HV-AV (HCMUT Reconfigurable Anti-Virus) [1] là một hệ thống quét virus như vậy

Với các hệ thống dùng FPGA, thông thường khi cập nhật dữ liệu hay thuật giải thì cần phải tái cấu hình toàn bộ FPGA và vì vậy hệ thống phải tạm ngưng hoạt động; mặc dù trong nhiều trường hợp chỉ một số khối chức năng nhỏ trong toàn bộ hệ thống là cần phải thay đổi Điều này là không phù hợp trong các hệ thống đòi hỏi tính đáp ứng liên tục như các máy chủ hay ‘gateway’ Kỹ thuật tái cấu hình từng phần (partial reconfiguration) cho phép chỉ tái cấu hình một số vùng của thiết bị FPGA mà không làm ảnh hưởng đến các vùng còn lại[2] Điều này mang đến hai lợi ích lớn sau đây :

 Một là các thành phần khác của hệ thống vẫn có thể hoạt động bình thường và vì vậy đảm bảo hệ thống có thể đáp ứng người dùng trong quá trình tái cấu hình

 Hai là thời gian tái cấu hình thường nhanh hơn do chỉ một phần của thiết bị là cần được lập trình lại

Nói cách khác việc thêm chức năng TCHTP sẽ giúp hệ thống hiện tại có thể được áp dụng cho các hệ thống đòi hỏi đáp ứng thời gian thực Ngoài ra nhìn một cách xa hơn, TCHTP là một lĩnh vực đã được nghiên cứu và áp dụng trong nhiều hệ thống trên thế giới, tuy nhiên ở Trường Đại học Bách Khoa, kiến thức về lĩnh vực này còn rất hạn chế, nếu không nói là chưa được nghiên cứu và áp dụng trước đây Đề tài sẽ góp phần quan trọng tạo tiền đề thúc đẩy việc nghiên cứu và áp dụng lĩnh vực này trong tương lai

Những đóng góp của luận văn

Những đóng góp chính là:

 Xây dựng được kiến trúc hệ thống cho phép việc thay đổi giải thuật của phần cứng trong vùng TCHTP (vùng động) mà không cần phải thay đổi các phần cứng trong vùng tĩnh Đồng thời việc hỗ trợ lõi kép giúp cho hệ thống có thể hoạt động với công suất bằng 50% bình thường trong quá trình TCHTP

 Xây dựng thành công phần mềm và phần cứng để thực hiện việc TCHTP

 Đề xuất và hiện thực thành công phương án thay đổi giao thức giữa phần mềm quét virus và phần cứng đảm bảo phần mềm quét virus có thể hoạt động đúng một cách hoàn toàn độc lập với phần mềm tái cấu hình Điều này là rất quan trọng trong các mở rộng về sau Ở đây cần chú ý rằng phần mềm quét virus là phần mềm hiện có của hệ thống còn phần mềm để tái cấu hình từng phần là phần mềm mới phát triển

 Xây dựng thành công khối “ICAP controller” hỗ trợ 3 phương thức TCHTP khác nhau, dùng chuẩn giao tiếp phổ biến là “bus AXI ” Hiệu suất tối đa của mỗi phương thức lần lượt 1Mbs, 50Mbs và 3Gbs Đặc biệt đây là hiệu suất khi hoạt động thức tế khi quá trình quét virus diễn ra song song với quá trình TCHTP, chứ không phải là hiệu suất của riêng “ICAP controller” như nhiều công bố trước đó.

Cấu trúc luận văn

Chương 2: Trình bày chi tiết về thiết bị FPGA, làm rõ quy trình tái cấu hình toàn bộ và tái cấu hình từng phần Chương này cũng sẽ trình bày chi tiết về cấu trúc của tập tin “bitstream” dùng để lập trình Xilinx Virtex5 FPGA vì việc hiểu cấu trúc của tập tin này là tối quan trọng trong quá trình viết phần mềm và thiết kế phần cứng tiếp nhận tập tin nó Cấu trúc phần cứng và cách thức giao tiếp giữa phần mềm và phần cứng trong quá trình quét virus của hệ thống hiện tại – hệ thống tái cấu hình toàn bộ cũng được sơ lược trong chương này

Chương 3: Tổng hợp các công trình nghiên cứu liên quan đến quá trình hiện thực tái cấu hình từng phần Các công trình nghiên cứu được phân loại, sơ lược và đánh giá ưu điểm cũng như khuyết điểm

Chương 4: Đây là chương trọng tâm của luận văn Chi tiết hiện thực của hệ thống được làm rõ ở chương này Vì việc TCHTP đòi hỏi sự thay đổi trên phần mềm và phần cứng, nên cả phần cứng, phần mềm cùng với cách thức giao tiếp đều được trình bày chi tiết Kiểm định đặc tả phần cứng bằng mô phỏng là một việc rất cần thiết, chương này

- 4 - cũng miêu tả cách thức tác giả xây dựng hệ thống kiểm định và kiểm định hệ thống bằng mô phỏng trước khi thực thi trên phần cứng thật

Chương 5: Trình bày cách thức kiểm định và kết quả kiểm định hệ thống Chương 6: Đây là chương để đúc kết lại luận văn và đề xuất các hướng mở rộng hệ thống cho các nghiên cứu trong tương lai

KIẾN THỨC NỀN TẢNG

Tổng quan về thiết bị FPGA và quá trình cấu hình FPGA

2.1.1 Field Programmable Gate Array (FPGA)

FPGA, viết tắt của “Field Programmable Gate Array” [3], là một loại thiết bị bán dẫn có kiến trúc được minh họa như hình 2-1 sau đây

Hình 2-1 Kiến trúc tổng quát của một thiết bị FPGA

Hình 2-1 cho ta thấy rằng FPGA bao gồm năm thành phần cơ bản Thành phần thứ nhất là các khối logic khả lập trình thường được gọi tắt là các CLB (configurable logic blocks) Mỗi CLB thường bao gồm một bảng tra LUT (lookup table) có thể được lập trình để thực hiện các chức năng luận lý cơ bản (combinational logic) như AND, OR, NOT, XOR, hoặc các chức năng kết hợp phức tạp hơn như bộ giải mã Về bản chất các LUT có thể là ROM hoặc là RAM nếu cho phép người dùng thực hiện chức năng ghi

2 Các khối có sẵn (Block RAM, DSP)

3 Các bộ đệm vào ra (kết nối với I/O PAD)

1 Các khối luận lý khả lập trình (CLB)

4 Các tài nguyên để kết nối (routing resources)

5 Các tài nguyên để tạo nhịp xung “clock” hoạt động cho thiết bị(clock resources)

- 6 - Chẳng hạn như một 5-1 LUT có thể đóng vai trò là một bộ nhớ RAM 32-bit Như vậy

8 5-1 LUT có thể kết hợp lại để làm một bộ nhớ 32x8 Bộ nhớ được cấu thành từ việc kết hợp nhiều LUT được gọi là các bộ nhớ phân tán (distributed RAM) để phân biệt với block RAM là các tài nguyên bộ nhớ có sẵn Ngoài ra mỗi CLB bao gồm 1 thanh ghi (register) có thể được sử dụng như là latch, JK, SR, hay D flip-flop vốn được dùng phổ biến để thiết kế các mạch tuần tự (sequential logic) Trong mỗi CLB còn có các

“carry chain” để chuyên dùng cho việc thiết kế các phép toán số học như phép cộng

Hình 2-2 (a) cho thấy các thành phần cơ bản trong một CLB của một chip FPGA

Virtex-5 của Xilinx Trong các dòng FPGA mới hơn như Virtex-6, Virtex-7 thì cấu trúc 6-2 LUT được hiện thực như hình 2-2 (b) Thực tế thì hai 5-1 LUT được ghép lại thành một 6-2 LUT

Hình 2-2 Cấu trúc của một CLB

Thành phần chủ yếu thứ hai của một thiết bị FPGA là các khối tài nguyên thiết kế sẵn Đây là các tài nguyên bộ nhớ, gọi là block RAM và các khối chuyên dụng cho cách các xử lý tín hiệu số (DSP) hay toán học như các bộ nhân, chia Các block RAM có thể được lập trình để đóng vai trò là các bộ nhớ SP (Single Port) chỉ có thể hoặc đọc hoặc ghi tại mỗi thời điểm, hay DP (Dual Port) cho phép quá trình đọc và ghi có thể diễn ra đồng thời trên hai “port” khác nhau Ngoài ra còn có các logic đi kèm để có thể dễ dàng lập trình kết nối các block RAM thành các bộ nhớ lớn hơn, hay dễ dàng kết nối các block RAM với các mạch điều khiển thành một FIFO hoàn chỉnh Hình 2-3 minh họa cấu trúc một bộ DSP có sẵn trong thiết bị FPGA Xilinx

Hình 2-3 Cấu trúc của một tài nguyên DSP có sẵn

Các bộ DSP có sẵn đã được thiết kế tối ưu cho phép người dùng có thể trực tiếp thiết kế các hệ thống cần nhiều tính toán toán học đạt hiệu suất cao Các tài nguyên cấu thành một DSP có thể được cấu hình để sử dụng như các tài nguyên thông thường khi cần thiết Chẳng hạn như người dùng có thể sử dụng các bộ nhân (MULT) trong các DSP có sẵn làm bộ nhân trong các mạch được thiết kế bởi người dùng Tất nhiên, trong những trường hợp đó, hiệu suất thường không cao

Thành phần chính yếu thứ ba là các bộ đệm vào ra dùng để kết nối các thành phần bên trong với các cổng I/O (còn gọi là I/O PAD) cho phép FPGA giao tiếp với các thiết bị bên ngoài chẳng hạn như bộ nhớ SDRAM Các chip FPGA còn có sẵn các khối SERDES (ISERDES hay OSERDES) sử dụng trong việc thiết kế các chuẩn giao tiếp tuần tự tốc độ cao Thành phần thứ tư trong một chip FPGA là thành phần dùng để kết nối các tài nguyên với nhau Điều đặc biệt là các kết nối này có thể lập trình được cho phép có thể tùy biến thay đổi việc kết nối các khối luận lý với nhau khi thiết kế của hệ thống thay đổi Đây là một trong những đặc điểm nổi bật làm cho thiết bị FPGA rất uyển chuyển, tuy nhiên nó cũng là điểm có thể hạn chế tốc độ của các thiết bị FPGA so với các thiết bị ASIC vì cần phải sử dụng các tài nguyên kết nối có sẵn để kết nối các khối chức năng Ta không thể tùy ý lựa chọn kết nối như trong các thiết bị ASIC

“Routing” vì vậy thường là bài toán phức tạp trong thiết kế FPGA Cuối cùng, một bộ phận không thể thiếu trong thiết bị FPGA dù không được thể hiện rõ trong hình 2-1, chính là các tài nguyên để sinh ra nhịp xung clock từ clock tham khảo đầu vào

- 8 - (reference clock) và phân phối các tín hiệu clock này đến tất cả các thành phần mạch tuần tự trong toàn bộ thiết bị Cũng tương tự như các “routing resources” thì các tài nguyên này có thể tái lập trình Chẳng hạn như ta có thể dễ dàng thay đổi đầu vào của một MMCM (Mixed-Mode Clock Manager) để thay đổi tần số của clock đầu ra Tuy nhiên việc phải sử dụng các tài nguyên thiết kế sẵn để tạo và phân tán các tín hiệu clock làm cho hiệu suất của FPGA thấp hơn thiết bị ASIC nơi mà người dùng có thể phân tán các tín hiệu clock một cách “tự do” hơn

Ngoài năm thành phần cơ bản vừa trình bày, tùy thuộc vào nhà sản xuất, hay dòng sản phẩm mà các thiết bị FPGA có thể có thêm các khối chức năng có sẵn Chẳng hạn như chip FPGA XC5VFX70T của Xilinx có tích hợp sẵn một PowerPC Processor, trong khi chip XC5VSX240T có tích hợp sẵn 4 Ethernet MAC (Media Accessor Controller) [3]

2.1.2 Quy trình thiết kế và tái cấu hình truyền thống - tái cấu hình toàn bộ

Như đã đề cập ở phần mở đầu, điểm mạnh chính yếu của FPGA so với các thiết bị phần cứng dùng ASIC chính là tính uyển chuyển nhờ khả năng tái cấu hình Phần này sẽ sơ lược về quy trình thiết kế hệ thống sử dụng cách thức cấu hình toàn bộ phổ biến [4] Hình 2-4 (a) minh họa một quy trình thiết kế FPGA thông thường và hình 2-4 (b) ở bên phải minh họa chi tiết các các bước để “tải” hay là cấu hình một chip FPGA của Xilinx Cách thức cấu hình cho FPGA của một hãng lớn (như Altera) cũng tương tự

Hình 2-4 Quy trình thiết kế và tái cấu hình truyền thống

Có hai điểm cần lưu ý ở đây Một là ngoại trừ các bước thiết kế 1 và 2 phụ thuộc nhiều vào người phát triển hệ thống, thì các bước còn lại trong quy trình thiết kế hầu hết có thể được thực hiện tự động bằng các công cụ EDA (được cung cấp bởi các nhà sản xuất), người phát triển chủ yếu chỉ phải thực hiện việc xác lập các mục tiêu về tốc độ và ánh xạ các cổng I/O (trong nhiều trường hợp có thể tái sử dụng các ánh xạ mẫu của các nhà cung cấp board mạch chủ) Mỗi khi cần thay đổi hệ thống, người phát triển chỉ cần phải sửa thiết kế HDL, và sử dụng công cụ EDA để tự động lặp lại các bước

- 10 - một cách rất thuận tiện Điểm lưu ý còn lại nằm ở bước 6.1, đó là toàn bộ bộ nhớ cấu hình (configuration memory) phải được xóa trước khi tải bitstream mới xuống thiết bị

Vì vậy, toàn bộ hệ thống phải ngưng hoạt động cho đến khi dữ liệu cấu hình mới được tải vào hệ thống từ các thiết bị lưu trữ bên ngoài Cũng vì tính chất này mà cách thức tái cấu hình này còn được gọi là tái cấu hình tĩnh (static reconfiguration) Ví dụ như toàn bộ bitstream của thiết bị là 10Mb, tốc độ cấu hình là khoảng 10Mb/s (dùng Flash tốc độ cao) thì quá trình tái cấu hình tốn ít nhất là 1 giây (chưa kể cả “overhead” khác)

Việc phải tạm ngưng hoạt động trong 1 giây tuy nhiên lại là không thể chấp nhận trong các hệ thống an ninh đòi hỏi đáp ứng liên tục Quá trình truyền nhận dữ liệu cấu hình

“bitstream” chỉ được thực hiện qua các chuẩn giao tiếp bên ngoài cũng làm cho tốc độ tái cấu hình không cao vì các chuẩn giao tiếp này thường có tốc độ thấp

2.1.3 Quy trình thiết kế và tái cấu hình từng phần (TCHTP)

Các yêu cầu phần cứng đối với hệ thống hộ TCHTP

Để một hệ thống phần cứng hiện thực trên thiết bị FPGA Virtex-5 trở lên có thể hỗ trợ việc TCHTP thì hệ thống đó phải đáp ứng các yêu cầu chính sau

 Các clock buffer toàn cục (global clock buffer) hoặc các bộ sinh clock (DCM, PLL) phải nằm trong vùng tĩnh, tức là chỉ có thể được tái cấu hình toàn bộ

 Các “I/O PAD” thì cũng nên đặt trong vùng tĩnh, việc đặt trong vùng động sẽ đòi hỏi phải thỏa mãn khá nhiều yêu cầu phụ khác

 Những “timing critical path” cũng không nên đặt ở hai phân vùng khác nhau

 Một yêu cầu rất quan trọng đó là việc tách biệt (decoupling) các ngõ ra của vùng động với các vùng khác Trong quá trình tái cấu hình từng phần tất cả ngõ ra của các khối trong vùng động đang được TCHTP sẽ ở trạng thái luận lý bất định (underministic state) điều này có thể làm ảnh hưởng đến hoạt động của các khối khác Trong các thiết bị FPGA Virtex-4 trở về trước thì người dùng phải đặt các

“Bus Macro” là một “pritimive cell” của FPGA, điều này là tương đối phức tạp

Tuy nhiên trong Virtex5 trở lên thì yêu cầu này được giảm xuống bằng cách dùng một tính hiệu “enable” để cố định giá trị output của vùng đang được tái cấu hình từng phần Đồng thời người dùng được khuyên là nên “buffer” tín hiệu output từ vùng động Cuối cùng sau khi tái cấu hình xong, cần phải có “soft reset” để “reset” vùng đã được tái cấu hình xong về trạng thái khởi tạo ban đầu

Hình sau minh họa yêu cầu này

Hình 2-7 Các “logic” cần để “decoupling” vùng động PRR0 và các vùng khác

Control module (Static region) Module A

Module B (Static region or PRR)

- 15 - Điều cốt yếu ở đây là cần phải có một “Control Module” để sinh hai tín hiêu

“Prr0_Reconfig_Enable” và “Prr0_Reconfig_Reset” Trong quá trình PRR0 đang được tái cấu hình, “Prr0_Reconfig Enable” sẽ bằng 0, tín hiệu này được “AND” với

“Prr0_Out” trước khi được đưa vào Module B Chú ý là “Prr0_Out” không được truyền trực tiếp vào “mạch tổ hợp” trong Module B Sau khi tái cấu hình xong, thì

“Prr0_Reconfig_Reset” sẽ được tích cực để reset “Module A” nằm trong PRR0 về trạng thái khởi tạo sau đó “Prr0_Reconf_Enable” sẽ được gắn về giá trị 1 Hình ngay sau đây chi tiết các trạng thái của hai tín hiệu này Cần lưu ý là cổng AND trong hình cần phải được đặt trong vùng tĩnh hoặc trong module B Cổng OR phải nằm trong vùng tĩnh “DFF” ở trong hình là tùy chọn, vì việc thêm cổng AND có thể làm “delay time” giữa Module A và Module B tăng lên, nên việc thêm một tầng “DFF” là điều nên làm

Hình 2-8 Giá trị của tín hiệu Enable và Reset trong quá trình TCHTP PRR0

(1): Là khoảng thời gian trước lúc PRR0 được tái cấu hình (2): Là khoảng thời gian PRR0 đang được tái cấu hình (3): Là thời điểm PRR0 đã được tái cấu hình xong, nhưng đang được “Reset”

(4): Là thời điểm sau khi toàn bộ quá trình TCHTP và “Reset” đã xong, lúc này PRR0 sẽ có thể chứa một “Module A” mới

Ngoài ra còn có một số ràng buộc khác không được đề cập ở đây Chi tiết hơn có thể được tìm thấy ở UG702 của Xilinx [8]

Prr0_Reconfig_Enable Prr0_Reconfig_Reset

Chi tiết quá trình tái cấu hình Virtex5 và cấu trúc “bitstream”

Như đã trình bày ở đầu chương, tái cấu hình thiết bị FPGA về bản chất chính là việc lập trình giá trị của vùng nhớ cấu hình cho các LUT Vùng nhớ này được gọi là vùng nhớ cấu hình làm bằng SRAM Bitstream là một chuỗi byte nhị phân dùng để hướng dẫn thiết bị FPGA chuyển dữ liệu lập trình mới xuống vùng nhớ cấu hình Có hai thành phần chính trong bitstream là “lệnh” và “dữ liệu” Về cơ bản lệnh được dùng để xác định cách thức dữ liệu được đưa vào vùng nhớ cấu hình Ở đây cũng xin nhấn mạnh là vùng nhớ này được tổ chức dưới dạng “32-bit word”, tuy nhiên việc đưa bitstream từ thế giới bên ngoài (máy tính, bộ nhớ ROM, …) có thể được thực hiện bằng các chuẩn giao tiếp khác nhau có thể là chuẩn “serial 1-bit” như JTAG hoặc chuẩn parallel như SelectMap, tuy nhiên độ rộng bit không được quá 32

2.3.1 Các bước cơ bản của quá trình tái cấu hình FPGA

Trước khi đi vào tìm hiểu nội dung của bitstream, tác giả xin trình bày sơ lược về các bước trong một quá trình tái cấu hình được mình họa ở hình dưới đây [9]

Hình 2-9 Các bước lập trình thiết bị FPGA Virtex-5

Như hình vẽ chỉ rõ, có 8 bước lập trình chính, tuy nhiên 3 bước đầu là để khởi tạo thiết bị FPGA và là cần thiết đối với các kỹ sư làm board mạch, nó không liên quan bitstream vì vậy tác giả không chi tiết thêm ở đây

Bước 4 gồm hai bước chính, bước thứ nhất là xác định độ rộng bit của giao tiếp tái cấu hình trong trường hợp giao tiếp song song được sử dụng Xilinx hỗ trợ 8-bit, 16- bit hoặc 32-bit Điều này được xác định dựa vào mẫu nhận dạng bit-width được liệt kê trong bảng sau

Bảng 2-1: Mẫu nhận dạng “bit-width” tự động

0xFF 0xFF 0xFF 0xFF Dummy word

0xFF 0xFF 0xFF 0xFF Dummy word

0xFF 0xFF 0xFF 0xFF Dummy word

Cơ chế để thiết bị FPGA nhận dạng bit-width như sau

 Lúc đầu nó sẽ kiểm tra xem có 0xBB được ghi vào 7 bit cuối D[0:7] hay không

Nếu có và theo sau đó là 0x11 thì nó biết là 8-bit, nếu là 0x22 thì là 16-bit, nếu là 0x44 thì bit-width là 32 Nếu không phải một trong ba thì nó sẽ quay lại chờ xem chừng nào nhận được 0xBB và lập lại quá trình nhận dạng

 Sau khi đã nhận dạng được bit-width thì nó sẽ chờ để nhận “Sync word” Tùy vào bit-width đã đươc nhận dạng mà “Sync word” sẽ được nhận dạng khác nhau như bảng sau

Bảng 2-2: Mẫu nhận dạng “Sync word”

Bước 5 là bước để xác minh bitstream này có ID giống với ID của thiết bị FPGA đang được lập trình Nếu như ID không giống, thiết bị FPGA sẽ báo lỗi bằng cách bật cờ “ID_Err” và quá trình tiếp nhận bitstream sẽ bị dừng lại Thiết bị FPGA trên board mạch Net-FPGA là XC5VTX240T, có ID code là 0x0453E093 Bước 6 là bước chính thức mà các dữ liệu lập trình sẽ được chuyển vào bộ nhớ lập trình tại vị trí mong muốn, dữ liệu được truyền theo từng “frame”

Trong suốt quá trình nhận bitstream theo từng frame, thiết bị FPGA sẽ tính “CRC” cho chuỗi dữ liệu nhận được Sau khi toàn bộ dữ liệu được truyền xong, dữ liệu trong

- 18 - bitstream sẽ có 32-bit word “CRC check command”, theo sau bởi 32-bit CRC mong muốn Thiết bị FPGA sẽ so sánh giá trị này với giá trị tính toán xem có trùng không, nêu không trùng sẽ báo lỗi Toàn bộ các công việc vừa được trình bày là bước 7 của quá trình cấu hình Tương tự như bước 5, quá trình tái cấu hình sẽ bị dừng lại nếu có lỗi xảy ra

Sau cùng ở bước 8, bitstream sẽ bao gồm các “command” để hướng dẫn thiết bị FPGA khởi động quá trình hoạt động, chẳng hạn như lệnh để chờ cho các các xung clock được ổn định, khởi tạo các I/O

Tiếp theo, tác giả xin trình bày chi tiết cấu trúc của một “bitstream” Như đã đề cập ở mục 2.3.1, bitstream về cơ bản bao gồm các “lệnh” và theo sau “dữ liệu”, hay nói cách khác là bao gồm tập các “packet” Có hai loại “packet” như sau

 Packet loại 1: đây là packet dùng để đọc và ghi các thanh ghi bên trong thiết bị FPGA Cấu trúc một lệnh 32-bit cho packet loại 1 như bảng sau Các bit không được liệt kê là những bit dành sẵn (Reserved)

Bảng 2-3: Cấu trúc “lệnh” cho packet loại 1

Trường Ví trí Ý nghĩa Header type [31:29] Cố định bằng 001 (Packet loại 1)

Opcode [28:27] 00: Lệnh NOP (không làm gì cả)

Lệnh đọc thanh ghi 10: Lệnh ghi thanh ghi

Register address [17:13] Có tất cả 32 thanh ghi

Word count [10:0] Xác định số “data word” trong packet, vì chỉ 11 bit, nên tối đa là 2048 words Trong trường hợp số word trong một packet lớn hơn 2048 ta sẽ dùng packet loại 2

 Packet loại 2: đây là packet đi ngay theo sau packet loại 1, nó không có trường

“Register address” mà sẽ dùng “Register address” của packet loại 1 trước đó

Nó gồm hai trường như bảng sau

Bảng 2-4: Cấu trúc “lệnh” cho packet loại 2

Trường Ví trí Ý nghĩa Header type [31:29] Cố định bằng 010 (Packet loại 2)

Word count [26:0] Xác định số “data word” trong packet

- 19 - Bảng sau trình bày thứ tự các “word” trong một “bitstream” thông thường Chú ý là tùy vào những tùy chọn người dùng trong quá trình sinh ra bitstream mà cấu trúc cụ thể có thể có một vài khác biệt nhỏ

Bảng 2-5: Thứ tự các “word” trong một “full bitstream” thông thường

FF FF FF FF Dummy word … Tiếp tục lệnh ghi một số thanh ghi khác

00 00 00 BB Bus width detection word 30 00 20 01 Ghi vào thanh ghi "Frame

11 22 00 44 Bus width detection word 00 00 00 00 Vị trí frame tái cấu hình FF FF FF FF Dummy word 30 00 80 01 Ghi vào thanh ghi "Command"

FF FF FF FF Dummy word 00 00 00 01 Đây là command cho phép việc bắt đầu quá trình đưa dữ liệu vào "configuration memory"

AA 99 55 66 Sync words (Kết thúc bước 4) 20 00 00 00 NOP packet

20 00 00 00 NOP Packet 30 00 40 00 Ghi vào thanh ghi FDRI

30 02 00 01 Ghi vào "Warm boot-start" 50 1F 59 C0

Packet loại 2, xác đinh số "word" là 0x1F59C0 Vì lớn hon 2048 byte nên phải dùng Packet loại 2

00 00 00 00 Giá trị ghi … Ghi word 1

30 00 80 01 Ghi vào thanh ghi "Command" …

30 00 80 01 Ghi vào thanh ghi "Command" 30 00 00 01 Ghi vào thanh ghi CRC 00 00 00 07 Lệnh "reset" giá trị CRC C4 EC F3 FB Giá trị CRC mong đợi 20 00 00 00 NOP Packet

… Lặp lại các bước tương tự để đưa dữ liệu vào các frame khác 20 00 00 00 NOP Packet

30 02 20 01 Ghi vào thanh ghi "TIMER"

00 00 00 00 Tắt tất cả các timer

Các packet để hướng dẫn việc

"start-up" (Bước 7 của quá trình tái cấu hình)

30 01 20 01 Ghi vào thanh ghi "COR0 option"

00 00 35 E5 Cho phép việc kiểm tra CRC 30 00 80 01 Ghi vào thanh ghi "Command"

30 01 C0 01 Ghi vào thanh ghi "BOOST" 00 00 00 0D

DESYNC words Đến đây được hiểu là bitstream kết thúc Kết thúc bước 8

00 00 00 00 Gia trị thanh ghi 20 00 00 00 NOP Packet

30 01 80 01 Ghi vào thanh ghi "Device ID" 20 00 00 00 NOP Packet 04 53 E0 93 Đây là ID code của XC5VTX240T Kết thúc bước 5

Theo bảng trên ta dễ dàng nhận ra các điểm bắt đầu và kết thúc của các bước tái cấu hình từ bước 4 đến bước 8 đã trình bày trước đây Các hình ngay sau đây minh

- 20 - họa một góc nhìn khác của cấu trúc bitstream bằng cách dùng phầm mềm hiển thị nội dung bitstream dưới dạng mã hex

Hình 2-10 Phần đầu chứa sync-word của bitstream

Hình 2-11 Phần chứa ghi vào thanh ghi FDRI, theo sau là dữ liệu cấu hình

Hình 2-12 Phần chứa lệnh để kiểm tra CRC

Hình 2-13 Phần cuối cùng lệnh để “DESYNC”

- 21 - Chú ý là ở đây không đề cập đến “header” của bitstream Trong thực tế, bitstream sẽ gồm có header dùng để chỉ tên file, ngày tạo file, … Những phần này sẽ được loại bỏ bởi phần mềm và không được đưa xuống thiết bị FPGA

Về cấu trúc giống “full bitstream”, chỉ trừ ba điểm sau

 Một là trong “partial bitstream” sẽ không có nhiều bước để set các thanh ghi chỉ hướng dẫn việc “start-up” hoặc các thanh ghi xác định các tùy chọn, và đặc biệt là các thanh ghi ở bước thứ 7 của quá trình tái cấu hình từng phần

 Hai là “partial bitstream” chỉ gồm dữ liệu cấu hình cho các “frame” nằm trong vùng “PRR” cần được tái cấu hình Hai khác biệt này dẫn đến một điều là độ dài

“partial bitstream” thường nhỏ hơn và thời gian cấu hình sẽ theo đó nhỏ hơn Cụ thể hơn thiết bị FPGA Virtex 5 XC5VTX240T trên board Net-FPGA có tất cả

“50,112” frame cấu hình Mỗi frame có chứa 41 32-bit words Như vậy “full bitstream” sẽ có độ dài là 8218368 byte Giả định rằng số “word” trong “partial bitstream” là “n” và thời gian để nạp “full bitstream” là t(full) thì thời gian để nạp partial bitstream có thể ước lượng theo công thức sau, trong đó t(start-up) là thời gian để thực hiện bước 7 trong quá trình tái cấu hình toàn bộ

 Cuối cùng là trong “full bitstream ” việc kiểm tra CRC sẽ được thực hiện nhiều lần Trong khi đó ở “partial bitstream ” thì chỉ có một lệnh kiểm tra CRC cuối cùng bất chấp độ dài của bitstream Điều này làm giảm khả năng phát hiện lỗi

Về việc nạp xuống thiết bị “FPGA” thì “partial bitstream” có thể được nạp thông qua việc dùng cổng lập trình bên trong ICAP, bên cạnh việc dùng cổng lập trình bên ngoài Việc dùng cổng lập trình bên trong cho phép người dùng có thể nâng cao việc kiểm tra lỗi cho “partial bitstream ” nếu cần thiết bằng cách được minh họa trong hình sau [8]

Hình 2-14 Cách kiểm tra lỗi CRC trong quá trình nạp “partial bitstream” Ý tưởng ở đây là phần mềm sẽ chia “partial bitstream” thành nhiều phần, và tính CRC cho từng phần đó Sau đó phần cứng sẽ nhận và kiểm tra CRC, và gộp lại trước khi truyền vào ICAP Với cách tương tự, chúng ta cũng có thể nâng cao tính bảo mật bằng cách mã hóa “partial bitstream” và giải mã trước khi đưa vào ICAP Đây là những điểm mà chúng ta không thể làm được đối với “full bitstream”

2.3.4 Chi tiết giao tiếp “ICAP”

ICAP về cơ bản là một khối giao tiếp hiện thực sẵn (còn gọi là primitive) trong các thiết bị FPGA Virtex-4 trở về sau của Xilinx, có giao tiếp tương tự như cổng giao tiếp bên ngoài SelectMap Bảng sau mô tả các tín hiệu vào ra của khối “primitive” này [9]

Bảng 2-6: Đặc tả giao tiếp vào ra (I/O) của ICAP “primitive”

CLK 1 Ngõ vào Xung “clock”

CE 1 Ngõ vào 0: Cho phép đọc ghi

1: Không cho phép đọc ghi

WRITE 1 Ngõ vào 0: Tác vụ ghi (dùng để đưa “command” hoặc dữ liệu tái cấu hình vào thiết bị FPGA)

1: Tác vụ đọc (dùng để đọc dữ liệu cấu hình từ FPGA, trường hợp này được dùng để “debug”

I 8/16/32 Ngõ vào Dữ liệu ghi vào ICAP Tùy vào tham số đầu vào mà độ rộng có thể là 8, 16 hoặc là 32

O 8/16/32 Ngõ ra Dữ liệu đọc ra từ ICAP Tùy vào tham số đầu vào mà độ rộng có thể là 8, 16 hoặc là 32 Ngoài ra 8- bit cuối của ngõ ra này có thể được dùng để theo dõi trạng thái của quá trình TCHTP

BUSY 1 Ngõ ra Dùng trong tác vụ đọc

0: Dữ liệu ngõ ra “O” là tích cực (“valid”)

1: Dữ liệu ngõ ra chưa tích cực, cần phải chờ đến khi tin hiệu trở về 0 thì mới có thể đọc dữ liệu xuất ra

Tuy đặc tả tương đối đơn giản, có một số vấn đề gây khó khăn cho việc thiết kế khối điều khiển để đưa “partial bitstream ” vào ICAP Đầu tiên là việc “constraint timing” cho khối này không thể dùng các phương pháp “constraint” đồng bộ mà phải dùng “MAXDELAY” Người dùng vì vậy thường phải cần có “buffer” ở phần giao tiếp với ICAP để có thể hoạt động ở tốc độ cao

Tuy nhiên khó khăn nhất chính là việc “Xilinx” không có thư viện để mô phỏng khối này vì vậy trong quá trình thiết kế cần phải “debug” trực tiếp trên thiết bị

JTAG, SelectMAP

Sơ lược về hệ thống HR-AV

HR-AV là hệ thống quét virus tốc độ cao kết hợp giữa giải pháp phần cứng và phần mềm Hình sau mô tả kiến trúc của hệ thống [1]

Hình 2-17 Kiến trúc hệ thống HR-AV

Phần mềm (dựa trên phần mềm diệt virus mã nguồn mở ClamAV) và cơ sở dữ liệu virus được lưu trữ trên máy chủ Công việc so trùng mẫu virus với tập tin cần quét được “offload” xuống cho H/W hiện thực trên board Net-FPGA Hiện tại hệ thống thiết kế dựa trên phương pháp lập trình toàn bộ và công việc do phần cứng làm sẽ do phần mềm đảm nhiệm trong quá trình tái cấu hình

2.4.2 Hiện thực phần cứng của hệ thống

Hình sau mô tả kiến trúc phần cứng của hệ thống trước lúc được sửa đổi

Hình 2-18 Cấu trúc phần cứng của hệ thống HR-AV hiện tại

Khối chức năng “PCIe EP with DMA”, gọi tắt là DMA, là khối để thực hiện việc giao tiếp giữa phần cứng và phần mềm Khối này chuyển đổi các các gói tin chứa nội dung của các tập tin cần được quét virus thành chuẩn “AXI stream” Đây là chuẩn bus giao tiếp “point-to-point” rất phổ biến được định nghĩa bởi công ty ARM Khối này cũng sẽ nhận kết quả trả về từ “Scanner core” và chuyển ngược về lại phần mềm Nói về chuẩn “AXI Stream”, ở đây có “AXI Stream Master” viết tắt là “AXI-M” và “AXI Stream Slave” viết tắt là AXI-S AXI-M để chỉ nơi xuất phát của dữ liệu và AXI-S là để chỉ nơi tiếp nhận dữ liệu Trong phương thức giao tiếp này luôn luôn một đầu là AXI-M và đầu kia là AXI-S Ngoài ra khối DMA còn có một giao tiếp AXI-Lite Master với AXI-Interconnect module, việc này dùng để đọc và ghi các thanh ghi control nằm phân tán trong tất cả các khối chức năng khác

“Scanner core” là bộ phận xử lý chính của hệ thống Chức năng thiết yếu của khối này là so trùng mẫu để phát hiện virus Ngoài hai giao tiếp (interface) AXI-S and AXI- M để giao tiếp với khối DMA, khối này còn có AXI-M interface (tương tự như AXIS- M tuy nhiên cần phải có định vị địa chỉ và là kết nối hai chiều) để truy xuất bộ nhớ ngoài (External SRAM) thông qua khối “SRAM controller” Khối “SRAM controller” tương tự như khối DMA dùng để truy xuất đến thế giới bên ngoài FPGA Cụ thể trong trường hợp này là bộ nhớ SRAM được tích hợp sẵn trên board Vì cơ sở dữ liệu cho

PCIe EP with DMA Host IF (via PCIe Connector)

A X I- Lit e In te rc o n n e ct

- 28 - việc quét virus và bộ nhớ trên FPGA là có giới hạn nên bộ nhớ ngoài được sử dụng như là bộ nhớ đệm Khi cần, khối scanner core sẽ đọc cơ sở dữ liệu virus từ bộ nhớ ngoài và lưu vào bộ nhớ trong FPGA để thực hiện việc so trùng

Cuối cùng khối AXI-Lite interconnect là khối dùng để giải mã địa chỉ của yêu cầu truy xuất thanh ghi từ phần mềm Khối này sẽ gửi yêu cầu đến tất cả các khối còn lại, nhận kết quả trả về và cuối cùng gửi lại DMA module để truyền về cho phần mềm

2.4.3 Quy trình giao tiếp giữa phần cứng và phần mềm

Phần này trình bày tóm tắt về ý niệm giao tiếp giữa phần cứng và phần mềm cho việc quét virus Một “file” cần được quét virus được phần mềm chia làm nhiều

“block” và một block sẽ được chia nhỏ hơn nữa ra làm nhiều “packet” để gửi xuống phần cứng Phần cứng sẽ thực hiện việc quét virus và trả về kết quả tổng hợp cho toàn bộ “block” sau khi xử lý xong “packet” cuối cùng của một block, “packet” kết quả gọi là “scan result” Những công việc này được minh họa ở hình sau

Hình 2-19 Cách thức phân chia gói tin để giao tiếp giữa phần cứng và phần mềm

Nói cách khác giao tiếp chủ yếu giữa phần mềm và phần cứng nằm ở việc quét virus cho một block Điều này được thực hiện bởi hàm “cli_bbf_static_scanbuff” Hình sau là thuật giải giản lược của hàm này

Hình 2-20 Thuật giải giản lược của hàm quét một “block”

- 30 - Đầu tiên hàm này đọc và xử lý “block memory” để gửi tuần tự các “packet” từ đầu đến cuối Sau khi gửi xong, sẽ lắng nghe kết quả trả về Khi đã nhận được packet kết quả quét trả về từ S/W hàm này sẽ kiểm tra và trả kết quả về cho hàm gọi Đến đây, chúng ta có thể hỏi rằng làm sao phần cứng biết được đâu là packet đầu tiên, đâu là packet cuối cùng, nội dung của packet kết quả như thế nào, làm sao biết có virus hay không? Tất cả những câu hỏi này được trả lời bằng quy định là tất cả các packet đều gồm được bắt đầu bằng “Packet header” và “Packet data” như hình sau

Hình 2-21 Định dạng gói tin gửi từ phần mềm xuống phần cứng

Phần header luôn cố định là 8-byte và được thêm vào trong tất cả các packet Phần

“buffer info” là 24-byte và chỉ được thêm vào packet đầu tiên Phần “DATA” có chiều dài cố định là 1472 byte Packet cuối cùng có thể nhỏ hơn 1472, tùy vào kích thước thực tế của “file” cần được quét virus Chi tiết định dạng của 8-byte header như sau

Bảng 2-7: Chi tiết phần “header” của packet

HEADER[3:1] 3 bytes định danh gói tin, hệ thống hiện tại sử dụng giá trị cố định là

0xAECAFE HEADER[4] Byte xác định kiểu gói tin, hiện tại cũng được cố định là 0x1 HEADER[7:5] Byte xác định buffer ID, hiện tại cũng được cố định là 0xFFFFFF

HEADER[8] o Byte này dùng để xử lý trong trường hợp “packet” nhỏ hơn 64-byte

Vì phần mềm driver để truyền nhận gói tin sẽ tự động tăng chiều dài gói tin lên 64-byte nếu như nó nhận được yêu cầu truyền nhận gói tin nhỏ hơn 64-byte o [7:2]: 6 bits xác định kích thước phần DATA

 6'd0: Vùng DATA lớn hơn hoặc bằng 60 bytes

 6'd1-6'd60: kích thước DATA chính xác o [1]: Nếu bằng 1, thì đây là gói tin bắt đầu o [0]: Nếu bằng 1, thì đây là gói tin kết thúc

- 31 - Hình sau minh họa packet gửi từ phần cứng lên phần mềm

Hình 2-22 Định dạng gói tin kết quả từ phần cứng gửi lên phần mềm Độ dài của packet là cố định 20-byte, tuy nhiên thực tế phải gửi lên 64-byte, các byte [64:21] được phần mềm bỏ qua Phần “HEADER” sẽ giống như phần “HEADER” của packet được gửi từ phần mềm xuống phần cứng Phần kết quả có nội dung đơn giản như sau

 NO_SIG: 4bytes – số lượng virus phát hiện

 SIG_ID_i: 4bytes – ID của virus phát hiện

 SIG_OFFSET_i: 4bytes – vị trí phát hiện virus trong gói tin

LIÊN QUAN

Áp dụng TCHTP vào hệ thống phát hiện tấn công mạng (NIDS)

Năm 2010, Salvatore Pontarell và các cộng sự [11] áp dụng kỹ thuật TCHTP vào việc hiện thực hệ thống phát hiện tấn công mạng, IDS (Intrusion Detection system) trên board mạch NetFPGA (chip FPGA là Virtex-2) Hình sau mô tả kiến trúc của hệ thống

Hình 3-1 Kiến trúc hiện thực NIDS áp dụng kỹ thuật TCHTP

Giống như hệ thống quét virus, hệ thống NIDS thường dùng một tập các luật cho các tấn công mạng và so trùng gói dữ liệu đầu vào với các tập luật này (ở đây tác giả sử dụng tập luật Snort) để phát hiện xâm nhập Gói dữ liệu vào (thông qua cổng Ethernet 1Gbs) được phân loại và lưu vào một trong hai hàng đợi tùy thuộc vào việc sử dụng tập luật A hay tập luật B để so trùng Hai khối so trùng luật A và B chạy song song, đọc dữ liệu từ hàng đợi tương ứng của mình và so trùng và gửi thông báo đến “gate module” và cuối cùng “gate module” sẽ chuyển gói dữ liệu đến cổng “Ethernet 1Gbs” output nếu như không có bất thường, hoặc gửi cảnh báo đến S/W chạy trên máy chủ Hai khối so trùng A và B được hiện thực trên hai vùng PRR khác nhau Tất cả các vùng còn lại được đặt trong vùng tĩnh Một lưu ý ở đây là tập luật A và B có thể chứa các luật trùng nhau Khi cần thay đổi tập luật, chỉ cần tái cấu hình một trong hai khối so trùng luật Để giải quyết vấn đề đáp ứng liên tục, tác giả sử dùng bộ nhớ ngoài DRAM gắn với chip FPGA trên board NetFpGA Điểm mấu chốt là quá trình ghi vào hàng đợi hoạt

- 33 - động với tần số 125MHz (chu kỳ là 8ns), 64-bit bus, vì vậy đáp ứng 1Gbs cho việc tiếp nhận gói dữ liệu vào Tuy nhiên khối so trùng luật hoạt động ở tần số 133Mhz (chu kỳ là 7.5ns), 64-bit bus Nói cách khác, hàng đợi là FIFO bất đồng bộ Tốc độ tái cấu hình một PRR là vào khoảng 10ms, vì vậy cần khoảng 20Mbyte bộ nhớ ngoài để đảm bảo hệ thống vẫn có thể đáp ứng băng thông 1Gbs mà không bị mất dữ liệu NetFPGA có thể kết nối với 64MByte bộ nhớ ngoài, nên giải pháp này là hoàn toàn khả thi Với cách làm này việc tái cấu hình hệ thống là “trong suốt” với người dùng Ưu điểm của công trình này là:

 Đây là giải pháp tương đối đơn giản, dễ hiện thực

 Chỉ rõ số lượng luật có thể được hiện thực trên FPGA, và chi phí tài nguyên FPGA để hiện thực hai PRR (chiếm 32%)

Tuy nhiên nhược điểm là

 Bài báo cho rằng cách hiện thực này làm giảm tải diện tích (tài nguyên tiêu tốn), nhưng không có một chứng cứ hay kết quả kiểm định nào (chẳng hạn như giảm so với cái gì, với cách hiện thực nào thì hoàn toàn không được đề cập)

 Không đề cập đến cách thức hệ thống giao tiếp với máy chủ (host PC), mặc dù có vẻ như nó được thực hiện thông qua cổng giao tiếp PCI

 Thêm vào đó, kỹ thuật TCHTP cụ thể nào được sử dụng (embedded processor hay external processor) cũng không được đề cập

 Tổng FPGA “utilization” cũng không được đề cập, block RAM có được sử dụng làm bộ đệm hay không cũng không được làm rõ

 Băng thông là khiêm tốn do sử dụng board NetFPGA 1Gbs, nếu mở rộng lên 10Gbs và không có nhiều cải tiến thì cần bộ nhớ ngoài rất lớn

Áp dụng TCHTP vào hệ thống “virtual network”

Salvatore Pontarell và các công sự [12] công bố việc áp dụng thành công kỹ thuật TCHTP vào việc hiện thực hệ thống “virtual network” trong năm 2011 Đạt được cải tiến 20x về thời gian tái cấu hình (nếu tái cấu hình toàn bộ thì tốn 12s, trong khi đó chỉ tốn 0.6s cho việc tái cấu hình từng phần) Hình sau mô tả kiến trúc của hệ thống này

Hình 3-2 Kiến trúc hiện thực “virtual network” áp dụng kỹ thuật TCHTP

Hệ thống dùng board NetFPGA (Virtex-2), đạt băng thông 1Gbs Chip FPGA được phân làm 2 vùng PRR, mỗi vùng chứa một “HW virtual router” (thực chất là các

“forwarding logic” và các “forwarding table” dùng để quyết định việc chuyển một gói dữ liệu từ port đầu vào đến một port đầu ra) Toàn bộ các khối logic khác được đặt trong vùng tĩnh Không giống như giải pháp của Salvatore Pontarell [12] được trình bày ở trên, ở đây trong quá trình từng phần cho một PRR thì công việc được chuyển qua cho hệ thống phần mềm trên máy chủ, thông qua chuẩn cổng giao tiếp PCI Dữ liệu tái cấu hình được truyền xuống NetFPGA từ máy chủ thông qua cổng giao tiếp JTAG Sau khi quá trình tái cấu hình được thực hiện xong thì công việc được chuyển lại cho phần cứng Như vậy đây là giải pháp kết hợp phần cứng và phần mềm tương tự hệ thống HR-AV mà đề tài đang nghiên cứu

Ngoài ra khi một “virtual network” không còn được sử dụng và xóa khỏi hệ thống thì có thể tái cấu hình PRR bằng “blank image” Điều này làm giảm 16% năng lượng tiêu tốn trên chip FPGA Tác giả sử dụng “NetFPGA packet generator tool” [13] để

- 35 - đánh giá hiệu suất của hệ thống và dùng Xilinx XPower để ước lượng điện năng tiêu thụ trên chip FPGA Các tác giả cũng đã mở rộng cách hiện thực dùng NetFPGA với chip Virtex-5 dung lượng lớn hơn và có thể hiện thực được hơn 20 “virtual network”

(không đề cập rõ về số lượng PRRs) và thời gian tái cấu hình Ưu điểm của công trình này là:

 Đây là công trình đầu tiên được công bố về việc áp dụng TCHTP vào việc hiện thực “virtual network” trên FPGA

 Hệ thống được đặc tả rất chi tiết, kết quả kiểm định cũng cho thấy rõ được lợi điểm Đặc biệt là ngoài lợi ích về hiệu suất, thì giải pháp cho thấy được lợi ích trong việc giảm hiệu suất bằng cách khá đơn giản

Tuy nhiên nhược điểm là

 Quá trình đánh giá hiệu suất chưa đề cập đến vấn đề “latency” khi hệ thống được chuyển từ phần cứng sang phần mềm thông qua cổng PCI Đồng thời theo bài báo thì hiệu suất của phần mềm chỉ bằng 200Mbs (1/5 so với phần cứng) nhưng không nêu ra giải pháp khắc phục để có thể vẫn đáp ứng 1Gbs như bình thường, trong quá trình tái cấu hình hệ thống Trong một công trình khác không áp dụng TCHTP [14], tác giả đề nghị giải pháp sử dụng board mạch thay thế board mạch hiện tại trong quá trình tái cấu hình Tuy nhiên đây là giải pháp quá tốn kém do phải cần đến ba board mạch cho hệ thống

 “Utlization” cũng chưa cao chỉ dùng lại ở 68% Hơn thế nữa nếu hiện thực toàn phần thì số virtual network gần như có thể tăng lên gấp đôi so với tái cấu hình từng phần, hiệu suất tổng thể sẽ không tăng hoặc thậm chí giảm nếu quá trình tái cấu hình không diễn ra thường xuyên

Áp dụng TCHTP vào việc hiện thực mã hóa IPsec trên FPGA

Ở một công trình khác, Ahmad Salman, Marcin Rogawski và Jens-Peter Kaps [15] hiện thực hệ thống tăng tốc cho thuật giải mã hóa dùng trong giao thức IPsec, sử dụng board ML403 (tích hợp chip Virtex-4), đạt hiệu suất 600Mbs Kiến trúc của hệ thống này được thể hiện trong hình sau:

Hình 3-3 Kiến trúc hiện thực mã hóa IPSec áp dụng kỹ thuật TCHTP

Tương tự như hệ thống [12], hệ thống này sử dụng kết hợp giữa phần cứng và phần mềm Tuy nhiên điểm chính yếu ở đây là phần mềm được thực thi bởi

“Microblaze” processor nhúng trực tiếp bên trong chip FPGA Điều này giúp cho việc giao tiếp giữa phần cứng và phần mềm được thực hiện nhanh chóng ở ngay bên trong thiết bị mà không cần các giao tiếp bên ngoài vốn tốn nhiều thời gian Mặt khác chỉ một PRR được hiện thực và từng thời điểm nó sẽ chứa 1 PRM “IPSec co-processor” hiện thực cho 1 trong các giải thuật mã hóa (AES, SH256, hoặc MODEXP), điều này giúp giảm 34% diện tích so với hiện thực toàn phần cả 3 thuật giải cùng một lúc Các thuật giải mã hóa khác được phần mềm thực hiện Phần mềm chạy trên Microblaze cũng có nhiệm vụ tải các partial bit-stream chứa trong một thiết bị CF (Compact Flash) và cấu hình hệ thống thông qua ICAP Đây cũng là điểm khác biệt so với các hệ thống đã trình bày

- 37 - Giao tiếp giữa phần mềm và phần cứng được thực hiện khá đơn giản qua tập thanh ghi 32-bit Dữ liệu cần được mã hóa/giải mã được Microblaze ghi vào tập thanh ghi đầu vào, “IPSec co-processor” giải mã/mã hóa và trả kết quả vào tập thanh ghi đầu ra

Bên cạnh đó dữ liệu cần mã hóa sẽ được chứa trong 3 hàng đợi khác nhau (tương ứng với ba thuật giải) và dùng giải thuật “round-robin” để luân phiên xử lý dữ liệu Do chỉ có 1 PRR hiện thực một thuật giải tại một thời điểm, nên hệ thống phải tái cấu hình PRR mỗi khi chuyển việc xử lý sang một hàng đợi khác Và cũng vì vậy thông thường mỗi hàng đợi sẽ được xử lý cho đến khi nó trống hoặc là đã quá “time-slot” lập trình cho nó Để đảm bảo tính liên tục của hệ thống thì tác giả sử dụng phương pháp dùng bộ bộ nhớ ngoài (DDR) làm bộ đệm Để đạt được băng thông 600Gps trong mọi trường hợp thì cần bộ đệm có dung lượng 140MByte

Tăng tốc quá trình TCHTP dùng bộ điều khiển “ICAP” tốc độ cao

Như đã đề cập trong mục 2.1.3, quá trình TCHTP có thể được thực hiện với tốc độ cao thông qua cổng tái cấu hình bên trong “ICAP” Tuy nhiên “ICAP” về cơ bản chỉ là một module “interface” cần phải có khối điều khiển để có thể có thể đưa bitstream từ vị trí nó được lưu trữ (bộ nhớ ngoài hoặc bộ nhớ bên trong FPGA) vào khối ICAP Mục 2.3.4, cũng đề cập đến việc Xilinx có cung cấp một số “IP core” để điều khiển ICAP

Tuy nhiên những “IP core” đó còn nhiều hạn chế Do vậy có khá nhiều công trình nghiên cứu về việc thiết kế các “customimzed controller” để điều khiển ICAP nhằm đạt tốc độ tái cấu hình nhanh hơn

Tiêu biểu là công trình tăng tốc ICAP của Vilpin và Fahmy[16] Ý tưởng chính ở đây là tác giả thiết kế một DMA có độ rộng dữ liệu lên đến 256 và một bộ đệm bất đồng bộ giữa DMA với ICAP Về lý thuyết ICAP có thể hoạt động tối đa với xung clock là 100MHz, nhưng nhờ việc tách biệt miền “clock” mà tác giả có thể cho phép khối ICAP hoạt động lên đến 210MHz, với độ rộng dữ liệu là 32, tốc độ tái cấu hình tối đa có thể đạt là 800Mbytes/s Hình sau là kiến trúc tổng thể của ICAP controller trình bày trong công trình này

Hình 3-4 Kiến trúc hiện thực của “ICAP controller” tốc độ cao

Tuy nhiên để trả giá cho tốc độ cao, cần sử dụng nhiều tài nguyên hơn, trong đó cần dùng đến 8 “block RAM” Hơn nữa việc áp xung có thể làm cho việc tái cấu hình bị lỗi và hệ thống cần phải giảm tốc độ clock và thực hiện tái cấu hình lại Điều này có

- 39 - thể làm phức tạp việc thiết kế phần mềm Ngoài ra “partial bitstream” phải được lưu sẵn trong bộ nhớ DDR gắn với thiết bị FPGA Điều đó có nghĩa cần phải có khối điều khiển, mà cụ thể là “embedded processor” để truyền “partial bitstream ” từ vào DDR trước khi việc tái cấu hình diễn ra Vì vậy về tổng thể “latency” của việc tái cấu hình là thấp và vì vậy không phù hợp với các hệ thống áp dụng TCHTP để thực hiện

“resource time-sharing” hệ thống đã được trình bày trong mục 3.3

Một công trình mới hơn tập trung vào cân bằng giữa tối ưu hóa việc sử dụng tài nguyên và tăng tốc việc tái cấu hình [17] Partial bitstream được chứa trong “Flash Card” và “Microblze” được dùng đề điểu khiển việc đưa “Partial bitstream ” từ bộ nhớ

“Flash” vào “ICAP controller” Ở đây tác giả đánh giá tốc độ TCHTP ở mức hệ thống so với “IP Core” HW_ICAP của Xilinx Việc sử dụng “buffer” và “DMA” cho phép hệ thống có thể đạt tốc độ TCHTP lên 50MBs so với 8-10MBs trong trường hợp HW_ICAP được dùng Ở đây dù ICAP hoạt động ở 100MHz và độ rộng dữ liệu là 32- bit, nên về lý thuyết có thể đạt tốc độ 240MBs Tuy nhiên việc đọc bộ nhớ chỉ đạt tốc độ tối đa là 50MBs nên đó cũng là tốc độ TCHTP của toàn bộ hệ thống

Nghiên cứu các công trình rút ra được hai nhận xét quan trọng trong việc tăng tốc TCHTP dùng ICAP Một là cần phải thiết kế bộ đệm bất đồng bộ với khả năng DMA để có thể thay đổi tần số hoạt động của ICAP một cách độc lập với hệ thống và việc truyền nhận dữ liệu không cần sự can thiệp của CPU Hai là tốc độ TCHTP không chỉ phụ thuộc vào tốc độ của khối điều khiển ICAP hay là tốc độ của chính ICAP mà còn phụ thuộc rất lớn vào tốc độ truyền nhận “partial bitstream” từ nơi lưu trữ đến khối điều khiển ICAP Vì vậy việc dùng các giao tiếp tốc độ cao như PCIE hay Etherenet là hữu ích trong trường hợp “partial bitstream” được lưu trữ bên ngoài FPGA (chẳng hạn như PC hay server)

Tóm tắt các công trình khác

Ngoài các công trình có nhiều điểm tương đồng với hệ thống HR-AV thì có nhiều công trình áp dụng kỹ thuật TCHTP đã được tìm hiểu Phần này ngắn gọn tóm tắt các hướng tiếp cận và giải pháp của các công trình này Trong bài báo [18], các tác giả đã đánh giá việc hiện thực TCHTP trong các hệ thống xử lý tín hiệu số; để cho thấy được lợi ích lớn của giải pháp này, và những điểm cần khắc phục trong quy trình thiết kế Đặc biệt công trình công bố cách thức nâng cao tốc độ tái cấu hình từng phần thông qua ICAP bằng cách sử dụng DMA và tăng độ rộng bus Cụ thể so với giải pháp truyền thống tốc độ tái cấu hình nhanh nhất chỉ là 32.4Mbit/s, nhưng giải pháp này có thể đạt 560Mbit/s hoặc thậm chí là 2.8Gbs/s trong trường hợp độ rộng bus được nâng từ 8-bit lên 32-bit

Một hướng nghiên cứu khác liên quan đến TCHTP là việc đề ra các quy trình thiết kế phù hợp, hiệu quả để tận dụng sức mạnh của TCHTP mà không quan tâm đến một ứng dụng cụ thể nào [19] Một số báo cáo tập trung vào việc kiểm định các cách thức

TCHTP, mô hình hóa để ước lượng thời gian tái cấu hình từng phần dựa vào nhiều thông số như data-bus width, hay dung lượng của “partial bitstream”[20] Một công trình tập trung vào việc xây dựng các công cụ để tự động hóa, đơn giản hóa hay nâng cao hiệu quả so với các công cụ cung cấp bởi nhà sản xuất [21][22][23] Ở Việt Nam, có công trình áp dụng TCHTP để nâng cao tính bảo mật của hệ thống bằng cách mã hóa các “partial bitstream” [24], vừa được công bố trong năm 2014

Kết luận

Kỹ thuật tái cấu hình từng phần cho thấy nhiều ưu điểm vượt trội so với kỹ thuật truyền thống Nó làm gia tăng hơn nữa sức mạnh của giải pháp phần cứng dùng FPGA so với các giải pháp phần cứng khác Có nhiều báo cáo về các phương pháp, các công cụ hỗ trợ việc áp dụng kỹ thuật này vào các bài toán tổng quát Cũng có khá nhiều báo cáo khoa học áp dụng thành công kỹ thuật này vào hệ thống cụ thể gần với hệ thống

HR-AV Tuy nhiên, chưa có các báo cáo về việc áp dụng kỹ thuật này vào hệ thống chống virus máy tính

Kiến trúc hệ thống HR-AV đòi hỏi phải tái cấu hình toàn bộ thiết bị và chuyển công việc quét virus của phần cứng sang phần mềm trên máy chủ nếu muốn đảm bảo tính hoạt động liên tục của hệ thống Tuy nhiên điều này sẽ làm giảm hiệu suất của hệ thống và có thể dẫn đến các bộ đệm trong máy chủ bị tràn do sự suy giảm hiệu suất

Một số công trình nghiên cứu đề xuất giải pháp sử dụng chip FPGA thay thế trong quá trình tái cấu hình Tuy nhiên giải pháp này làm tăng chi phí thiết kế board mạch và tăng

“latency” của hệ thống do dữ liệu phải đi qua các mạch chuyển giữa chip FPGA hiện tại và chip FPGA tạm thời Do đó việc hiện thực TCHTP cho hệ thống HR-AV là một vấn đề mới, nhưng có tính khả thi và có ý nghĩa trong việc khắc phục hiệu quả đáp ứng liên tục của hệ thống

HIỆN THỰC HỆ THỐNG 4.1 Hiện thực phần cứng

Phần này trình bày tổng quan về kiến trúc phần cứng của hệ thống Hình sau là sơ đồ minh họa các khối chức năng chính của hệ thống

Hình 4-1 Kiến trúc hiện thực lõi kép hỗ trợ TCHTP Để giải quyết bài toán tái cấu hình mà vẫn đảm bảo quá trình hoạt động của phần mềm Tác giả quyết định lựa chọn giải pháp dùng lõi kép, mỗi “scanner core” sẽ nằm trong một vùng động Như vậy trong quá trình một “Scanner core 0” được tái cấu hình,

- 43 - thì “Scanner core 1” vẫn có thể quét virus và giao tiếp với phần mềm Ngoài việc thêm vào một “Scanner core”, các khối chức năng chính sau được thêm vào

 “Dis-patcher” là khối dùng để kiểm tra “Packet” gửi từ phần mềm và quyết định xem packet đó nên được truyền xuống “Scanner core 0”, “Scanner core 1” hay là module “ICAP controller” Ở đây cần chú ý module giao tiếp với phần mềm chỉ có một và không hề thay đổi và chỉ có một đường truyền từ module đó xuống “Dis-patcher”

 “ICAP Controller” là khối để nhận dữ liệu “partial bitstream” được gửi từ phần mềm tái cấu hình từng phần thông qua khối “Dis-patcher” Dữ liệu này cũng được gửi theo từng “packet” và có cấu trúc tương tự như “packet” gửi xuống cho “scanner core 0/1” và vì vậy giao tiếp giữa “Dis-patcher” và “ICAP controller” là “AXI Stream” Khối ICAP controller sẽ thực hiện việc xử lý packet theo quy định với phần mềm và ghi dữ liệu vào “Virtex-5 ICAP”, đây là khối có sẵn trong Virtex-5 FPGA như đã trình bày mục 2.1.3 Vì giao tiếp

“AXI-M” của “Dis-patcher” hoạt động ở 125-MHz, độ rộng data-bus là 256-bit, trong khi đó Virtex-5 ICAP chỉ có thể hoạt động tối đa 100MHz, độ rộng bus là 32-bit, khối này phải thực hiện việc chuyển đổi độ rộng bus, cũng như việc truyền nhận dữ liệu bất đồng bộ giữa hai miền “clock” khác nhau Khối này có giao tiếp “Configuration handshake” (đây là giao tiếp do tác giả quy định) với khối “DPR controller”, mục đích của việc này là ICAP controller chỉ được phép gửi dữ liệu xuống “Virtex-5 ICAP” khi nó được phép của “DPR controller” Đồng thời khi quá trình tái cấu hình đã được hoàn thành, khối này trả kết quả về cho khối “DPR controller”, đồng thời nó cũng gửi packet kết quả trả về cho phần mềm tái cấu hình Việc trả kết quả này hoàn toàn tương tự như việc

“Scanner core” trả kết quả về cho phần mềm

 “DPR (Dynamic Partial Reconfiguration) Controller” là khối có thể được xem như là khối quan trọng nhất để đảm bảo việc TCHTP không ảnh hưởng đến hoạt động quét virus Khối này nhận các packet gửi từ phần mềm thông qua khối

“Dispatcher”, lưu trữ nó trong bộ đệm và chuyển nó đến “Scanner core” 0 hoặc

“Scanner core” 1 khi và chỉ khi scanner đó đang không được TCHTP “DPR controller” còn nhận kết quả trả về từ hai “Scanner core” 0, 1, và trả về cho khối

“Collector” để cuối cùng được gửi về lại phần mềm Nếu như “packet” đầu tiên của một “block” được gửi đến một “scanner core” đang được TCHTP, thì “DPR controller” sẽ loại bỏ chúng hay nói cách khác là không ghi vào bộ đệm và không gửi tới khối tái cấu hình từng phần Điều này diễn ra hoàn toàn độc lập với khối “Disptacher”, hay nói cách khác “Dispatcher” vẫn hoạt động như thể packet đã được gửi đến nơi mong muốn Tuy nhiên DPR controller sẽ có bộ xử

- 44 - lý bên trong để tiếp tục theo dõi đến khi nào “packet” cuối cùng được nhận nó sẽ “thay mặt” “scanner core” trả kết quả về cho phần mềm Chỉ có điều packet ở đây là để báo cho phần mềm biết là nó đã “loại bỏ” toàn bộ “block” gửi xuống scanner Thêm vào đó, sau khi ICAP controller thông báo là quá trình TCHTP đã xong, thì “DPR controller” cũng sẽ thông báo cho phần mềm quét virus về việc này Tuy nhiên, việc gửi thông tin này tương đối khó hiểu Việc này sẽ được làm rõ hơn ở các mục sau Một chức năng quan trọng khác của khối này là sẽ theo dõi quá trình hoạt động của cả hai “scanner core” để thông báo cho

“ICAP Controller” biết được khi nào thì có thể tái cấu hình được một scanner core cụ thể DPR controller làm luôn nhiệm vụ “decoupling” cho các scanner theo yêu cầu đã nêu ra trong mục 2.2

 Chức năng của khối “Collector” tương tự như khối “Dispatcher” nhưng ở chiều ngược lại Nếu như “Dispatcher” về cơ bản là bộ 1-3 demux, thì “Collector” là 2-1 muxing Vì “DPR controller” đã gộp kết quả trả về từ hai ‘scanner core’ vào trong một giao tiếp AXI-M, nên “Collector” chỉ cần phân xử kết quả trả về từ

“ ICAP controller “ và từ “DPR controller”

Ngoài ra, khối “SDRAM controller” cũng cần phải được thay đổi để có thể chấp nhận việc truy xuất bộ nhớ từ cả hai scanner Cụ thể hơn là một bộ phân xử “round- robin” được đặt ở trong “SDRAM controller” Một điều nữa là AXI-Lite interconnect cũng được thay đổi để phần mềm có thể truy xuất vào các thanh ghi nằm trong khối

“ICAP controller” Điều này là khá đơn giản vì AXI-Lite interconnect là một IP-core có thể thêm, bớt số lượng cổng AXI-Lite chỉ bằng việc thay đổi tham số Về phương diện hiện thực dùng planAhead, thì hai scanner core được đặt trong trong hai vùng động (PRR) và tất cả các module còn lại nằm trong vùng tĩnh

4.1.2 Thay đổi trong quy trình giao tiếp giữa phần cứng và phần mềm

Việc thêm một lõi mà mục đích chỉ như là lõi dự phòng trong khi lõi kia được TCHTP thì lãng phí Hơn nữa việc hiện thực hai lõi, cộng với việc thêm vào các khối để điều khiển có thể dẫn đến hệ quả là mỗi lõi có thể phải hoạt động ở tần số clock thấp hơn hệ thống đơn nhân do tốn nhiều tài nguyên phần cứng hơn Do đó để tận dụng sức mạnh của cả hai lõi và đảm bảo hiệu suất của hệ thống ngay cả khi tần số hoạt động của một lõi có thể giảm xuống, cần phải thay đổi cách thức truyền gói tin từ phần mềm xuống phần cứng Như đã trình bày trong mục 2.4.3, giao tiếp giữa phần cứng và phần mềm trong hệ thống cũ chỉ nằm ở việc quét một block, để giảm thiểu thời gian cập nhật và “debug” phần mềm, tác giả quyết định cũng chỉ tập trung thay đổi hàm quét một

- 45 - block Tuy nhiên khác biệt là block này lại được chia nhỏ làm hai sub-block Mỗi sub- block sẽ được giao cho mỗi “scanner core” để quét virus Đối với mỗi “scanner core” điều này giống như là phải quét một block có độ dài nhỏ hơn – việc này không cần bất cứ một thay đổi nào trong hiện thực của “scanner core” Đây là một điểm tốt của cách tiếp cận này vì thực tế “scanner core” cũng đang trong quá trình phát triển và hoàn thiện bởi một nhóm kỹ sư khác Hình sau minh họa việc chia một block ra làm hai block nhỏ và truyền xuống phần cứng

Hình 4-2 Thay đổi trong việc truyền gói tin xuống phần cứng lõi kép

Một lưu ý ở đây là việc gửi sub-block xuống phần cứng phải được thực hiện một cách xen kẽ (interleavingly) vì ở đây thực tế là chỉ có một đường truyền từ phần cứng xuống phần mềm thông qua cổng giao tiếp PCIe Việc gửi xen kẽ sẽ giúp cho quá trình quét virus của cả hai “scanner core” được diễn ra một cách song song và vì vậy hiệu suất sẽ cao hơn Cuối cùng vì cả hai “scanner core” đều quét một block, nên sẽ có hai kết quả trả về Phần mềm phải lắng nghe trên đường truyền để tiếp nhận cả hai gói kết quả, tổng hợp lại và trả kết quả về Vì cấu trúc kết quả cũng không hề thay đổi vì vậy toàn bộ các hàm chức năng khác của phần mềm cũng không cần phải thay đổi Đây là một lợi ích nổi bật khác của cách tiếp cận này so với một cách khác, chẳng hạn như là việc sử dụng kỹ thuật “multi-threading” trong phần mềm để chia công việc quét virus ra làm hai “thread” khác nhau, mỗi thread giao tiếp với một “scanner core” Việc dùng kỹ thuật “multi-threading” đòi hỏi phải thay đổi lớn về mặt cấu trúc của phần mềm và vì vậy khả năng phát sinh lỗi cao hơn

DPR Controller

Chi tiết hiện thực khối “ICAP Controller”

Đây là khối dùng để tiếp nhận dữ liệu tái cấu hình được gửi từ phần mềm Dữ liệu được tiếp nhận thông qua chuẩn giao tiếp chuẩn AXIS Đây là điểm khác biệt của module này so với module hiện thực chức năng tương tự trong các hệ thống khác, và các IP Controller IP của Xilinx Hình sau là cấu trúc của khối này

Hình 4-10 Cấu trúc của “khối con” “ICAP Controller”

Ngoài việc hỗ trợ tiếp nhận dữ liệu thông qua giao tiếp “AXI Stream” thì module này còn cho phép việc TCHTP thông qua “debug” mode để đưa bitstream đến ICAP Primitive thông qua việc đọc và ghi thanh ghi Nó cũng hiện thực thanh ghi

EXT_DPR_CTRL0, EXT_DPR_CTRL1, và EXT_DPR_STAT để giúp phần mềm có thể sử dụng quá trình TCHTP thông qua cổng giao tiếp bên ngoài như JTAG mà vẫn đảm bảo có thể “nói chuyện” với “DPR Controller” như là trong trường hợp “ICAP” được dùng Với khả năng này “DPR Controller” có thể hoạt động mà không cần quan tâm là quá trình tái cấu hình thực sự được thực hiện bằng phương thức nào Chi tiết

(8) Control FSM (2) Data- bus converter

(5) Register slice Dispatcher AXI-Lite Interconnect p rp _ re q p rp _ c o re p rp _ a c k p rp _ d o n e p rp _ e rr

- 63 - hiện thực của thanh ghi này được trình bày trong bảng sau Chú ý là địa chỉ “base” để truy xuất các thanh ghi trong ICAP controller là 0x20000000

Bảng 4-6: Đặc tả của thanh ghi dùng cho việc TCHTP dùng cổng JTAG

Tên thanh ghi Địa chỉ

(offset) Đặc tả các bit

EXT_DPR_CTRL0 0x04 Bit 0: “DPR REQ/DONE” bit

0  1: Gửi yêu cầu TCHTP 1  0: Thông báo là TCHTP đã thực hiện xong EXT_DPR_CTRL1 0x08 Bit 0: “DPR Core” bit

0: Chỉ định là việc TCHTP sẽ được thực hiện cho

1: Chỉ định là việc TCHTP sẽ được thực hiện cho

Bit này sẽ được lưu và gửi cho “DPR controller” khi EXT_DPR_CTRL0[0] thay đổi từ giá trị 0 lên giá trị 1

0: Thông báo là việc TCHTP đã thực hiện thành công

1: Thông báo là việc TCHTP đã có lỗi

Bit này sẽ được lưu và gửi cho “DPR controller” khi EXT_DPR_CTRL0[0] thay đổi từ 1 xuống 0

EXT_DPR_STAT 0x0c Bit 0: DPR ACK

0: Yêu cầu TCHTP chưa được chấp thuận 1: Yêu cầu TCHTP đã được chấp thuận Để điều khiển việc TCHTP dùng ICAP thì khối ICAP controller hiện thực các thanh ghi như đặc tả trong bảng sau

Bảng 4-7: Đặc tả của thanh ghi dùng cho việc TCHTP sử dụng ICAP

Tên thanh ghi Địa chỉ (offset) Đặc tả các bit trong thanh ghi

Vì việc TCHTP dùng ICAP có thể xảy ra lỗi và có thể làm hệ thống bị treo, nên cần hỗ trợ chức năng “SW reset” để phục vụ việc “debug”

[5]: Ghi “1” vào bit này để “reset” khối “ICAP controller”,

- 64 - ghi 0 để thoát khỏi “reset” Chú ý là phần giao tiếp thanh ghi không bị “reset”

[4]: Ghi “1” vào bit này để “reset” khối “Collector” , ghi 0 để thoát khỏi “reset”

[3]: Ghi “1” vào bit này để “reset” khối “Dispatcher”, ghi 0 để thoát khỏi “reset”

[2]: Ghi “1” vào bit này để “reset” khối “DPR Controller”, ghi 0 để thoát khỏi “reset”

[1]: Ghi “1” vào bit này để “reset” khối “Scanner core 1”, ghi 0 để thoát khỏi “reset”

[0]: Ghi “1” vào bit này để “reset” khối “Scanner core 0”, ghi 0 để thoát khỏi “reset”

Bit [6]: “Reserved” bit Bit [7]: “Enable statistics counter auto-clear” bit 1: Cho phép xóa các các “statistics counter” sau khi gói tin kết quả đã được gửi lên

0: Không cho phép việc tự động xóa Bit [8]: “Force enable core 0” bit

1: Cho phép enable core 0 bất chấp trạng thái của “DPR controller”

0: Việc enable core 0 được quyết định bởi “DPR controller”

Bit [9]: “Force enable core 1” bit

1: Cho phép enable core 1 bất chấp trạng thái của “DPR controller”

0: Việc enable core 1 được quyết định bởi “DPR controller”

Bit [10]: “Force disable core 0” bit

1: Cho phép disable core 0 bất chấp trạng thái của “DPR controller”

0: Việc disable core 0 được quyết định bởi “DPR controller”

Bit [11]: “Force disable core 1” bit

1: Cho phép disable core 1 bất chấp trạng thái của “DPR controller”

0: Việc disable core 1 được quyết định bởi “DPR controller”

Bit [12]: “ICAP AXI stream loop-back” bit

1: Gói tin gửi xuống ICAP controller sẽ được gửi ngược trở lại, dữ liệu sẽ không được chuyển xuống ICAP

0: Gói tin gửi xuống ICAP controller sẽ được xử lý và đưa xuống ICAP

Bit [23:16]: Xác định giá trị “source port” trong gói tin gửi về phần mềm

Bit [31:24]: Xác định giá trị “destination port” trong gói tin gửi về phần mềm

0: Không cho phép chuyển bitstream xuống ICAP 1: Cho phép chuyển gói tin xuống ICAP

Bit 1: “DPR Mode” bit 0: Debug mode (truyền bitstream thông qua AXI-Lite) 1: AXI-Stream mode (dữ liệu sẽ truyền theo dạng gói tin) ICAP_

0x38 Bit 8: “Debug write FIFO empty” bit

0: “Debug write FIFO” đã rỗng, toàn bộ dữ liệu đã được đưa xuống ICAP

1: “Debug write FIFO” không rỗng, vẫn còn dữ liệu chưa được đưa xuống ICAP

Bit [7:0] ICAP “O[7:0]” dùng để theo dõi trạng thái của quá trình TCHTP

[7]: “Configuration error” bit 0: Có lỗi xảy ra trong quá trình TCHTP 1: Không có lỗi xảy ra

0: Chưa nhận được “Sync word” Nhắc lại “Sync word là dùng để xác định độ rộng bit của ICAP như đã trình bày trong chương 2

1: Đã nhận được “Sync word”

[5]: “Readback is in progress” bit 0: Không có quá trình “readback” đang diễn ra 1: Quá trình “readback” đang diễn ra

[4]: “Abort is in progress” bit 0: Quá trình “abort” đang diễn ra 1: Không có quá trình “abord” đang diễn ra [3:0]: Bit dành sẵn, luôn luôn bằng 0xF ICAP_

0x24 Đây là thanh ghi dùng trong “Debug mode” Dữ liệu ghi vào thanh ghi này sẽ được lưu vào “Write FIFO” Đây là thanh

TEST0 0x20 Đây là thanh ghi chỉ để đọc, nó chứa thông tin về thời gian gần nhất mà “ICAP Controller” được thay đổi Ví dụ như giá trị 0x07011439 là để chỉ ra rằng lần gần nhất “ICAP Controller” được thay đổi là 14 giờ 39 phút ngày 1 tháng 7

Xây dựng môi trường mô phỏng và mô phỏng phần cứng

Việc đảm bảo cả hai “scanner core” có thể hoạt động cùng một lúc và việc thiết kế khối chức năng “DPR controller” đòi hỏi phải được kiểm định bằng phương pháp mô phỏng trước khi thử nghiệm trên thiết bị FPGA Ở đây các khối chức năng được đóng gói thành cái “IP-Core”, kết hợp với các “IP-Core” là các thư viện Sau đó dùng phần mềm “XPS” để sinh ra “netlist” của toàn bộ hệ thống “XPS” cũng sinh ra file

“system.v” là “Top” file chứa tất cả các IP-Core và các kết nối của chúng Hình sau minh họa môi trường mô phỏng dùng “ISE”

Hình 4-11 Cấu trúc “test-bench” của môi trường mô phỏng hệ thống

- 68 - Một cách lý tưởng thì ta cần phải dùng file “system.v” sau đó xây dựng “test- bench” để đưa dữ liệu “quét virus” hay “bitstream ” thông qua giao tiếp PCIE của

“system.v” Tuy nhiên điều này là rất khó vì giao tiếp PCIE là rất phức tạp Một khó khăn nữa là “IP-Core” AXI-Interconnect, ICAP, là các khối chức năng không thể mô phỏng Vì vậy tác giả cần phải thay đổi file “system.v” bằng cách cắt kết nối giữa khối

“PCIE EP DMA” và các khối chức năng khác, sau đó “dữ liệu được đưa trực tiếp” vào hệ thống thông qua giao tiếp AXI-Stream slave, và “theo dõi” kết quả trả về thông qua giao tiếp AXI-Stream Master của hệ thống Thêm vào đó một AXI-Interconnect model được viết và kết nối trực tiếp đến các cổng AXI-Lite để thực hiện việc đọc ghi thanh ghi Với cách này tác giả có thể kiểm định hoạt động việc quét virus, có thể gửi yêu cầu tái cấu hình để kiểm định hoạt động của “DPR controller” bằng cách gửi các yêu cầu TCHP thông qua việc đọc ghi thanh ghi vào ICAP controller Về ICAP controller, tác giả viết một “ICAP model” để mô phỏng hoạt động bitstream vào ICAP, và có thể kiểm định hiệu suất truyền nhận “bitstream” vào ICAP.

Hiện thực phần mềm

4.3.1 Qui trình của phần mềm quản lý TCHTP dùng “JTAG”

Việc gửi “partial bitstream” xuống thiết bị FPGA là cách làm đơn giản và đã được hiện thực bằng phần mềm iMPACT của Xilinx Việc TCHTP vì vậy có thể được thực hiện hoàn toàn giống như việc tái cấu hình toàn bộ, người dùng chỉ cần chỉ định đường dẫn đến “partial bitstream” được sinh ra bởi planAhead Tuy nhiên vấn đề ở đây là cần phải thông báo cho phần cứng bên dưới biết rằng việc tái cấu hình đang sắp diễn ra Vì vậy cần phải viết một chương trình bao hàm việc gọi phần mềm iMPACT để giao tiếp với phần cứng Hình sau minh họa hoạt động của chương trình này

Hình 4-12 Lược đồ hoạt động của phần mềm TCHTP dùng JTAG Đầu tiên phần mềm cần dùng thanh ghi EXT_DPR_CTRL1 để thông báo cho phần cứng biết là nó chuẩn bị dùng JTAG để TCHTP cho core 0 hay core 1 Sau đó ghi 1 vào EXT_DPR_CTRL0 để chính thức gửi yêu cầu TCHTP Chú ý là việc ghi vào thanh ghi EXT_DPR_CTRL1 phải được thực hiện trước việc ghi vào thanh ghi EXT_DPR_CTRL0 Tiếp đến là đọc thanh ghi EXT_DPR_STAT để biết là yêu cầu đã được chấp nhận hay chưa Việc đọc này phải được lặp lại chừng nào thanh ghi có giá

Write EXT_DPR_CTRL1[1] = 0/1 Write EXT_DPR_CTRL0[0] = 0

Call script to send partial bitstream using iMPACT software

Write EXT_DPR_CTRL1[0] = 0/1Write EXT_DPR_CTRL0[0] = 1

- 70 - trị là 1 Sau đó gọi “script” để nhờ phần mềm iMPACT chuyển “partial bitstream” xuống thiết bị FPGA Sau khi hoàn thành, phần mềm cần phải thông báo cho phần cứng bằng việc ghi vào thanh ghi EXT_DPR_CTRL1[1] Nếu việc TCHTP có lỗi thì ghi “1” vào bit này nếu không có thì ghi 0 Sau đó ghi 0 vào thanh ghi EXT_DPR_CTRL0 để thông báo cho phần cứng là quá trình TCHTP đã kết thúc

4.3.2 Qui trình của phần mềm quản lý TCHTP dùng “ICAP” Đầu tiên phần mềm có thể dùng thanh ghi ở “Debug mode” để đưa dữ liệu xuống ICAP bằng lược đồ sau Các bước kiểm tra “Sync-word” và “ID Code” là để theo dõi các bước cơ bản trong quá trình tái cấu hình đã được trình bày trong chương 2 Phần mềm có thể bỏ qua các bước này để tăng tốc quá trình TCHTP

Hình 4-13 Lược đồ hoạt động của phần mềm TCHTP dùng ICAP “Debug mode” Ở bước thứ 3, để đảm bảo việc truyền “dữ liệu” tái cấu hình tới một frame (thường là 41-words) một cách liên tục Đầu tiên, phần mềm có thể ghi 0 vào thanh ghi INT_DPR_CTRL để “disable” việc gửi dữ liệu xuống ICAP, sau đó ghi liên tiếp 41-

1 Read one word from bitstream and write to

2 Read one word from bitstream and write to

ICAP_DBG0 IDCODE word sent?

Report DPR error ICAP_CONFIG_

3 Read one word from bitstream and write to

ICAP_DBG0 Last word sent?

- 72 - words bằng cách dùng thanh ghi ICAP_DBG0, sau đó ghi “1” vào thanh ghi INT_DPR_CTRL để cho phép việc chuyển toàn bộ 41-words đã ghi xong xuống ICAP

Sau đó phần mềm có thể kiểm tra bit 8 của thanh ghi ICAP_CONFIG_STAT để biết xem là toàn bộ dữ liệu đã được ghi xuống ICAP hay chưa Quá trình này có thể lặp lại cho đến khi dữ liệu tái cấu hình cho toàn bộ các “frame” đã được đưa xuống ICAP

Bằng cách ghi giá trị 1 vào bit 1 của thanh ghi INT_DPR_CTRL, phần mềm có thể chuyển sang dùng giao thức truyền gói tin như trong phần mềm quét virus hiện hữu để chuyển gói tin xuống ICAP Với phương thức này phần mềm có thể gửi một gói tin có kích thước tối đa lên đến 1472-bytes xuống ICAP trong khi ở “Debug mode” chỉ có thể gửi 4-byte một lúc vì vậy tốc độ được kỳ vọng sẽ nhanh hơn hàng trăm lần Hình sau là các bước phần mềm cần làm để gửi partial bitstream xuống ICAP bằng cách thức này

Hình 4-14 Lược đồ hoạt động của phần mềm TCHTP dùng ICAP “Stream mode”

1 Read bitstream from start to SyncWord , form one packet, send to ICAP Controller

2 Read bitstream from start to IDCODE, form one packet, send to ICAP controller

3 Read bitstream, form one 1472-byte packet (at max), and send to ICAP controller

4 Listen to receive DPR status packet from ICAP controller, check DPR Err field

- 73 - Cũng giống nhưng trong “Debug mode”, phần mềm có thể bỏ qua các bước kiểm tra “Sync word” hay “IDCODE” khi không cần thiết Một điểm lưu ý nữa là ở bước thứ 4 phần mềm có thể lắng nghe gói tin kết quả hoặc cũng có thể đọc thanh ghi

“ICAP_CONFIG_STAT” để xác định xem quá trình TCHTP có diễn ra thành công hay không So với việc dùng “JTAG”, ở đây phần mềm không cần phải dùng các thanh ghi EXT_DPR* để giao tiếp với “DPR Controller” mà ICAP khi nhận dữ liệu tái cấu hình sẽ thực hiện việc giao tiếp với “DPR Controller”, đây cũng là điểm làm cho quá trình TCHTP có thể diễn ra nhanh hơn

4.3.3 Qui trình quét virus dùng lõi kép

Như đã trình bày sơ lược trong mục 4.1.2, cần phải có sự thay đổi trong cách thức quét virus để có thể dùng cả hai lõi quét virus và có thể đảm bảo tính đúng đắn và liên tục hoạt động khi một trong hai lõi được TCHTP Sự thay đổi này chỉ diễn ra trong hàm quét một “block” đó là hàm “cli_bbf_static_scanbuff”

Hình 4-15 Thuật giải của hàm quét một “block” dùng lõi kép và hỗ trợ TCHTP Ở đây phần mềm cần dùng hai biến là “DPR_Flag” và “DPR_Core” để ghi nhớ xem là quá trình TCHTP có đang diễn ra hay không và nếu có thì “scanner core” nào Để đơn giản có thể dùng biến toàn cục để lưu hai biến này nhằm ghi nhớ lại ngay cả khi hàm này kết thúc Lúc bắt đầu quét sẽ kiểm tra xem DPR_Flag nếu không thì sẽ làm các bước 1, 2, 3 để gửi dữ liệu xuống cả hai “scanner core” một cách xen kẽ và lắng nghe kết quả trả về Việc này đã được giải thích trong mục 4.1.2 Tuy nhiên một vấn đề là phần mềm TCHTP có thể đang chạy song song với phần mềm quét virus, và khi dữ liệu đã gửi xong, vì vậy cần phải kiểm tra gói tin kết quả xem có phải là gói tin

- 75 - kết quả bình thường hay là gói tin thông báo quá trình xử lý thất bại vì “scanner core” đang được TCHTP Nếu gói tin kết quả là bình thường thì đơn giản là đến bước 9 để trả kết quả về Vì ở bước 9 là chung cho tất cả các trường hợp nên ở bước này cần phải kiểm tra xem trong gói tin kết quả có thông tin là quá trình TCHTP đã được thực hiện xong hay chưa Nếu có thì sẽ gán giá trị 0 vào biến “DPR_Flag” Ở bước 3 nếu gói tin kết quả cho thấy là việc quét virus thất bại do một trong hai scanner core đang được TCHTP trong quá trình gói tin được gửi tới nó, thì phần mềm phải thực hiện các bước 4, 5, 6 để gửi lại dữ liệu của “sub-block” bị mất xuống

“scanner core” còn lại Phần mềm cần phải gán “DPR_Flag” bằng 1 và “DPR_Core” bằng 0 hoặc 1 tùy vào gói tin kết quả để ở các lần gọi hàm “cli_bbf_static_scanbuff” tiếp theo việc tái cấu hình từng phần sẽ được thực hiện bằng cách dùng một scanner core Đó là trường hợp mà ngay từ đầu kiểm tra thấy “DPR_Flg” bằng 1, phần mềm sẽ thực hiện các bước 7 và 8 Thực ra đây là thuật giải quét virus lõi đơn như trong hệ thống cũ Câu hỏi được đặt ra là nếu vậy khi nào hệ thống sẽ quay lại quét virus dùng lõi kép Câu trả lời là ở bước 9 như đã trình bày ở trên, phần mềm sẽ kiểm tra gói tin trả về và để cập nhật biến “DPR_Flg” nếu gói tin kết quả chứa thông tin thông báo là quá trình TCHTP đã xong

ĐÁNH GIÁ HỆ THỐNG 5.1 Đánh giá thời gian TCHTP

5.1.1 Tốc độ TCHTP dùng cổng giao tiếp JTAG Thời gian TCHTP phụ thuộc vào kích thước của partial bitstream như đã trình bày trong mục 2.3.3 Bảng sau là kết quả kiểm định thời gian TCHTP dùng cổng giao tiếp ngoài JTAG cho hai trường hợp khác nhau của cấu hình “partial bitstream”

Bảng 5-1: Thời gian TCHTP dùng JTAG với các kích thước bitstream khác nhau

STT Loại tài nguyên Số lượng

Ta dễ thấy rằng thời gian TCHTP tăng lên khi kích thước của vùng TCHTP tăng lên Tuy nhiên có thể thấy rằng là tốc độ TCHTP tăng lên khi kích thước bitstream tăng lên Điều này có thể giải thích là vì khi kích thước tăng thì ảnh hưởng của các bước khởi tạo (trong quá trình TCHTP đã trình bày ở chương 2) so với toàn bộ quá trình TCHTP là giảm đi.

5.1.2 Đánh giá tốc độ của “ICAP Controller” so với các công trình khácViệc dùng ICAP Controller giúp tăng quá trình tái cấu hình Về lý thuyết có thể đạt tốc độ khoảng 3.2Gbs (32-bit hoạt động ở 100MHz) Theo kết quả mô phỏng ICAP controller hiện tại có thể đạt được tốc độ xử lý 3Gbs ngay cả khi hoạt động song song với việc quét virus Môi trường mô phỏng giả định rằng các gói tin sẽ được truyền nhận và không bị “stall” vì tốc độ xử lý PCIE EP DMA có thể đạt tốc độ tối đa là 8Gbs Trong khi cả hai scanner core chỉ đạt 2Gbs Vì vậy giả định PCIE EP DMA có thể đáp ứng việc truyền gói tin xuống cả hai “scanner core” và “ICAP Controller” mà

- 77 - không bị “stall” là hợp lý Dẫu vậy điều này đòi hỏi phải đặt một số packet buffer Việc này sẽ được trình bày trong mục tiếp theo

Kiểm định trên board, nếu dùng “loop-back” mode thì tốc dộ truyền nhận của

ICAP controller cũng là 3Gbs Tuy nhiên khi dữ liệu tái cấu hình được truyền xuống ICAP thì ICAP báo lỗi “abort” Đây là một trong những điểm cần được khắc phục trong các đề tài tiếp theo

5.2 Đánh giá tốc độ quét virus và ảnh hưởng của kích thước “buffer”

Như đã trình bày trong mục 4.1.6.3, cần phải có “packet buffer” để lưu trữ dữ liệu vì tốc độ tiếp nhận dữ liệu của mỗi scanner core chỉ là 1Gbs, trong khi đó việc truyền nhận dữ liệu từ phần mềm xuống được “muxing” trong một kênh truyền duy nhất là PCIE EP Hình sau minh họa tốc độ quét virus của cả hai core với các cấu hình khác nhau của kích thước bộ đệm, đồng thời so sánh với việc quét virus chỉ dùng một core Ở đây tổng số “block” được kiểm định là 3000

Hình 5-1 Tốc độ quét virus với các cấu hình “packet” buffer khác nhau

Chú ý ở đây là “scanner core” được cấu hình hoạt động ở 125MHz, và về lý thuyết mỗi core sẽ đạt hiệu suất là 125*8(bit)=1 Gbs/s Ở đây nếu chỉ quét một core, ta đạt hiệu suất khoảng 0.96 Gbs là hoàn toàn hợp lý vì hiện tại phần mềm sẽ gửi gói tiếp theo khi và chỉ khi đã nhận kết quả trả về, và luôn có thời gian trễ giữa thời điểm

“scanner core” nhận xong một “block” và thời gian phần mềm thực sự nhận được kết quả trả về Thêm vào đó, ở mỗi gói tin ta cần phải thêm vào 8-byte “header” Việc chỉ mất 0.04 Gbs so với lý thuyết là kết quả rất khả quan

Tiếp đến về lý thuyết, cả hai scanner core sẽ đạt hiệu suất là 2Gbs Tuy nhiên kết quả thực tế thì tối đa ta có thể đạt được 1.86 Gbs Điều này cũng có thể giải thích là do các “overhead” trong xử lý gói tin- chia một block ra làm hai sub-block, và đặc biệt là việc dữ liệu gửi xuống hai “scanner core” đều thông qua một giao tiếp “PCIE EP”

Thêm vào đó thực tế là lúc số lượng “block” cần quét tăng lên nữa thì tốc độ quét virus

- 79 - của “hai core” cộng lại có thể đạt đến 1.92Gbs Ta sẽ quay lại phần này sau các phần đánh giá tiếp theo

Về kích thước buffer, ta thấy rằng nếu không có “buffer” thì tốc độ quét virus của cả hai “scanner core” sẽ gần như bằng một “scanner core” Tiếp đến một cách trực quan, do kích thước tối đa của “packet” gửi xuống phần mềm là (1472+32) nên một buffer có kích thước 1.5 KB là cần thiết, điều này cũng đã được kiểm định bằng mô phỏng Tuy nhiên thực nghiệm cho thấy ta chỉ cần có buffer có kích thước 1KB là cho kết quả tối ưu Minh chứng là “throughput” hệ thống là như nhau trong cả hai trường hợp kích thước “buffer” là 1 KB và 1.5 KB Điều này có thể giải thích là do trong quá trình mô phỏng ta không dùng khối “PCIE EP”, và trong khối đó có một số “buffer” để truyền nhận dữ liệu.

- 80 - 5.3 Đánh giá ảnh hưởng của TCHTP lên quá trình quét virus Ở đây tác giả chia việc đánh giá ra làm hai phần Đầu tiên là đánh giá ảnh hưởng trong trường hợp chỉ có hàm “cli_bbf_static_scanbuff” được chạy Tiếp đến là đánh giá ảnh hưởng trong trường hợp toàn bộ phần mềm quét virus được chạy

5.3.1 Đánh giá ảnh hưởng lên hàm “cli_bbf_static_scanbuff”

Hàm “cli_bbf_static_scanbuff” là hàm chính được thay đổi trong toàn bộ hệ thống phần mềm, đây cũng là hàm chiếm đến 80% thời gian xử lý của toàn bộ phần mềm

Chính vì vậy ảnh hưởng của quá trình TCHTP lên hàm này được đánh giá trước Để mô phỏng các hàm khác của phần mềm, thì tác giả đơn giản gọi truyền vào dữ liệu quét virus ngẫu nhiên từ 1 đến 255, kích thước của “block” là cố định từ 300KB, và dùng vòng lặp để mô phỏng việc quét nhiều “block” Đầu tiên phần mềm quét virus được bắt đầu, song song với đó là phần mềm TCHTP được bắt đầu Bảng sau là chi tiết kết quả quét virus 3000, 30000, và 300000 “block” song song với việc tái cấu hình một core

Bảng 5-2: “throughput” của hàm quét một block trong quá trình TCHTP một core

Số lượng block phải quét đơn nhân 678 1201 1171

Số lượng “sub-block” phần mềm phải gửi lại 1 1 1

Thời gian quét (us) 4945.733 41707.879 385597.969 Số lượng bit (kể cả header) 7414080000 74140800000 741408000000

“Throughput” (Gbs) trong trường hợp không có TCHTP

Ta thấy ảnh hưởng của việc tái cấu hình từng phần là rõ rệt khi khối lượng quét virus là nhỏ Tuy nhiên, điều này càng giảm khi hệ thống quét một khối lượng lớn tập tin Đi vào phân tích chi tiết, dựa vào số lượng block phải quét đơn nhân (do nhân còn lại đang được TCHTP), ta có thể tính toán về lý thuyết tốc độ quét virus sẽ là

+ P(TCHTP) là “throughput” hệ thống trong quá trình TCHTP + P là “throughput” quét dùng hai nhân

+ m là số block phải chuyển qua quét đơn nhân

+ x là số lượng “block” phần mềm phải quét lại, x chỉ có thể bằng 0 hoặc 1

+ n là tổng số block cần phải quét Áp dụng công thức này cho trường hợp quét 3000 “block”, n = 3000, thì

Kết quả thực nghiệm là 1,49Gbs, sai lệch ở đây là 10% Tương tự nếu ta áp dụng cho trường hợp gửi 300000 “block” thì “throughput” là 1,918994833, hay nói cách khác ở đây sai số so với thực nghiệm chỉ là 0,2% Cũng theo công thức này ngay cả khi m là vô cùng lớn thì “throughput” của hệ thống sẽ ít nhất bằng P * 0,5 Đây là ưu điểm nổi bật của giải pháp TCHTP đã được hiện thực

Với kiến trúc hệ thống hiện tại, thì cả hai “scanner core” là hai thể hiện của cùng một thiết kế Vì vậy trong thực tế thường khi cần thay đổi thuật giải cần phải tuần tự TCHTP cả hai vùng động chứa hai “scanner core” Bảng sau chi tiết kết quả thực nghiệm khi cả hai được tuần tự TCHTP

Bảng 5-3: “Throughput” của hàm quét một block trong quá trình TCHTP hai core

Số lượng block phải quét đơn nhân 2382 2338 Số lượng “sub-block” phần mềm phải gửi lại 2 2

Số lượng bit (kể cả header) 74140800000 741408000000

“Throughput” (Gbs) trong trường hợp không có TCHTP (không tính header)

KẾT LUẬN VÀ ĐỀ XUẤT

6.1 Những kết quả đã đạt được Luận văn đã hoàn thành xây dựng hệ thống hỗ trợ hai “scanner core” và áp dụng thành công kỹ thuật TCHTP cho phép thay đổi động thuật giải của mỗi khối chức năng

“scanner core” một cách tuần tự mà không hề làm ảnh hưởng đến tính đúng đắn và đạt 50% “through-put” nhờ vào việc dùng “scanner core” còn lại để quét virus Đồng thời hệ thống có thể quay trở lại hoạt động bình thường sau 6 giây nếu JTAG được dùng, và 9 mili-giây nếu ICAP được dùng

Luận văn đã hoàn thành việc thay sửa đổi giao tiếp một giữa phần mềm quét virus và phần cứng để phần mềm có thể tận dụng sức mạnh của cả hai scanner core mà chỉ cần thay đổi trong một hàm chức năng duy nhất của phần mềm Điều này đảm bảo tính đúng đắn và giảm thiểu rủi ro trong quá trình sửa đổi phần mềm Thêm vào đó việc hỗ trợ giao tiếp bất đồng bộ giữa “scanner core” nằm trong vùng động và các khối chức năng trong vùng tĩnh cho phép việc thay đổi sau này của “scanner core” sẽ không ảnh hưởng đến các phần khác và người thiết kế có thể dễ dàng lựa chọn tốc độ phù hợp với kiến trúc mới của “scanner core”

Luận văn đã phát triển phần mềm để hỗ trợ việc TCHTP thông qua JTAG hoặc thông qua ICAP Trong cả hai phương pháp, thuật giải quét virus vẫn không hề thay đổi đảm bảo một điều là thuật giải quét virus không phụ thuộc vào cách thức hệ thống được tái cấu hình Đây là điều quan trọng cho phép những sự mở rộng trong tương lai

Luận văn đã xây dựng “ICAP Controller” như một IP-Core, hỗ trợ giao tiếp “AXI Stream”, “AXI-Lite” điều này cho phép ICAP Controller có thể dễ dàng tiếp nhận

“partial bitstream” thông qua các giao tiếp “packet-based” như là Ethernet Vì vậy IP- Core này có thể được tái sử dụng trong các hệ thống liên quan

6.2 Hướng phát triển Đầu tiên tác giả đề nghị các cải tiến sau cho hệ thống hiện tại

 Hiện tại DPR Controller sẽ loại bỏ “packet” nếu như nó nhận được packet gửi đến cho một “scanner core” nằm trong vùng đang được TCHTP Phần mềm phải gửi lại gói tin Một giải pháp khác là thay vì “loại bỏ” thì phần cứng nên lưu trữ lại gói tin Vì gói tin có độ dài đến 300KB nên việc lưu trữ toàn bộ là không khả thi vì không đủ tài nguyên Nên tác giả đề nghị o Vẫn lưu vào “packet buffer” (chứa được một packet) Nếu đây cũng là gói tin cuối cùng, trường hợp này có thể xảy ra block đang quét là block cuối cùng của một file đang quét , hay file có kích thước nhỏ hơn 1.5KB

- 90 - Sau đó chờ cho “scanner core” còn lại xử lý xong, thì sẽ đưa gói tin vào nhờ scanner core kia làm công việc quét virus o Vẫn lưu vào “packet buffer” nhưng nếu tràn thì sẽ lưu vào “External SRAM” Vì vậy phải thêm giao tiếp với “SDRAM Controller”

 Khắc phục lỗi “abort” của ICAP controller Hiện tại ICAP controller chỉ hoạt động bằng mô phỏng ở 3Gbs mode Hiện thực trên board gặp lỗi “abort”

 Thay thế việc dùng “distributed” SRAM cho các FIFO bằng “block RAM” để giảm số lượng LUT cần dùng Hiện tại hệ thống chưa gặp vấn đề về tài nguyên nhưng trong trường hợp “scanner core” được nâng cấp thì có thể cần phải tối ưu hơn nữa

Về hướng mở rộng đề tài, tác giả đề nghị việc thêm vào “TEMAC”, “Ethernet Controller” để có thể giao nhận dữ liệu tái cấu hình từng phần thông qua cổng Ethernet (hiện tại đã có đến 4 cổng giao tiếp 10G) Việc dùng chung cổng PCI cho việc truyền nhận “partial bitstream” và dữ liệu quét virus có thể dẫn đến vấn đề tốc độ quét virus bị ảnh hưởng trong trường hợp scanner core có thể hoạt động nhanh hơn Phương pháp này cũng có thể cho phép việc sinh “bitstream” được thực hiện ở một máy tính từ xa có kết nối với FPGA thông qua cổng Ethernet

Tuy nhiên cần giải quyết hai vấn đề đó là vấn đề thiết kế “Ethernet Controller” và “ICAP Controller” Một điểm tốt là trên FPGA hiện tại đã có sẵn 4 “TEMAC” nên không hề tốn thêm tài nguyên cho khối này Vấn đề là phải thiết kế “Ethernet Controller” để có thể nói chuyện với “TEMAC” và “ICAP Controller”, đồng thời do việc truyền gói tin qua mạng có thể gặp lỗi hoặc bị tấn công nên “ICAP Controller” cũng cần phải được cải tiến bằng cách thêm vào các chức năng phát hiện lỗi như CRC hay giải mã một “partial bitstream” đã được mã hóa

DANH MỤC CÁC TÀI LIỆU THAM KHẢO

[1] T N Thinh, “Thuyết minh đề tài - Thiết kế hệ thống nhận dạng virus máy tính tốc độ cao kết hộp giải pháp phần cứng và mềm,” 2013

[2] Xilinx Corporation, “Partial Reconfiguration Tutorial - PlanAhead Design Tool (User Guide UG743),” 2012

[3] Xilinx Corporation, “Virtex-5 Family Overview (Product Specification DS100),” p 2, 2009

[4] Xilinx Corporation, “FPGA vs ASIC Design Flow”

Methodologies and CAD Tools for Dynamic Reconfiguration of Xilinx FPGAs (Invited Paper),” Proceedings of the IEEE Conference on Field Programmable

Logic and Applications (FPL), pp 1-6, 2006

[6] Simon Tam and Martin Kellermann (Xilinx Corporation), “Fast Configuration of

PCI Express Technology through Partial Reconfiguration (Application Note XAPP883),” 2010

[7] K P a D P Charalampos Vatsolakis, “Enabling Dynamically Reconfigurable Technologies in Mid Range Computers Through PCI Express,” HiPEAC

Workshop on Reconfigurable Computing (WRC), 2014

[8] Xilinx Corporation, “Partial Reconfiguration User Gude UG702,” 2010

[9] Xilinx Corporation, “Virtex-5 FGA Configuration User Guide UG191,” 2012

[10] Xilinx Corporation, “LogiCORE IP XPS HWICAP (v5.01a),” p 2, 2011

[11] C G E N S T a G B S Pontarelli, “Exploiting Dynamic Reconfiguration for FPGA Based Network Intrusion Detection Systems,” Proc IEEE Int', Conf Field

Programmable Logic and Applications (FPL), pp 10-14, 2010

[12] D U , Y L , L G , R T Dong Yin, “Customizing virtual networks with partial FPGA reconfiguration,” ACM SIGCOMM Computer Communication

- 92 - [13] G G J W L a G A Covington, “A packet generator on the NetFPGA platform,” Proceedings of the IEEE Symposium on Field-Programmable Custom

[14] e a T Katashita, “PGA-Based Intrusion Detection System for 10 Gigabit Ethernet,” IEICE Trans on Information and Systems, pp 1923-1931, 2007

[15] M R a J K A Salman, “Efficient Hardware Accelerator for IPSec based on Partial Reconfiguration on Xilinx FPGAs,” Reconfigurable Computing and

[16] S A F Kizheppatt Vipin, “A high speed open source controller for FPGA Partial Reconfiguration,” trong Field-Programmable Technology (FPT), Seoul, 2012

[17] A Traber, “Resource-efficient Dynamic Partial Reconfiguration on FPGAs,”

B , P C , B R , P G Philippe Manet, “An evaluation of dynamic partial reconfiguration for signal and image processing in Professional Electronics Applications,” EURASIP Journal on Embedded Systems, pp 1-11, 2008

[19] A G.-R C C a A George, “Design framework for partial run-time FPGA reconfiguration,” 17th IEEE Int'l Conf on Field Programmable Logic and

[20] A D S H K Papadimitriou, “Performance of Partial Reconfiguration in FPGA Systems: A Survey and a Cost Model,” ACM Transactions on Reconfigurable

[21] A J.-B a A Gordon-Ross, “Runtime Temporal Partitioning Assembly to Reduce FPGA Reconfiguration Time,” Proceedings of International Conference on

Reconfigurable Computing and FPGAs, pp 374-379, 2009

[22] S Y a A Gordon-Ross, “DAPR: Design Automation for Partially Reconfigurable FPGAs,” Proceedings of the International Conference on

Engineering of Reconfigurable Systems and Algorithms (ERSA), 2010

[23] D K a J T Christian Beckhoff, “Go Ahead: A Partial Reconfiguration Framework,” Field-Programmable Custom Computing Machines (FCCM), pp

[24] T H V N D P D S T C N.-V V C P N N Tran Thanh, “Enhance performance in implementing the security of partially reconfigurable embedded systems,” American Journal of Embedded Systems and Applications, 2014