Sự khác biệt giữa thử nghiệm và xác minh là gì?


15

Mỗi cuốn sách giáo khoa tôi từng thấy làm cho một thực tế lớn rằng kiểm traxác minh là hai khái niệm khác nhau. Tuy nhiên, không ai trong số họ cung cấp một sự phân biệt rõ ràng (hoặc đủ rõ ràng cho tôi, cuối cùng).

Để cung cấp một số bối cảnh, tôi quan tâm đến việc xác minh các thiết kế phần cứng kỹ thuật số bằng ngôn ngữ thiết kế phần cứng (HDL).

Tôi đã thấy một số giải thích cho thấy sự khác biệt "vật lý" hoặc "hữu hình": nếu đó là về một thiết bị được sản xuất, thì đó là thử nghiệm. Đây có phải là toàn bộ câu chuyện? Nếu vậy, tại sao từ "kiểm tra" lại xuất hiện thường xuyên như vậy trong xác minh (đặc biệt là trong xác minh chức năng, chúng tôi nói về testcase, testbenches, DUT (thiết bị được thử nghiệm), kiểm tra theo chỉ đạo, kiểm tra ngẫu nhiên, v.v ...)

Câu trả lời:


21

Là một kỹ sư xác minh thiết kế ASIC tại Qualcomm. Theo cách đơn giản nhất tôi có thể giải thích nó:

Kiểm tra: Đảm bảo sản phẩm hoạt động, sau khi bạn đã tạo sản phẩm (nghĩ QA).

Xác minh: Đảm bảo rằng sản phẩm hoạt động TRƯỚC KHI bạn đã tạo nó.

Cả hai đều đang thử nghiệm, chỉ cần xác minh đó phức tạp hơn vì bạn phải tìm ra cách kiểm tra sản phẩm trước khi nó tồn tại và bạn phải chắc chắn rằng nó hoạt động như thiết kế và để xác định khi nào nó thực sự xuất hiện.

Ví dụ, Intel đang thiết kế bộ xử lý tiếp theo của họ, họ có thông số kỹ thuật, họ có sơ đồ và mô phỏng. Họ chi 1 tỷ USD để đi qua chế tạo và sản xuất. Sau đó, con chip quay trở lại và họ kiểm tra nó và phát hiện ra rằng nó không hoạt động. Họ chỉ ném rất nhiều tiền ra khỏi cửa sổ.

Ném xác minh vào. Các kỹ sư xác minh tạo ra các mô hình mô phỏng hoạt động của chip, họ tạo ra testbench sẽ kiểm tra các mô hình cụ thể đó. Họ nhận được kết quả của các mô hình này và sau đó họ so sánh nó với kết quả RTL (mô hình của mạch ghi trong ngôn ngữ thiết kế phần cứng). Nếu chúng phù hợp, mọi thứ (thường) OK.

Có một số phương pháp khác nhau cho quy trình xác minh, một phương pháp phổ biến là Phương pháp xác minh phổ quát (UVM) .

Có rất nhiều chiều sâu trong lĩnh vực này và mọi người có thể dành toàn bộ sự nghiệp của mình trong đó.

Một thông tin ngẫu nhiên khác về thông tin: Thông thường bạn cần 3 kỹ sư xác minh cho 1 kỹ sư thiết kế. Dù sao đó cũng là những gì mọi người trong lĩnh vực nói.

EDIT: Rất nhiều người nghĩ rằng xác minh là một vai trò thử nghiệm, nhưng thực tế không phải vậy; Bản thân nó là một vai trò thiết kế vì bạn phải hiểu tất cả những điều phức tạp của IC giống như một nhà thiết kế, và sau đó bạn phải biết cách thiết kế mô hình, testbenches và tất cả các trường hợp thử nghiệm sẽ bao gồm tất cả các chức năng tính năng của IC của bạn , cũng như cố gắng đạt được từng dòng mã RTL cho tất cả các kết hợp bit có thể. Hãy nhớ rằng một bộ xử lý ngày nay có hàng tỷ bóng bán dẫn do quá trình chế tạo cho phép nhỏ hơn và nhỏ hơn (nay là 14nm).

Ngoài ra, trong các tập đoàn lớn như Intel, AMD, Qualcomm, v.v., các nhà thiết kế không thực sự thiết kế chip. Thông thường, kiến ​​trúc sư sẽ xác định tất cả các thông số kỹ thuật, bố trí các loại mảnh cần đi cùng nhau để có được một chức năng cụ thể với một yêu cầu cụ thể (ví dụ: tốc độ, độ phân giải, v.v.), và sau đó nhà thiết kế sẽ mã hóa nó thành RTL. Đó không phải là một công việc dễ dàng, nó chỉ không thiết kế nhiều như nhiều kỹ sư ra khỏi trường nghĩ rằng nó là. Những gì mọi người muốn trở thành một kiến ​​trúc sư, nhưng cần rất nhiều giáo dục và kinh nghiệm để đi đến điểm đó. Rất nhiều kiến ​​trúc sư có bằng tiến sĩ, và như 15-20 năm kinh nghiệm trong lĩnh vực này với tư cách là một nhà thiết kế. Đây là những người thông minh (và đôi khi điên rồ), những người xứng đáng được làm những gì họ đang làm và họ rất giỏi trong việc đó. Kiến trúc sư trên con chip đầu tiên tôi làm việc hơi lúng túng và không thực sự tuân theo một số quy tắc xã hội, nhưng anh ta có thể giải quyết bất cứ điều gì bạn mắc kẹt liên quan đến con chip, và đôi khi anh ta sẽ giải quyết nó trong đầu và nói với bạn nhìn vào một tín hiệu và bạn sẽ giống như, "làm thế quái nào anh ấy làm điều đó?". Sau đó, bạn yêu cầu anh ta giải thích và anh ta làm và nó đi qua đầu bạn. Thực sự đã truyền cảm hứng cho tôi để đọc sách giáo khoa mặc dù tôi đã tốt nghiệp.


+1 Cảm ơn về nhận xét cuối cùng, giúp chúng tôi thấy rằng lĩnh vực này thực sự quan trọng (mặc dù RTL và kỹ thuật thiết kế nghe có vẻ hấp dẫn hơn đối với hầu hết các kỹ sư, tôi nghĩ vậy)
VHDL Addict

Để cho đầy đủ, bạn có phiền khi thêm một testcase là gì?
Nghiện VHDL

Tôi đã thêm một mẩu tin về việc xác minh thực sự là gì vì nhận xét đầu tiên của bạn về vai trò thiết kế hấp dẫn hơn; Cả hai đều là những vai tốt, chỉ phụ thuộc vào những gì bạn thích. Đối với một trường hợp thử nghiệm, một SoC như Snapdragon có thể có hàng chục đến hàng trăm nghìn trường hợp thử nghiệm và với thử nghiệm ngẫu nhiên, trong hàng triệu. Nói một cách đơn giản: bạn đang áp dụng một tập hợp các bit đầu vào và được thay đổi qua nhiều mô-đun, sau đó bạn nhận được một số bit đầu ra do kết quả mà bạn so sánh với kết quả của mô hình. Một cái gì đó đơn giản như thử nghiệm một hình ảnh hiển thị trên điện thoại của bạn sẽ có ...
PGT

một số lượng lớn các testcase. Giả sử bạn muốn hiển thị một pixel trên màn hình điện thoại di động của bạn. Những gì ai đó bên ngoài trường sẽ nghĩ là áp dụng 1 bit cho màu trắng và 0 cho màu đen. Trong thế giới di động thực tế, pixel đó có thể khác nhau theo kích thước, cường độ, góc quay, định dạng màu (YUV ###, RGB ###, v.v.). Và có lẽ bạn đang kiểm tra 1 bit trong một tập hợp các bit được áp dụng cho đầu vào cùng nhau. Các bit khác có thể là 0 vì nó màu đen hoặc có thể là 1 vì nó xử lý các thông tin khác như cách xử lý chế độ truyền, CLK, bật / tắt, kích hoạt, những thứ ưa thích như thế.
PGT

6

Trong cuốn sách của tôi, Xác minh đảm bảo rằng những gì bạn đã thiết kế "thực hiện công việc" - tức là, bạn có một bộ những thứ mà "thiết bị" cần thực hiện và xác minh đánh dấu những thứ đó trong danh sách.

Tuy nhiên, kiểm tra là đảm bảo rằng những điều mà "thiết bị" thực hiện được thực hiện đúng. Bạn có một bộ các chức năng và bạn kiểm tra từng chức năng để đảm bảo rằng chức năng đó hoạt động đúng.

Tóm lại, Xác minh đang kiểm tra thiết kế và Kiểm tra đang kiểm tra sản phẩm.


Tôi nghĩ rằng tôi đang bắt đầu hiểu ... Bạn có thể vui lòng cung cấp một số ví dụ về mỗi?
Nghiện VHDL

Làm thế nào điều đó phù hợp với một kế hoạch xác minh , trong đó chỉ định những gì nên được thực hiện và cũng làm thế nào để biết rằng chức năng là chính xác? Nó sẽ ít được sử dụng để thực hiện hoặc đánh dấu vào một chức năng nếu nó không hoạt động.
Nghiện VHDL

@ Majenko - Vậy bạn đã viết một cuốn sách về Xác minh? Bạn có thể chia sẻ thêm một số chi tiết về nó?
Michael Karas

4

Xuất phát từ nền tảng thiết kế ASIC (phần cứng), có ba thuật ngữ quan trọng: xác nhận , xác minhkiểm tra . Các câu trả lời trước đây thường nói về một hoặc hai trong số các thuật ngữ này, nhưng không tương phản rõ ràng cả ba theo cách tôi sẽ làm. Đây là cách tôi hiểu họ:

  • Xác nhận: thông số kỹ thuật (thường là mô hình C) đáp ứng yêu cầu của thị trường hoặc khách hàng
  • Xác minh: việc triển khai (RTL, netlist hoặc GDS2) có khớp với thông số kỹ thuật không
  • Kiểm tra: thiết bị được sản xuất có phù hợp với việc triển khai không

Các mô phỏng netlist và GDS2 có thể cho kết quả khác nhau không?
Ciro Santilli 新疆 心 心

1
@CiroSantilli 巴拿馬 件, tôi cho rằng bạn đang hỏi về hành vi của cổng so với bóng bán dẫn. Đối với điện áp và dạng sóng kỹ thuật số thông thường, tôi muốn nói rằng chúng sẽ cho kết quả tương tự. Nhưng có thể có các hiệu ứng "tương tự" không được xem xét bởi các cổng lý tưởng hóa, chẳng hạn như các biến thể nguồn / mặt đất hoặc chia sẻ điện tích tín hiệu. Nếu những hiệu ứng đó có mặt, thì hành vi kỹ thuật số lý tưởng có thể không đúng.
Winston Smith

1

Một thử nghiệm được thiết kế để xem nếu một đặc điểm kỹ thuật được đáp ứng. Xác minh là để xem thiết bị có đáp ứng các đầu vào thiết kế hay không - tức là tất cả các thông số kỹ thuật. Tôi cho rằng có nhiều cách hiểu hơn, nhưng đây là những gì tôi đã thấy trong các tài liệu hướng dẫn của FIA.


Tôi thấy, tôi đã thay đổi từ ngữ một chút (từ kiểm tra sang kiểm tra ) để làm rõ hơn rằng cả hai đều là quy trình. Tôi đồng ý với bạn rằng cho bài kiểm tra cá nhân từ thử nghiệm thích hợp (đôi khi tôi cảm thấy như tôi tái khẳng định rõ ràng với những câu hỏi ngữ ...) :)
VHDL Addict

1

Chúng tôi phân biệt giữa kiểm tra xác minh và kiểm tra xác nhận. Giả sử bạn đang thiết kế một chiếc quạt làm mát một số thiết bị. Kiểm tra xác minh được thực hiện để đảm bảo quạt đáp ứng tất cả các yêu cầu thiết kế. Vì vậy, bạn có thể kiểm tra luồng không khí, chu kỳ nhiệt, độ rung, vv

Kiểm tra xác nhận đảm bảo các yêu cầu thiết kế là đúng. Có phải các đầu vào thiết kế chúng ta có cho quạt thực sự cung cấp cho chúng ta quạt mà chúng ta muốn? Ví dụ: bạn chắc chắn rằng quạt thực sự làm mát thiết bị khi được tăng cường.


Đây là cách các thuật ngữ được hiểu bởi những cuốn sách về Kỹ thuật phần mềm tôi đã đọc. Xác nhận = đảm bảo các yêu cầu là đúng (kiểm tra chúng với khách hàng, quy định, v.v.); Xác minh = đảm bảo sản phẩm đúng (kiểm tra so với thông số kỹ thuật)
Wouter van Ooijen

1

ISO 9000 nói về xác minh và xác nhận. Trong bối cảnh xác minh ISO 9000 có nghĩa là thử nghiệm một thiết kế nguyên mẫu để chứng minh rằng nó đáp ứng các mong đợi về chức năng và hiệu suất. Xác nhận có nghĩa là thử nghiệm lần chạy sản xuất đầu tiên cũng đáp ứng mong đợi thiết kế. Xác minh trước, xác nhận sau là cách nhỏ của tôi để nhắc lại thứ tự của mọi thứ.

Một số tiêu chuẩn phần mềm đảo ngược thứ tự xác minh và xác nhận và điều này thực sự có thể gây nhầm lẫn vì vậy hãy lưu ý điều này.

Điểm mấu chốt là ... Tại sao bạn đang thử nghiệm một cái gì đó - đó có phải là một thiết kế nguyên mẫu - nếu vậy thì các tiêu chuẩn chất lượng có xu hướng gọi xác minh này. Nếu bạn đang thử nghiệm một lần chạy sản xuất lần đầu tiên thì những người làm phần cứng gọi đây là xác nhận.

Chỉ là kinh nghiệm cá nhân của tôi.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.