Thông báo

**tonyvandinh** · 06-05-2010, 12:14

Nguyên văn bởi jefflieu Xem bài viết

Có nên lập 1 project về formal verification ko nhỉ?
- Lấy code từ opencores.org
- Thiết kế verification plan/codes

Phần này Jeff rất mù mờ, chưa có khái niệm nhiều, mong anh em ai có kinh nghiệm cho ý kiến.

Chắc J muốn ám chỉ Functional Verification. Vì Formal Verification là kỹ thuật dùng tool để xác định sự tương đồng của giữa 2 thiết kế (2 versions hoặc 2 ngôn ngữ và vân vân). Ví dụ như muốn chứng tỏ sự tương đồng giữa RTL và gate level netlist hoặc là khi đổi thiết kế của một netlist và muốn biết sự thay đổi không làm ảnh hưởng tới bộ phận khác thì FV giữa 2 versions trước và sau khi thay đổi, kết quả là chỉ khác ở chỗ thay đổi mà thôi, còn chỗ khác, sự hoạt động vẫn tương đồng. Kỹ thuật này hay được dùng cho ECO (Engineering Changing Order) để tiết kiểm thời gian làm lại Functional Verification.

**jefflieu** · 06-05-2010, 12:37

Hehe, thuật ngữ Jeff dùng ko đúng lắm, anh em thông cảm

Thôi bỏ chữ formal, J muốn lập project để tìm hiểu xem các bước để kiểm tra (một cách chuyên nghiệp, tất cả các ngóc ngách) một IP là như thế nào?

**hithere123** · 07-05-2010, 16:27

Theo mình để bắt đầu với công việc kiểm tra nhất thiết phải có một verification plan, điều này càng có ý nghĩa với những thiết kế có mức tổ hợp cao (phức tạp). Ý nghĩa của tài liệu này là cố gắng không “lỡ quên” bất cứ trường hợp kiểm tra nào. Thông thường có một tài liệu quan trọng trước khi bắt đầu tiến hành bước thiết kế (coding), đó là tài liệu mô tả các yêu cầu thiết kế trong đó mô tả tất cả những đặc tính, thông số, trình tự (FSM), … của thiết kế. Người thiết kế sẽ dựa vào tài liệu này để thiết kế và người kiểm tra cũng dựa vào tài liệu này để xây dựng verification plan cho thiết kế.

Ví dụ, thiết kế một bộ giao tiếp SPI cho bộ nhớ flash chẳng hạn, thì yêu cầu thiết kế đơn giản chỉ là thực hiện nhiệm vụ ghi (write), đọc (read) và xóa (erase). Tuy nhiên trong tài liệu mô tả thiết kế không đơn giản như vậy vì trình tự ghi cả bộ nhớ hay một byte là khác nhau. Do đó, mô tả chi tiết các quá trình ghi/đọc/xóa và các hoạt động tương tác kết hợp giữa ghi/đọc và xóa là cần thiết. (Có thể mô tả bằng ngôn ngữ thuật toán hay đồ thị thời gian hay kết hợp nhiều phương pháp). Tóm lại là sẽ có rất nhiều hoạt động cần được thiết kế cho IP giao tiếp SPI này.

Dựa vào tài liệu này, verification plan cần phải đảm bảo:
+ Kiểm tra hết chức năng của các hoạt động ghi/đọc/xóa xem có đúng với yêu cầu thiết kế không
+ Kiểm tra những trường hợp stress. Ví dụ, nếu địa chỉ đưa vào không trùng với giải địa chỉ cho phép thì sao; hay có thể vô tình nhảy vào trạng thái đồng thời cả ghi và xóa không; hay nếu đang ghi mà mất clock một khoảng thời gian nào đó rồi lại có clock thì sao, . . .

Tóm lại là cũng có khá nhiều thứ cần tính đến.

Sau khi đã có verification plan thì bước tiếp theo là xây dựng testbench (coding). Một ưu điểm của thiết kế số là khi đưa tín hiệu vào thế này thì biết chắc chắn đầu ra phải thế kia nếu thiết kế đúng. Do đó, hoàn toàn có thể tự động cho ra kết quả PASS/FAIL mà không cần phải nhìn waveform.

Ví dụ, để kiểm tra hoạt động ghi/đọc có thể làm như sau: Một bộ đếm tuần tự sẽ quét hết các địa chỉ bộ nhớ và một bộ tạo dữ liệu ngẫu nhiên sẽ tạo ra dữ liệu ghi vào bộ nhớ. Dữ liệu ngẫu nhiên này sẽ được lưu trữ cùng với địa chỉ để so sánh dữ liệu thu được ở đầu ra khi thực hiện quá trình đọc. Nếu tất cả các so sánh này là giống nhau thì PASS, nếu có bất cứ so sánh khác nhau nào sẽ cho ra kết quả FAIL. Và một thiết kế kiểm tra tốt là khi kết quả ra FAIL thì có đầy đủ thông tin như sai ở địa chỉ nào, và ở trạng thái nào, … để đơn giản hơn cho việc xác định lỗi.

Khi mức độ tổ hợp của thiết kế là rất lớn, thì việc kiểm tra này mất rất nhiều thời gian, có khi chiếm tới 70%-80% giai đoạn thiết kế. Mình nhớ là đã có một số trao đổi về việc này ở các luồng thảo luận:
http://www.dientuvietnam.net/forums/...t=34163&page=2
và
http://www.dientuvietnam.net/forums/...ad.php?t=34248

Hy vọng một số thông tin trên sẽ giúp cho bạn có cái nhìn tổng quan về công việc kiểm tra.

Thân mến.

**tarzanaly** · 07-05-2010, 17:23

Theo em hiểu thì IP cũng có Soft IP và Hard IP (kiểu software với hardware ấy) chắc cũng không khó hiểu.
soft IP thì chỉ có code, còn hard IP là một cục có thể đưa ra sản xuất luôn, bên trong có gì không biết

Muốn verify cả 2 thì đều phải có functional verification với testbench và simulation. Soft IP chắc thế là hết, hard IP thì giống như một con chip nhỏ (kô package) nên vẫn phải qua các khâu physical layout implementation nên phải thêm formal verification để compare cái netlist hoặc RTL ban đầu (soft IP) với RTL sau cùng trước khi stream ra GDS (dùng để sản xuất). Ngoài ra còn có các test để check timing, DRC (design rules check), EM (electromigration) hay noise (crosstalk). Có lẽ là chỉ thiếu mỗi package test với verification là đủ cho cả chip.
Mọi người thấy sai hay thiếu sót gì thì sửa/bổ sung với nhớ

**hithere123** · 07-05-2010, 18:14

Formal Verification là một kỹ thuật khác và đã được anh Tony giải thích kỹ ở trên và cùng với các phần kiểm tra timing, DRC . . . mà bạn đề cập là những bước bắt buộc trong quy trình thiết kế. Và nếu thiết kế trong đó có sử dụng Soft-IP hay Hard-IP thì đều phải trải qua các bước này.

Như bạn nói Hard-IP là một cục có thể đưa sản xuất luôn tức là về mặt chức năng đã được kiểm tra thậm chí đã được bảo đảm silicon đã chạy, ở một khía cạnh nào đó có thể coi nó như một standard cell và khi sử dụng không cần kiểm tra nữa, mà chỉ kiểm tra về mặt kết nối và tương tác với các phần khác ở mức SoC verification. ( Thông thường trong Hard-IP sẽ có một bộ behavior macro + dữ liệu timing để có thể compile, chạy mô phỏng , chạy timing check, … )

Tuy nhiên bạn có nói là so sánh netlist ban đầu (soft-IP) và RTL sau cùng (gate netlist) thì mình nghĩ có sự khó hiểu về khái niệm Soft-IP ở đây. (Soft-IP ở đây là của Hard-IP? Tức là mua IP thì có cả RTL(soft) và layout (hard)?.) Theo mình, chạy formal verification ở đây là ở mức tổ hợp SoC. Khi chạy LEC chẳng hạn thì Hard-IP sẽ được coi là một black box.

Thân mến.

**tonyvandinh** · 07-05-2010, 18:59

Cám ơn có thể theo dõi thêm về OVM (Open Verification Methodology) nhe.

http://www.ovmworld.org/index.php

Mình có thể dùng kỹ thuật này để làm verification cho thêm chu đáo và hoàn hảo hơn nhưng nó đòi hỏi phải biết về systemV hoặc systemC cho nên tôi không biết có nên bàn về vấn đề này hay chưa

**jefflieu** · 07-05-2010, 22:25

Nguyên văn bởi hithere123 Xem bài viết

Theo mình để bắt đầu với công việc kiểm tra nhất thiết phải có một verification plan, điều này càng có ý nghĩa với những thiết kế có mức tổ hợp cao (phức tạp). ......
Tóm lại là cũng có khá nhiều thứ cần tính đến.....

Khi mức độ tổ hợp của thiết kế là rất lớn, thì việc kiểm tra này mất rất nhiều thời gian, có khi chiếm tới 70%-80% giai đoạn thiết kế. Mình nhớ là đã có một số trao đổi về việc này ở các luồng thảo luận:
http://www.dientuvietnam.net/forums/...t=34163&page=2
và
http://www.dientuvietnam.net/forums/...ad.php?t=34248

Hy vọng một số thông tin trên sẽ giúp cho bạn có cái nhìn tổng quan về công việc kiểm tra.

Thân mến.

Đây hoàn toàn đúng với những gì Jeff muốn tìm hiểu và muốn bạn nào có kinh nghiệm làm một cái DEMO

...

Ý tưởng là lấy code, trên opencores.org và thiết kế quá trình verification cho nó.
Một project như vậy không biết có hữu ích cho cộng đồng không?

Như anh Tony nói, cần khá nặng về SystemC và SystemV....

**jefflieu** · 11-05-2010, 23:14

Idea is dropped then !

Ý tưởng này có vẻ ko thực hiện được.
Thanks all.

**hithere123** · 12-05-2010, 16:08

Nguyên văn bởi jefflieu Xem bài viết

Ý tưởng này có vẻ ko thực hiện được.

Ý tưởng này sẽ thực hiện được vì các bạn chắc chắn sẽ cần quá trình kiểm tra này cho các project các bạn đang tiến hành. Đến lúc đấy mọi người hoàn toàn có thể đưa lên diễn đàn để làm DEMO.

Nguyên văn bởi jefflieu Xem bài viết

Một project như vậy không biết có hữu ích cho cộng đồng không?

Mình nghĩ nó rất hữu ích cho cộng đồng, ít nhất là với những ai mới bắt đầu làm quen với VLSI design. Các bạn đó sẽ có được những thông tin tham khảo tốt để hiểu về những công việc/công đoạn trong quá trình thiết kế.

Thân mến.

Thông báo

Project về verification

Project về verification

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Về tác giả

Bài viết mới nhất