Các trải nghiệm với phát triển theo hướng thử nghiệm (TDD) cho thiết kế logic (chip) trong Verilog hoặc VHDL

Question

Tôi đã xem trên web và các cuộc thảo luận/ví dụ dường như là để phát triển phần mềm truyền thống. Vì Verilog và VHDL (được sử dụng cho thiết kế chip, ví dụ như FPGA và ASIC) tương tự như phát triển phần mềm C và C++, nó có vẻ hợp lý. Tuy nhiên, họ có một số khác biệt về cơ bản song song và yêu cầu phần cứng để kiểm tra đầy đủ.

Trải nghiệm nào, tốt và xấu, bạn đã có? Bất kỳ liên kết nào bạn có thể đề xuất về ứng dụng cụ thể này?

Chỉnh sửa/giải thích: 10/28/09: Tôi đặc biệt hỏi về TDD. Tôi đã quen với việc thực hiện các băng ghế thử nghiệm, bao gồm cả các băng ghế tự kiểm tra. Tôi cũng biết rằng SystemVerilog có một số tính năng đặc biệt cho băng ghế thử nghiệm.

10/28/09: Các câu hỏi ngụ ý bao gồm 1) viết một bài kiểm tra cho bất kỳ chức năng nào, không bao giờ sử dụng dạng sóng để mô phỏng và 2) viết test/testbenches đầu tiên.

11/29/09: Trong Empirical Studies Show Test Driven Development Improves Quality chúng báo cáo cho (phần mềm) TDD "Mật độ khiếm khuyết trước khi phát hành của bốn sản phẩm, được đo là lỗi trên mỗi nghìn dòng mã, giảm từ 40% đến 90% so với các dự án không sử dụng TDD. Ban quản lý báo cáo mức tăng 15-35% trong thời gian phát triển ban đầu cho các đội sử dụng TDD, mặc dù các đội đã đồng ý rằng điều này được bù đắp bằng chi phí bảo trì giảm. " Các lỗi giảm làm giảm nguy cơ băng ra, tại các chi phí của tác động lịch trình vừa phải. This cũng có một số dữ liệu.

11/29/09: Tôi chủ yếu làm mã kiểm soát và datapath, không phải mã DSP. Đối với DSP, giải pháp điển hình liên quan đến mô phỏng chính xác bit Matlab.

03/02/10: Ưu điểm của TDD là bạn đảm bảo kiểm tra không thành công trước. Tôi cho rằng điều này có thể được thực hiện với các xác nhận.

Answer 1

Tôi viết mã cho FPGA, chứ không phải ASICS ... nhưng TDD vẫn là cách tiếp cận ưa thích của tôi. Tôi muốn có một bộ đầy đủ các bài kiểm tra cho tất cả các mã chức năng tôi viết, và tôi cố gắng (không phải luôn luôn thành công) để viết testcode đầu tiên. Nhìn chằm chằm vào dạng sóng luôn luôn xảy ra tại một số điểm khi bạn đang gỡ lỗi, nhưng nó không phải là một cách tốt để xác nhận mã của bạn (IMHO).

Do khó khăn trong việc thực hiện các kiểm tra thích hợp trong phần cứng thực (kích thích các trường hợp góc đặc biệt khó) và thực tế việc biên dịch VHDL mất vài giây (so với biên dịch "phần cứng" mất nhiều phút (hoặc thậm chí hàng giờ)), Tôi không thấy bất cứ ai có thể hoạt động theo bất kỳ cách nào khác!

Tôi cũng xây dựng các xác nhận vào RTL khi tôi viết nó để nắm bắt những điều tôi biết không bao giờ nên xảy ra. Cách ly này được xem là một chút "lạ", vì có một nhận thức rằng các kỹ sư xác minh viết khẳng định và nhà thiết kế RTL không. Nhưng chủ yếu tôi là kỹ sư xác minh của riêng tôi, vì vậy có lẽ đó là lý do tại sao!

Answer 2

Phần mở rộng SystemVerilog với chuẩn IEEE Verilog bao gồm một loạt các cấu trúc tạo thuận lợi cho việc tạo các phòng thử nghiệm kỹ lưỡng để xác minh thiết kế logic kỹ thuật số phức tạp. SystemVerilog là một trong số Ngôn ngữ xác minh phần cứng (HVL) được sử dụng để xác minh chip ASIC thiết kế thông qua mô phỏng (trái ngược với mô phỏng hoặc sử dụng FPGA).

lợi ích đáng kể trên một phần cứng thiết kế truyền thống ngôn ngữ (Verilog) là:

• chế ngẫu nhiên
• khẳng định
• bộ sưu tập tự động dữ liệu bảo hiểm chức năng và khẳng định

Điều quan trọng là có quyền truy cập vào phần mềm mô phỏng hỗ trợ tiêu chuẩn (2005) gần đây này. Không phải tất cả các trình mô phỏng đều hỗ trợ hoàn toàn các tính năng nâng cao hơn.

Ngoài tiêu chuẩn IEEE, có một thư viện SystemVerilog mã nguồn mở của các thành phần xác minh có sẵn từ VMM Central (http://www.vmmcentral.com). Nó cung cấp một khuôn khổ hợp lý để tạo ra một môi trường thử nghiệm.

Bạn cũng có thể thực hiện thêm nghiên cứu về chủ đề này bằng cách tìm kiếm trên diễn đàn Verfication Guild.

SystemVerilog không phải là HVL duy nhất và VMM không phải là thư viện duy nhất. Nhưng, tôi muốn giới thiệu cả hai, nếu bạn có quyền truy cập vào các công cụ thích hợp . Tôi đã tìm thấy đây là một phương pháp hiệu quả trong việc tìm kiếm thiết kế lỗi trước khi trở thành silicon.

Answer 3

Tôi chưa bao giờ tích cực thử TDD trên thiết kế RTL, nhưng tôi đã suy nghĩ về điều này.

Điều tôi cho là thú vị là thử phương pháp này liên quan đến xác nhận. Về cơ bản bạn sẽ viết xuống dưới dạng xác nhận những gì bạn giả định/mong đợi từ mô đun của bạn, viết RTL của bạn và sau đó bạn có thể xác minh các xác nhận này bằng cách sử dụng các công cụ và/hoặc mô phỏng chính thức. Trái ngược với testcases "bình thường" (nơi bạn có thể cần phải viết những cái hướng dẫn), bạn nên có phạm vi phủ sóng tốt hơn và các xác nhận/giả định có thể được sử dụng sau này (ví dụ: ở cấp hệ thống).

Tuy nhiên tôi sẽ không hoàn toàn dựa vào các xác nhận, điều này có thể trở nên rất lông.

Có thể bạn cũng có thể bày tỏ suy nghĩ của mình về điều này, như bạn đang yêu cầu, tôi đoán bạn có mang một số ý tưởng trong đầu?

Answer 4

Tôi không biết nhiều về thiết kế phần cứng/chip, nhưng tôi rất sâu vào TDD, vì vậy ít nhất tôi có thể thảo luận về sự phù hợp của quy trình với bạn.

Câu hỏi tôi muốn gọi là thích hợp nhất là: Các bài kiểm tra của bạn có thể cung cấp cho bạn phản hồi nhanh về thiết kế như thế nào? Liên quan đến điều đó: Bạn có thể thêm các bài kiểm tra mới nhanh như thế nào? Và các công cụ của bạn hỗ trợ tái cấu trúc tốt như thế nào (thay đổi cấu trúc mà không thay đổi hành vi) của thiết kế của bạn?

Quá trình TDD phụ thuộc rất nhiều vào "độ mềm" của phần mềm - kiểm tra đơn vị tự động tốt chạy trong vài giây (phút ở bên ngoài), và hướng dẫn các đợt ngắn tập trung xây dựng và tái cấu trúc. Các công cụ của bạn có hỗ trợ loại công việc này không - nhanh chóng đi xe đạp giữa việc viết và chạy thử nghiệm và xây dựng hệ thống đang được thử nghiệm trong các lần lặp ngắn?

Answer 5

TDD dành cho bạn là gì? Bạn có nghĩa là có tất cả các mã của bạn thực hiện bởi các bài kiểm tra tự động mọi lúc, hoặc bạn đi xa hơn để có nghĩa là các bài kiểm tra được viết trước mã và không có mã mới được viết trừ khi kiểm tra thất bại?

Bất kỳ phương pháp nào bạn thích, kiểm tra mã HDL không khác với kiểm thử phần mềm. Nó có điểm cộng của nó (độ bao phủ tốt hơn và độ sâu của thử nghiệm) và minuses (khó thiết lập và cồng kềnh tương đối với phần mềm).

Tôi đã có kinh nghiệm rất tốt khi sử dụng các trình giao dịch Python và HDL chung để thực hiện các thử nghiệm toàn diện và tự động cho các mô-đun HDL tổng hợp. Ý tưởng này tương tự như những gì Janick Bergeron trình bày trong sách của ông, nhưng thay vì SystemVerilog, Python được sử dụng để (1) tạo mã VHDL từ các kịch bản thử nghiệm được viết bằng Python và (2) xác minh kết quả được viết bởi các giao dịch giám sát chấp nhận dạng sóng từ thiết kế trong khi mô phỏng.

Có nhiều thứ khác để viết về kỹ thuật này, nhưng tôi không chắc bạn muốn tập trung vào điều gì.

Answer 6

Đối với công cụ tái cấu trúc cho ngôn ngữ phần cứng, tôi muốn chỉ cho bạn công cụ của chúng tôi Sigasi HDT. Sigasi cung cấp một IDE với bộ phân tích VHDL tích hợp và cấu trúc lại VHDL.

Philippe FAES, Sigasi

Answer 7

ANVIL - Một Verilog Interaction Lớp cuộc đàm phán về một số này. Tôi đã không thử nó.