Khóa luận tốt nghiệp Kỹ thuật máy tính: Thiết kế và hiện thực lõi IP JTAG cho vi xử lý MIPS 32-bit

TÓM TÁT KHÓA LUẬNTrong đề tài khóa luận này, nhóm sẽ trình các kiến thức liên quan đến kiểm tra, gỡlỗi phần cứng, kiến thức về giao thức JTAG và quá trình hiện thực giao thức JTAG.Trong

Tổng quan về giao thức JTAG và hệ thống gỡ lỗi trên phần cứng

Tổng quan giao thức JTAG 1 Lịch sử phát triển -22222-222222+22221122222112 22711 CcEEcce 6 2 Tổng quan về cách hoạt động của chuẩn giao tiếp JTAG 3 Kỹ thuật quét biên, phương pháp và cách thức kiểm tra

Giao thức JTAG là cách gọi ngắn gọn theo tên của nhóm tạo ra chuẩn giao thức này Tên chính thức của chuẩn này là “IEEE Standard Test Access Port and Boundary Scan Architecture” Trong đó, có hai nội dung chính được đề cập: e _ Nội dung về TAP quy định giao tiếp và hoạt động của TAP trên chip. ¢ Boundary Scan quy định một phương pháp và cách thức kiểm tra các kết nối bên trong chip và các chân trên bo mạch in.

Vào đầu những năm 1980, mạch in nhiều lớp, mạch tích hợp với số lượng chân lớn có dạng đóng gói ở dạng mạng lưới như ball grid array hoặc pin grid array và các bo mạch in có tích hợp số lương lớn linh kiện ngày càng phổ biến Do đó, khiến việc kiểm tra kết nối của chip trên bo mạch phức tạp, tốn nhiều thời gian và khó sử dụng phương pháp đầu dò (probe) thông thường.

Bên cạnh đó, tại thời điểm này, việc kiểm tra một bo mạch chủ yếu dựa vào hai phương pháp Bed-of-nails và kiểm tra chức năng (function test).

Bed-of-nails, tạm dich là “nền đỉnh” Phương pháp này kiểm tra bo mạch bằng cách đặt bo mạch cần kiểm tra lên trên nền đỉnh hay còn gọi là đầu dò, tiếp xúc trực tiếp với các điểm kiểm tra trên bo mạch để thực hiện việc kiểm tra.

Kiểm tra chức năng là việc kiểm tra khả năng hoạt động của một linh kiện bằng cách đưa các mẫu (giá trị) kiểm tra đến linh kiện cần kiểm tra và giám sát các đáp ứng từ linh kiện này Việc chỉ sử dụng hai phương pháp trên làm thời gian kiểm tra lâu, chi phí cao.

Năm 1985, tổ chức Joint Test Action Group được thành lập và bắt đầu phát triển một tiêu chuẩn giải quyết các van đề trên.

Giữa năm 1986 và 1988, Tiểu ban kỹ thuật JTAG (JTAG Technical Subcommittee) đã phát triển và công bố một nhóm các dé xuất về dang chuẩn của boundary scan.

Trong năm 1988, JTAG được quyết định sẽ trở thành nền tảng của một tiêu chuẩn trong họ Bus kiểm tra — Testability Bus và dự án P1149.1 được khởi động.

Vào tháng 2 năm 1990, chuẩn được phê duyệt lần đầu tiên và được tiếp tục chỉnh sửa, nâng cấp và hoàn thiện.

Tháng 6 năm 1993, phiên bản IEEE Std 1149.1-1193 được chấp nhận với những bộ sung thêm: e Hai lệnh tùy chọn CLAMP và HIGHZ. e Cơ chế cho phép chuyển đổi chế độ hoạt động của một thành phan

(component) tương thích chuẩn này sang một cơ chế DFT khác.

Thang 9 năm 1994, phiên bản IEEE Std 1149.1b-1994 được chấp nhận Ban này bổ sung thêm phụ lục về ngôn ngữ mô tả Boundary-scan (Boundary-Scan Description

Tháng 7 năm 2001, phiên bản IEEE 1149.1-2001 được công bó với nhiều quy định bổ sung giúp giảm rủi ro (risk), tăng tính linh động (flexibility) và hiệu quả khi thiết kế phần cứng cho boundary-scan trên chip.

Phiên ban mới nhất được sử dụng cho tới ngày nay là IEEE 1149.1-2013 Phiên bản này có nhiều bồ sung hơn so với các phiên bản trước đó: s Các lệnh mới của JTAG: CLAMP_HOLD, TMP_STATUS,

CLAMP_RELEASE, ECIDCODE, INIT_SETUP, INIT_SETUP_CLAMP, INIT_RUN, IC_RESET. e Phu luc C vé ngôn ngữ mô tả thu tục PDL (Procedural Description

Language), một ngôn ngữ mới ghi lại các yêu cầu về thủ tục và dữ liệu cho các lệnh mới. e Phụ lục D trình bày thêm các ví dụ cho BSDL và PDL khi sử dụng cùng nhau. e Phụ lục E đưa ra một số ví dụ pseudo-code về việc thực thi của lệnh iApply trong PDL, một lệnh phức tạp nhất trong các lệnh mới của PDL. ¢ Một số chỉnh sửa bồ sung khác.

2.1.2 Tổng quan về cách hoạt động của chuẩn giao tiếp JTAG

Mạch được ứng dụng trong chuẩn giao tiếp này cho phép các lệnh kiểm tra, gỡ lỗi và dữ liệu kiểm tra liên quan đến một thành phần nào đó trong mạch có thể được đọc ra sau khi có kết quả thực thi một lệnh Tất cả các thông tin nhận được (lệnh, dữ liệu kiểm tra và kết quả kiểm tra) thông qua giao tiếp nói tiếp.

Quá trình hoạt động của thiết kế JTAG được điều khiển bởi một thiết bị module gọi là bus master Thiết kế JTAG sẽ được điều khiển bởi hai tín hiệu TMS và TCK được kết nối với bus master Thiết kế sẽ hoạt động theo một trình tự nhất định và được mô tả như sau: e Đầu tiên, nạp dữ liệu nối tiếp cho một lệnh sẽ được thực thi dưới dạng nhị phân Quá trình lệnh được nạp nối tiếp vào thanh ghi lệnh (quá trình dịch lệnh vào thanh ghi) sẽ không ảnh hưởng tới các khối khác trong kiến trúc mà hoạt động của chúng sẽ bị ảnh hưởng khi quá trình này được hoàn tat. e Sau khi lệnh được nạp khối được chọn sẽ được cấu hình dé có thé phản hồi lại Tuy nhiên, trong một số trường hợp khối được chọn cần nạp dữ liệu trước khi đưa ra lại phản hồi chính xác Cũng tương tự với quá trình nạp lệnh, quá trình nạp dữ liệu cũng thông qua giao tiếp nối tiếp và quá trình này cũng không ảnh hưởng tới các khối khác trong mạch. © Sau khi thực thi xong lệnh kiểm tra và cung cấp các dữ liệu cần thiết cho khối được chọn Kết quả quá trình kiểm tra sẽ được kiểm chứng bằng cách dich nối tiếp dữ liệu đó ra ngoài và được bus master điều khiển dé nhận được dữ liệu đó.

Hoạt động của thiết kế JTAG (mạch kiểm thử) có thé được tiến hành bằng cách nạp và thực hiện một số lệnh khác theo cách tương tự như đã mô tả Và sẽ được kết luận bang cách trả lại quyền điều khiển từ mạch kiểm thử cho mạch hệ thống.

2.1.3 Kỹ thuật quét biên, phương pháp và cách thức kiểm tra

Kỹ thuật quét biên là một kỹ thuật liên quan đến tầng thanh ghi dịch (được chứa trong một thanh ghi boundary-scan cell) Do được chèn giữa mỗi chân I/O nên những tín hiệu tại các biên thành phần có thể được kiểm soát và quan sát bằng cách sử dụng phương pháp kiểm tra quét.

Trong Hình 2.1 là sơ đồ khối của một thanh ghi boundary-scan cell, thanh ghi này có thể được sử dụng cho kết nối đầu vào (input) hoặc đầu ra (output) của mạch hệ thống Nếu được sử dụng cho một đầu vào, dữ liệu vào có thể được nạp vào thanh ghi quét từ đầu vào thông qua công Signal-in và được lái vào từ thanh ghi thông qua cổng Signal-out của cell đến mạch hệ thống và tat cả quá trình nạp trực tiếp từ các luồng dữ liệu bên ngoài (kể cả thông qua việc nạp từ giao thức JTAG) đều phải dựa trên các tín hiệu điều khiển cho mach chọn (multiplexers) Tương tự như cho đầu ra của mạch hệ thống, dữ liệu đầu ra sẽ được nạp vào thanh ghi quét thông qua công Signal-in và được lái ra đâu ra từ thanh ghi thong qua công Signal-out Flip-flop thứ hai (thanh ghi sử dụng xung clock B) được dùng để giữ giá trị tín hiệu được lái ra ngoài cell khi đữ liệu mới được dich đến cell bằng cách sử dụng cổng Scan-in và Scan-out của flip-flop thứ nhất có xung clock A.

Hình 2.1: Thanh ghi boundary-scan cell [1]

Những thanh ghi boundary-scan cell cho các chân của một thành phần được kết nối với nhau để tạo thành một chuỗi thanh ghi dịch xung quanh cạnh của thiết kế. Đường kết nói này tạo này thành một chuỗi kết nói nối tiếp đầu vào và dau ra Với một sản phẩm được tạo thành từ các mạch tích hợp khác nhau, các thanh ghi boundary-scan của các thành phần riêng biệt có thể được kết nối thành một chuỗi, sơ dé trong Hình 2.2 mô tả kết nối của một thiết kế bo mạch khi tích hợp nhiều thành phần khác nhau.

Serial test =- System interconnect ZF

Hình 2.2: Kết nối thanh ghi boundary-scan của bo mạch tích hợp [1]

Tổng quan về hệ thông gỡ lỗi trên phần cứng

Hình 2.5: Bo mạch gắn chip cần kiểm tra hỗ trợ giao thức JTAG 2.2 Tổng quan về hệ thống gỡ lỗi trên phần cứng

Hệ thống gỡ lỗi trên phần cứng là một ứng dụng tiêu biểu của JTAG, nó giữ vai trò quan trọng trong việc kiểm tra, gỡ lỗi thiết kế vi mạch Hiện nay có rất nhiều hệ thống gỡ lỗi trên phần cứng đang được phát triển, một trong số đó được sử dụng biết đến nhiều như hệ thống gỡ lỗi được phát triển bởi ARM Hệ thống này được chia hệ thống chính DS — 5 (phần mềm) và DSTREAM (phan cứng), hầu hết các hệ thống gỡ lỗi khác cũng được chia thành hai hệ thong như hệ thống gỡ lỗi của ARM. 2.2.1 Phần mềm

Hệ thống phần mềm gỡ lỗi hiện nay thường được tích hợp trên một công cụ phát triển phần cứng cụ thê (Hình 2.6) Nó được tích hợp như là một tính năng gỡ lỗi trong số những tính năng phát triển phần cứng khác như: trình biên dịch cho hệ thống SoC, trực quan hệ thống giúp tối ưu hệ thống và phân tích hiệu suắt,

Hình 2.6: Giao điện phần mềm DS-5 Các công cụ này thường có các chế độ gỡ lỗi phần cứng như các công cụ phát triển phần mềm khác như: chế độ gỡ lỗi dựa trên chu kỳ, dựa trên sự kiện và dựa trên ích hoạt chéo giữa phần mềm — phần cứng Những chế độ đó cho phép người dùng tạm dừng xung hoạt động của thiết bị gỡ lỗi tại một thời điểm nhất định, thời điểm đó dựa vào đặc điểm chế độ hoạt gỡ lỗi mà người dùng thiết lập. © Chế độ gỡ lỗi dựa trên chu kỳ: chế độ này cho phép người dùng tạm dừng hoạt động của thiết bị gỡ lỗi tại xung hoạt động xác định mà người dùng thiết lập. e Chế độ gỡ lỗi dựa trên sự kiện: chế độ này cũng có chức năng tương tự nhưng với điều kiện tạm dừng là một sự kiện (hoặc điều kiện) nào đó xảy ra. Những sự kiện đó có thể được xem như là những phép so sánh toán học, khi thỏa điều kiện trong phép so sánh đó thì thiết bị sẽ được đưa vao trạng thái gỡ lỗi. © _ Chế độ kích hoạt chéo phần mềm — phan cứng: chế độ này có điểm nồi bật là sự phối hợp giữa hai hệ thống phần mềm — phan cứng Đề đưa thiết bị vào chế độ gỡ lỗi này cần phải thiết lập các điều kiện cho hai hệ thống và những điều kiện của hai hệ thống phải có liên hệ với nhau Khi điều kiện của hai hệ thống thỏa mãn thì thiết bị sé được đưa vào trạng thái gỡ lỗi.

Sau khi tạm dừng hoạt động của thiết bị gỡ lỗi thì thiết bị đó sẽ được đưa vào trạng thái gỡ lỗi Trong trạng thái này hệ thống phần cứng sẽ gửi dữ liệu cần quan sát ra ngoài hệ thống (PC — máy tính kết nói với hệ thống phan cứng) thông qua JTAG và được biểu thị trên hệ thông phần mềm.

Những hệ thống phần cứng hiện nay thường được thiết kế như một hệ thống SoC, hệ thống này cho phép lập trình đề điều khién thiết bị gỡ lỗi, giúp việc gỡ lỗi chính xác và nhanh hơn Thông thường thiết kế của hệ thống phần cứng bao gồm các thành phần như trong Hình 2.7.

Hình 2.7: Sơ đồ kiến trúc hệ thống phan cứng [4]

Sơ đồ kiến trúc trên bao gồm các thành phan như bộ xử lý (Processor) dé thực thi chương trình ứng dụng và chương trình gỡ lỗi, và bộ nhớ (Memory) lưu trữ chính của hệ thống.Ngoài ra còn có các thành phần khác với các chức năng tương ứng với tên của nó như CoreSight ECT (cung cấp cơ sở hạ tầng cho việc quan sát và gỡ lỗi), Protocol Agent Unit (giao thức xử lý giao tiếp khi hệ thống trong trạng thái gỡ lỗi), Circuit under Debug (CUD - thiết bị gỡ lỗi sẽ được đặt tại thành phan này) Bộ điều khiển (Debug Controller) là thành phan quan trọng nhất của hệ thống, được sử dụng để điều khiển các hoạt động gỡ lỗi của hệ thống Mỗi một thành phần được tích hợp trong hệ thống đều có thê giao tiếp với nhau thông qua AHB bus.

Khi hệ thống phần cứng trong trạng thái gỡ lỗi CUD được tạm dừng và dữ liệu trong các thanh ghi của CUD sẽ được truyền sang bộ điều khiển thông qua bus giao tiếp Dé có thể truy xuất vào dữ liệu của các thanh ghi trong CUD thì người thiết kế chèn một chuỗi các flip flop (thường gọi là chuỗi xử lý quét) Dữ liệu trong các thanh ghi được xuất ra thông qua chuỗi quét tới khối điều khiển và sau đó được truyền đến host — PC của người dùng thông qua giao tiếp JTAG.

Chương 3 Thiết kế tong quan

3.1 Mô tả tổng quan hệ thống

Dựa trên nhiều hệ thống gỡ lỗi khác nhau, cũng như kiến trúc hệ thống trong Hình 2.7 Nhóm đề xuất một sơ đồ hệ thống như trong Hình 3.1 :

~ CORE JTAGTAP Debug Module —m — MIPS 32-bit

Hình 3.1: Sơ đồ khối đơn giản của hệ thong gỡ lỗi Kiến trúc hệ thống gỡ lỗi bao gồm 3 thành phần quan trọng chính: e _ Khối JTAG TAP đóng vai trò chủ yếu trong việc giao tiếp với module bus master cũng như thực thi các lệnh gỡ lỗi. e Khối Debug Module được dùng dé điều khiển quá trình gỡ lỗi Ngoài ra, khối này còn dùng dé lưu các điểm dừng (breakpoint) và thực thi các tinh năng khác (single-step, breakpoint, ) của quá trình gỡ lỗi. © Khối hệ thống logic chính CORE MIPS 32-bit, thực thi một số chức năng của một vi xử lý và giao tiếp dữ liệu với JTAG TAP.

Hệ thống cung cấp một số thông tin gỡ lỗi cơ bản theo như Bảng 3.1 sau.

Bảng 3.1: Giới hạn thông tin gỡ lỗi

Thông tin cung | Nội dung

DEVICE ID Version[31:28] | PartNumber[27:12] | Manufacturer[11:1] | LSB[0]

SCAN DATA RESETI34] WrEn prc[33] | Halt[32] DATA[31:0]

Một số thông tin dữ liệu được cung cấp trong bảng trên giúp cho người dùng hệ thống hiểu rõ nắm bắt được một sé thông tin quan trong khi gỡ lỗi như dữ liệu của thanh ghi PC hoặc các thanh ghi khác trong tập thanh ghi.

3.2 Quy trình hiện thực hệ thống Để đảm bảo quá trình thiết kế không xảy ra gián đoạn hoặc bất cứ vấn đề khác Quy trình hiện thực thiết kế được xây dựng, bao gồm các bước như trong Hình 3.2.

Thiết kế sơ đồ khối cho toàn bộ hệ và các thành phan nhỏ khác của hệ thống Ỷ

Hiện thực thiết kế bằng ngôn ngữ mô tả phần cứng HDL

Tổng hợp thiết kế và hiện thực trên bo FPGA.

Hình 3.2: Sơ đồ quy trình thiết kế Để có thé hiện thực được hệ thống, đầu tiên nhóm hành thiết kế hệ thống theo những kiến thức đã nghiên cứu được, bằng cách vẽ sơ đồ khối từ các khối thành phần lớn tới các khối thành phần nhỏ nhất Tiếp đó là hiện thực thiết kế bằng ngôn ngữ mô tả phần cứng Verilog và SystemVerilog Sau khi hiện thực thiết kế hoàn tat và có được khối Top design, tiến hành mô phỏng chức năng của mạch Và cuối cùng là tổng hợp thiết kế và nạp lên bo FPGA.

Thiết kế JTAG chủ yếu giao tiếp với hai thành phần còn lại trong hệ thống, mô tả interface của thiết kế JTAG có thiết kế như trong Hình 3.3.

{Reg_addr[2:0], Instruction_i[31:0], Addr_Wr{10:0], Instr_run_direct[31:0], WrEn_proc}

{Force_brk_signl, Run_signl, Runstep_signl, Run_direct_signl, WrEn_db }

Hình 3.3: Interface của thiết kế JTAG TAP JTAG TAP giao tiép với module bus master bên ngoài thông qua các tín hiệu TCK,

TDI, TMS, TDO (hoặc có thêm tín hiệu TRST) Bên cạnh đó, các tín hiệu tại phía trên khối JTAG TAP giao tiếp chủ yếu với Core MIPS 32-bit Và các tín hiệu còn lại của khối này đưa ra các tín hiệu điều khiển cũng như cung cấp dữ liệu cho Debug module Bảng 3.2 mô tả chỉ tiết các tín hiệu của JTAG TAP.

Bảng 3.2: Chỉ tiết các tín hiệu của JTAG TAP Tín hiệu VO | Số bit Mô tả

TCK I 1 Xung clock của thiết kế JTAG.

TDI I 1 Dữ liệu đầu vào nồi tiếp của JTAG.

TMS I 1 Tin hiệu điều khién hoạt động của JTAG.

TDO lo) 1 Dữ liệu đầu ra nối tiếp của JTAG.

TRST I 1 Tin hiéu reset cho JTAG.

Scan_chain YO |n Số lượng bit tùy thuộc vào số I/O của Core

Data I 32 Dữ liệu đầu vào cho các thanh ghi của JTAG

Reg_addr oO 3 Dia chỉ dé đọc các thanh ghi tir MIPS.

Instruction_i Oo |32 Giá trị lệnh dé lưu lệnh trực tiếp vào bộ nhớ lệnh của MIPS.

Addr_Wr oO 11 Dia chi 6 nhớ để ghi lệnh vào bộ nhớ lệnh.

Instr_run_direct Oo 32 Giá trị của lệnh dé chạy lệnh trực tiếp.

WrEn_proc O 1 Tín hiệu điều khiên việc nạp lệnh.

BrkPnt_Addr oO 32 Giá tri breakpoint dùng dé lưu vào 6 nhớ chứa các địa chỉ breakpoint khác.

Addr oO 4 Dia chỉ dé lưu breakpoint vào 6 nhớ.

Force_brk_signl oO Tín hiệu điều khiển của lệnh FORCE_BREAK

Run_signl (6) Tin hiệu điều khién của lệnh RUN.

Runstep_signl oO Tin hiệu điều khién của lệnh RUNSTEP.

Run_ direct_ signl oO Tin hiệu điều khién của lệnh RUN_ DIRECT. WrEn_db Oo Tin hiệu điều khiển việc nạp breakpoint.

{Force_brk_signl, Run_signl, Halt_signl Runstep_signl, Run_direct_signl, WrEn_db}

Hình 3.4: Interface của thiết kế Debug module Ngoài các tín hiệu đã được kể trên, thiết kế Debug module còn có các tín hiệu giao tiếp với Core MIPS Debug module sẽ nhận các tín hiệu điều khiển từ JTAG TAP và giá trị của thanh ghi PC từ Core MIPS dé đưa ra các tín hiệu điều khiển hoạt động gỡ lỗi cho MIPS Hình 3.4 mô tả interface của thiết kế và Bảng 3.3 mô tả chỉ tiết các tín hiệu còn lại của Debug module.

Bảng 3.3: Chỉ tiết các tín hiệu của Debug module Tín hiệu 1O | Số bit | Mô tả

PC I 32 Giá tri của thanh ghi PC được nhận từ Core MIPS.

Run_direct_en | I 1 Tín hiệu điều khiển việc chạy lệnh trực tiếp được cung cấp từ JTAG TAP.

Halt_signl 1 1 Tín hiệu điều khiển việc ngắt hoặc tạm dùng Core

Chương 4 Thiết kế chỉ tiết

4.1 Thiết kế khối JTAG TAP

Thiết kế giao tiếp JTAG dựa theo chuẩn IEEE 1149.1 có sơ đồ kiến trúc tương tự như trong Hình 4.1. i Boundary Scan Cell h ' (Bsc) '

' ” h MIPS 32-bit 1 m ' Ị Lớn li ' i Tnput-'p——| — L Output —‘q’ '

! Device ID Register ' i (DR) š ' i User Data Register - h i 1(DR) > ị

| aR) i tap | Ị wm oat id "TAP Controller Ị

Hình 4.1: Kiến trúc tổng quan của thiết kế JTAG TAP Kiến trúc JTAG bao gồm các thành phần chính sau đây:

Các chân giao tiếp JTAG được gọi là TAP bao gồm các chân: TCK, TMS,

TAP Controller — bộ điều khiển chính của thiết kế Các tín hiệu điều khiển từ bus master sẽ được bộ điều khiển này nhận và tạo ra các tín hiệu điều khiển cho các thanh ghi và các thành phần khác.

Thanh ghi lệnh — IR, thành phan lưu trữ lệnh điều khiển của JTAG,

Tập thanh ghi dữ liệu - DR, bao gồm nhiều thanh ghi với các mục đích khác nhau. o BYPASS register là thanh ghi 1-bit, cho phép dịch dữ liệu bỏ qua chip cần kiểm tra. o DEVICE ID register là thanh ghi 32-bit dữ liệu, lưu thông tin của chip. o Boundary scan register — BSR, được dat tại vi tri giữa các ngõ vào/ra của core logic và các ngõ vao/ra của chip Mục đích chính của thanh ghi này là kiểm tra kết nối hoặc hoạt động của chip. o PRG COMMAND register là thanh ghi 43-bit (32-bit dit liệu cho lệnh được lưu vào bộ nhớ lệnh, 11-bit địa chi trong bộ nhớ) cho phép thực thi lệnh PRG_COMMAND. o READ REGS register là thanh ghi 35-bit (32-bit dữ liệu thanh ghi, 3- bit địa chỉ thanh ghi) cho phép thực thi lệnh READ_REGS. o BREAKPOINT register là thanh ghi 36-bit (32-bit dữ liệu breakpoint,

4-bit địa chi breakpoint) cho phép thực thi lệnh SET_BREAK. o FORCE BREAK register là thanh ghi 1-bit lưu giá trị của tín hiệu

Force_brk_signl. o RUN DIRECT register là thanh ghi 32-bit lưu giá tri lệnh chạy trực tiếp.

Thiết kế khối Debug module .-: ¿©22z++22v++vt2cvvvrvrrvvvrerrvez 46 1 Tổng quan thiết kế khối Debug module -: -z 2 46 2 Hardware Breakpoint Uni( 5-55: S++c+xcxeceeexsxerererscee 47 3 Debug Controller c5: 552cc stekekerererrerrrerree 48 Chương 5 Hiện thực thiết kế và nap thiết kế vào bo FPGA

4.2.1 Tổng quan thiết kế khối Debug module

Thiết kế của Debug module được chia làm hai khối chính theo như trong Hình 4.19.

Addr[3:0] Hardware Breakpoint Debug Controller

Run_signl Run_direct_sign!

Hình 4.19: Tổng quan thiết kế Debug module Khối Hardware Breakpoint Unit được sử dụng để lưu các breakpoint (tối đa 15 breakpoint) và thực hiện chức năng so sánh giá trị PC với giá trị của các breakpoint.

Khi giá trị của PC bằng với giá trị của một trong các breakpoint được lưu sẽ thì sẽ bật tích cực cho tín hiệu Break_signl.

Khối Debug Controller là một máy trạng thái, nhận các tín hiệu điều khiển từ Hardware Breakpoint Unit và JTAG TAP để cho ra các tín hiệu điều khiển phù hợp với chức năng của hệ thống.

Chỉ tiết thiết kế của khối Hardware Breakpoint Unit được biểu thị trong Hình 4.20.

Hình 4.20: Sơ đồ chỉ tiết của thiết kế Hardware Breakpoint Unit Thiết kế của Hardware Breakpoint được tổng hợp lại từ 2 thành phan chính: © Khối MEM 15x32 là một bộ nhớ với 15 ô nhớ, mỗi ô nhớ chứa dữ liệu có độ rộng 1a 32-bit Khối nay dùng dé lưu các breakpoint. ¢ Khối Comparator là một mạch tổ hợp so sánh bằng nhau dùng dé so sánh đồng thời giá trị của các breakpoint với giá trị của thanh ghi PC. ¢ Và công OR trong thiết kế sẽ cho biết tín hiệu Break_signl có được bật hay không khi có tín hiệu của Force_brk_signl hoặc có giá trị breakpoint trùng với PC.

Debug Controller là một máy trang thái có so đồ chuyển trạng thái hoạt động như trong Hình 4.21.

Break_signl= 0AND Run_direct_sign! = 0

| Halt_signl=0, CC Hai signl=0, —*> Hah signl=0,

\ Run_direct_en=0 / Run_direct_en = | Run_direct_en = 0

Run_signl= 1 Run_direct_sign! = 1 NON

L—— Hat signl= 1 tL yalt_signl=1, © Run_direct_en oe OT OUTPUT

Run_direct_signl Halt_signl

Hình 4.22: Sơ đồ khối thiết kế Debug Controller Hau hết các thành phần tuần tự trong vi xử lý MIPS hoạt động tích cực tại cạnh lên của xung clock và bộ điều khiển Debug Controller cũng hoạt động dựa trên xung clock của vi xử lý Vì vậy, dé có thê đồng bộ hoạt động điều khiển vi xử lý, máy trạng thái thay đổi trạng thái tại cạnh xuống của xung lock.

Máy trạng thái hoạt động nhờ các tín hiệu được gửi từ hai khối JTAG TAP và Hardware Breakpoint Unit Tại thời điểm ban đầu của hệ thống hoặc nhận được lệnh CORE_RESET từ JTAG, máy trạng thái sẽ ở trạng thái IDLE, khi giao thức

JTAG nhận được các lệnh gỡ lỗi như RUN, RUNSTEP thì máy trạng thái sẽ chuyển từ trạng thai IDLE sang trạng thái RUN hoặc RUNSTEP Tại trang thái RUN, vi xử lý thực thi chương trình và máy trạng thái chỉ thay đổi trạng thái sang

RUN DIRECT hoặc HOLD khi các lệnh như RUN DIRECT hoặc FORCE_BREAK được nhập Trạng thái RUNSTEP và RUN DIRECT có hoạt động tương đồng nhau, vi xử lý sẽ thực thi một xung lệnh và máy trạng thái sẽ chuyển sang trạng thái HOLD Trạng thái HOLD, sẽ không đổi khi các lệnh RUNSTEP, RUN_DIRECT, FORCE_BREAK vẫn còn lưu trữ trong thanh ghi lệnh của khối JTAG TAP và chỉ thay đổi sang trạng thái HALT khi một lệnh khác ngoài ba lệnh đó được nạp vào thanh ghi lệnh của khối JTAG TAP Và cuối cùng là trạng thái HALT, tạm dừng hoạt động của vi xử lý MIPS và chỉ cho phép hoạt động trở lại khi hệ thống được nạp các lệnh RUN, RUNSTEP, RUN_DIRECT.

Chương 5 Hiện thực thiết kế và nạp thiết kế vào bo FPGA

Mô phỏng hệ thống 22: +2¿2222+2EE221522222111122221122227111 E21 re 52

Trong thiết kế giao tiếp JTAG này xoay quanh chủ yếu vào việc kiểm tra thiết bị phần cứng Giao tiếp JTAG sẽ thực thi các lệnh bằng cách truyền nối tiếp các bit của lệnh thông qua TAP của JTAG, sau đó dữ liệu của thanh ghi mà lệnh đã nạp cũng được truyền nối tiếp thông qua TAP. Để kiểm chứng hoạt động của JTAG, một chương trình mô phỏng được xây dựng bằng ngôn ngữ SystemVerilog Phương pháp kiểm tra chủ yếu của chương trình nay đơn giản là thực thi từng lệnh của JTAG và xem xét kết quả có đúng với mong đợi hay không.

Môi trường mô phỏng được xây dựng đơn giản với các thành phần được miêu tả như trong sơ đồ Hình 5.1 dưới.

Top Driver quan sat tir Monitor testbench file DƯT z= _ i ~ |— Giao diện pur kết nổi

Hình 5.1: Môi trường mô phỏng

Môi trường bao gồm ba thành phần chính Top testbench file, chương trình mô phỏng và giao điện kết nối, trong đó:

Top testbench file là một file sv chứa tất cả các instance (chương trình mô phỏng, giao điện kết nối và DUT).

Chương trình mô phỏng là chương trình chính bao gồm các khối chức năng như Configure, Generator, Driver, Monitor.

Giao diện kết nối giúp kết nối DUT với chương trình trình mô phỏng bằng một giao diện cụ thé.

Các khối chức năng trong chương trình mô phỏng có chức năng gắn liền với tên của chúng như:

Khối Configure giúp cấu hình các biến, thuộc tính (số chân chip, các giá trị cần thiết khác) trong chương trình.

Khối Generator tạo ra giá trị của các lệnh.

Khối Driver điều khiển nạp các lệnh theo thứ tự mà khối Generator đã tạo vào DUT và điều khiển DUT thông qua TAP dé xuất đữ liệu ra Monitor.

Khối Monitor hiện thị kết quả mô phỏng sau khi thực thi từng lệnh trên cửa số Tel Console.

Quá trình kiểm tra thiết kế chủ yếu kiểm tra chức năng của JTAG thông qua các lệnh đã được định trước, quá trình này bao gồm 3 giai đoạn chính:

Giai đoạn 1: Kiểm tra toàn bộ lệnh mà thiết kế có thể chạy Tạo lập danh sách các lệnh có xuất hiện lỗi, những lệnh không xuất hiện lỗi sẽ được bỏ qua ở giai đoạn 2.

Giai đoạn 2: Kiểm tra các lệnh có xuất hiện lỗi bằng cách sử dụng các công cụ hỗ trợ quan sát dữ liệu được lưu trữ trong thanh ghi (các cửa số gỡ lỗi được tích hợp trong công cụ) Thông qua công cụ đó truy xuất ngược lại dữ liệu có lỗi qua từng khối của thiết kế và tiến hành sửa lỗi Sau khi sữa lỗi hoàn tat tiễn hành kiểm tra lại lệnh, nếu không còn xuất hiện lỗi thì qua kiểm tra lệnh khác, ngược lại nếu còn lỗi thì lặp lại giai đoạn này cho lệnh đó Sau

53 khi các lệnh đều đã được kiểm tra không phát sinh thêm lỗi thì bước sang giai đoạn 3. e Giai đoạn 3: Dựa trên các trường hợp thực tế có thể xay ra, tiến hành mô phỏng theo các trường hợp đó.

Các trường hợp thực tế có thể xảy ra và có thể mô phỏng trên trường hợp lý tưởng gồm 3 trường hợp: ¢ Trường hợp 1: Khi thiết kế chỉ có một giao tiếp JTAG Khi đó các lệnh có thể thực thi là BYPASS, IDCODE, SAMPLE Các lệnh đó cho phép kiểm tra dữ liệu một số thanh ghi (BR, DIDR, BSR). e Trường hợp 2: Khi thiết kế có nhiều giao tiếp JTAG (trong trường hợp này sử dụng 2 thiết kế để kiểm tra) Khi đó các lệnh sẽ được thực thi là PRELOAD, EXTEST Hai lệnh đó cho phép kiểm kết nối giữa các thiết kế với nhau Tại trường hợp này sẽ được chia thành hai trường hợp nhỏ, trường hop thứ nhất khi kết nói thành công (kết nói không bị đứt hoặc gián đoạn), trường hợp thứ hai là khi kết nối thất bại (có lỗi xảy ra tại điểm kết nối giữa hai thiết bị). ¢ Truong hợp 3: Kiểm tra hoạt động của vi xử lý MIPS với các lệnh gỡ lỗi

PRG COMMANDS, CORE RESET, RUNSTEP, READ REGS, FORCE_BREAK, SET_BREAK, RUN, RUN_DIRECT.

Quá trình mô phỏng được trình bày trên phần mềm Vivado, với mỗi trường hợp mô phỏng sẽ được giải thích trên Tcl Console va Waveform.

Như đã nói trước đó tại trường hợp này sẽ kiểm tra thực thi của các lệnh BYPASS,

IDCODE, SAMPLE Dưới đây là wave form của các lệnh Hình 5.2.

Dé có thé mô phỏng từng lệnh, trước tiên cần nạp giá trị của lệnh đó và thanh ghi

IR, sau đó có thể mô phỏng lệnh đó Quá trình nạp lệnh và chạy mô phỏng lệnh được điều khiển bởi ngõ vào tms.

Lệnh BYPASS trong Hình 5.2 bắt đầu thực thi tại thời điểm 15 ns và kết thúc tại

215 ns, với tổng số chu kỳ thực thi lệnh này là 20 chu kỳ Trong đó 10 chu kỳ đầu thực thi việc nạp giá trị lệnh BYPASS (giá trị lênh BYPASS là 4°b0000 từ chu kỳ từ chu kỳ thứ 5 tới chu kỳ thứ 8) vào thanh ghi IR thông qua ngõ vào tdi Từ chu kỳ thứ 5 tới chu kỳ thứ 8 tdo xuất ra dãy dé liệu nối tiếp là 0010, giá tri dữ liệu này chứng minh rằng kết nối giữa thanh ghi IR và TAP không gặp lỗi Và 10 chu kỳ còn lại là quá trình mô phỏng của lệnh, ở đây giá trị dữ liệu nối tiếp xuất ra tdo là 5°b10100 (từ chu kỳ thứ 13 đến chu kỳ thứ 19, từ LSB đến MSB), mỗi bit xuất ra từ tdo sẽ trễ 1.5 chu kỳ (trễ 0.5 chu kỳ là do tdo cập nhật giá trị mới tại cạnh xuống xung tck) tương ứng với việc lệnh BYPASS thực hiện bỏ qua thiết bị khi không cần kiểm tra thiết bị.

Tương tự như lệnh BYPASS, hai lệnh IDCODE và lệnh SAMPLE cũng bỏ ra 10 chu kỳ đầu cho việc nạp lệnh Hai lệnh IDCODE và SAMPLE lần lượt sẽ nạp dữ liệu nối tiếp là 4'b0001 và 4'b0010 Quan sát tại ngõ vào tdi từ chu ky thứ 5 tới chu kỳ thứ 8 trong khoảng thời gian thực thi lệnh.

Lệnh IDCODE bat đầu thực thi tại thời điểm 215 ns và kết thúc tại thời điểm 685 ns, tổng số chu kỳ là 47 chu kỳ Giá trị chứa trong thanh ghi DIDR là 32’b01000000000000000000000000000001, giá trị này sẽ được nạp vào DIDR mỗi khi nạp lệnh IDCODE Khi đó giá trị đó được xuất ra thành dãy dữ liệu nối tiếp thông qua tdo, có thể quan sát tại khoảng chu kỳ thứ 13 (345 ns) đến chu kỳ thứ 46

Lệnh SAMPLE bắt đầu thực thi tại thời điểm 685 ns đến thời điểm 1075 ns, tổng số chu kỳ là 39 chu kỳ Lệnh SAMPLE là một lệnh quét các chân của core logic, tuy nhiên thiết kế hiện tại không có một core logic cụ thể nên việc quét giá trị từ core logic sẽ được thay bằng việc nạp một giá trị cố định tương tự lênh IDCODE, giá trị đó là 24’b010000001 100000000001 100, 24 bit dữ liệu tương ứng với 24 chan I/O, trong đó 12 chân input và 12 chân output Có thé quan sát dãy dữ liệu nối tiếp nay tại chân tdo từ chu kỳ thứ 13 đến chu kỳ thứ 38. Để thuận tiện cho việc quan sát và kiểm tra thiết kế, Monitor có nhiệm vụ xuất ra màn hình Tel Console kết quả mô phỏng của các lệnh Dưới đây là Hình 5.3 kết quả xuất ra Tel Console của ba lệnh trên.

: $finish called at time : 1075 ns : File "E:/Subjects/DA2/pi restart

*) INFO: [Simtcl 6-17] Simulation restarted run all

: WARNING: Ons : none of the conditions were true for unique

: WARNING: Ons : none of the conditions were true for unique

| Serial Data When BYPASS 5 Times: 10100

| Scan data: 010000001100000000001100 §finish called at time : 1075 ns : File "E:/Subjects/DA2/py

Hình 5.3: Tcl Console trường hợp 1

Như đã trình bày ở trên kết qua sau khi thực thi tuần tự ba lệnh trên Lệnh BYPASS sau khi mô phỏng sẽ xuất ra Tel Console là “Serial Data When BYPASS 5 Times: 10100” Tương tự, Lệnh IDCODE và lệnh SAMPLE lần lượt là “DEVICE ID CODE: 01000000000000000000000000000001” va “Scan Data:

Như vậy, kết quả mô phỏng trường hợp 1 đáp ứng yêu cầu đối với từng lệnh và đặc tả thiết kế chung của giao tiếp JTAG.

Trong trương hợp này hai thiết kế sẽ được kết nối với nhau như trong Hình 4.11 và thực hiện mô phỏng hai lệnh PRELOAD và SAMPLE Như đã đề cập trước đó, hai lệnh này sẽ kết nối giữa hai thiết kế có xảy ra lỗi không.

Dé kiểm tra được kết nối giữa hai thiết bị trước tiên phải thực thi lệnh PRELOAD để nạp dữ liệu vào cell (thiết kế có cell output — thiết kế 1) có kết nối giữa hai thiết bị thông qua tdi, trong trường hợp 2 này thiết kế có tổng 12 chân I/O, 6 chân input và 6 chân output và thiết kế 1 kết nói với thiết kế 2 bằng cách kết nối 6 chan output của thiết kế 1va 6 chân input của thiết kế 2 Do đó, giá trị được nạp có độ rộng là 12 bit, tuy nhiên kết nối cần kiểm tra là giữa 6 chân output của thiết kế 1 và 6 chân input của thiết kế 2 cho nên 6 bit giá trị nạp có thể không cần quan tâm (có thể mặc định là giá trị không xác định) Sau đó thực lệnh EXTEST, lệnh EXTEST sẽ cho phép thiết kế 2 nhận vào giá trị vừa nạp cho thiết kế tại cell input của nó và sau đó xuất ra tdo và quan sát kết quả.

Cách thức kiểm tra đã được trình bày rõ ràng, tuy nhiên còn cần phải có phương pháp xác định kết nói có lỗi không Phương pháp này dựa vào việc nạp giá trị vào 6 cell output của thiết kế 1, tương ứng với 6 kết nói cần kiểm tra Cách thức nạp của phương pháp nay là nạp cho | cell giá trị 1’b1 và 5 cell còn lại là 5*b00000 và thực thi lệnh EXTEST, sau khi mô phỏng lệnh EXTEST hoàn thành, kiểm tra kết quả xuất ra tdo, và tương tự lặp lại 5 lần với giá trị Lbl tại vị trí cell khác và 5 cell còn lại giữ nguyên giá trị 5'b00000 Sau khi lặp lại 6 lần tương ứng với 6 kết nối cần

57 kiểm tra thì dựa vào kết quả thực thi 6 lần EXTEST đánh giá tình trạng kết nối của hai thiết kế.

Hình 5.4 dưới là waveform quá trình kiểm tra kết nối trong trường hợp kết nối không xảy ra lỗi.

Name Value 0 ne 309 ne 200 ne 200 ne 400 ne 500 ng 600 ne hee M [I|UUUUHHUIIHUUIIHHIUHHUIIHHIUHIHUUHILUIHIUIHIIUHIHUIUHUIIHHIUHHUIHUUIHIIUHHIIIHHIIUHD

Win 1 ves lo Lm FiLn FLFII In Lz J

== rons 60m 00 ns 3000 na ns 200 ẻ nhu x tek JIIIIIIIII[IIIIIIIIIIIUIIIIIIIIIIIUIIIIIIIIIIIUIUIIIIIIIIIIUIUIIIIIIIUUUIIIIIIIIIUIIIIIIIIIUUUIIIIIIIIIUUIIIIIIIUUIIIIIIUUIITIIIIUUUTINIIIILIUTIII

Name Value 2/00 ns 2,200 ns 2/300 ne 2,400 ng 2,500 ng 2,600 ng © 2,700ne #4

Win 1 Sa 2 lÐ veo lo im ma FLƑL Fl

|PRELOAD, EXTEST - 5 fe oes 000 ns]

Name value 2/800 ne ô2,900 ne 9,000 ng 9,100 ng 9,200 ng 3,900 ng 9,400 ng ORO ME id tok E JUIIIIIHLIUIIUIIUUUUIIIIIUUUIIIIIIUIUUUUIIUUUUIUILIUUIIUILIUIUIUIIUULIUUUIIIVILIUIIUUUILIUIIUUIIUILIUIUULILIIUIIUUIIIUIIUUILi

Ba 8 il ủ EL EI il we Ie vẹ_r ủừắủ ủ ry fi

Name Value 2,500 ne 2,600 ne 3,308 ne 3,800 ne 3,900 ne 4,000 ne 4,100 ne 4200 nề aa I

Bim 4 Lez Ll FLFI aA T]