Chuỗi bài viết này trình bày về vấn đề chạy đua (race condition) và cách viết code tránh chạy đua trong mô hình mô phỏng sự kiện (event simulation) của System Verilog (SV) và Verilog HDL. Bài thứ nhất sẽ so sánh mô hình mô phỏng sự kiện của hai ngôn ngữ SV và Verilog. Từ đó, phân tích các vấn đề của mô hình mô phỏng này để làm rõ tại sao việc hiểu rõ mô hình mô phỏng sự kiện lại có ý nghĩa quan trọng đối với người sử dụng SV và Verilog.
1) Lời mở đầu
Trước đây, tác giả có một số bài viết trình bày về mô hình mô phỏng theo sự kiện. Bạn đọc có thể tham khảo ở các link sau:
Những bài viết này được viết ra trong giai đoạn đầu, khi tác giả bắt đầu tìm hiểu về cách xây dựng môi trường mô phỏng. Nội dung của các bài viết này ở mức cơ bản (mức dịch tài liệu). Bên cạnh đó, tác giả đưa ra các ví dụ và tự giải thích với mong muốn được bạn đọc có kinh nghiệm nhận xét, góp ý và chỉ ra những sai sót. Tuy nhiên, nội dung có vẻ như "lý thuyết" này rất ít được quan tâm trong khi việc hiểu nó là "RẤT QUAN TRỌNG". Quan trọng bởi vì:
- Nó giúp giải thích hành vi thực thi của những dòng code
- Nó giúp hiểu và sử dụng đúng các thành phần của ngôn ngữ
- Nó giúp tránh những cách viết code sai. Ở đây, "sai" không phải là "sai cú pháp" mà là sai kết quả mô phỏng hoặc sai kết quả tổng hợp
- Nó giúp hiểu một phần hoạt động của trình mô phỏng (simulator)
- Với người kiểm tra thiết kế (verifier), nó giúp "điều khiển" và xác định đúng thời điểm thực thi các dòng code.
Dạo quanh một vài diễn đàn về công nghệ trên thế giới, các kỹ sư tốn rất nhiều công sức để nghiên cứu và tìm hiểu về vấn đề này. Một trong các trung tâm đào tạo hàng đầu thế giới Sunburst Design (http://www.sunburst-design.com/) có rất nhiều bài báo kỹ thuật phân tích về vấn đề này. Trong đó, nhiều bài là "Best paper", bài viết được bình chọn là tốt nhất, hay nhất trong các hội thảo khoa học.
- Clifford E. Cummings, Clifford E. Cummings; Correct Methods For Adding Delays To Verilog Behavioral Models; HDLCON, 1999
- Clifford E. Cummings, Sunburst Design; Inc; Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!; SNUG-2000 (This is the best paper)
- Clifford E. Cummings, Sunburst Design;Verilog Nonblocking Assignments With Delays, Myths & Mysteries; SNUG-2002 (This is the best paper)
- Clifford E. Cummings, Sunburst Design; Arturo Salz, Synopsys; SystemVerilog Event Regions, Race Avoidance & Guidelines; SNUG Boston 2006
Các bài viết trên ra đời từ rất lâu, bài mới nhất cách đây 13 năm, bài lâu nhất cách đây 20 năm. Tuy vậy, giá trị của chúng là rất lớn và sẽ còn hữu ích với cộng đồng cho đến khi SV và Verilog không còn được dùng nữa. Có lẽ vậy!
Việc hiểu thấu đáo và tường tận các nội dung trình bày trong các bài viết này là không dễ, ngay cả đối với người có kinh nghiệm vì đôi khi chúng ta chỉ dùng một cách "thuần thục như một cái máy" nhưng lại không rõ vì sao lại như vậy. Tác giả thử kiểm nghiệm bằng cách hỏi một vài người bạn có kinh nghiệm lâu năm về sử dụng SV nhưng hầu hết không thể trả lời rõ ràng hoặc chưa nghiên cứu sâu hoặc không biết về mô hình mô hình mô phỏng sự kiện trong khi ảnh hưởng của nó đến việc viết code là không hề nhỏ.
Vì vậy, trong quá trình thành lập các nhóm tự học, đối với các bạn theo hướng kiểm tra thiết kế (verification), tác giả đã trao đổi và đề xuất cùng tìm hiểu về vấn đề này trước khi bắt tay sử dụng SV và xây dựng môi trường mô phỏng.
Trong chuỗi bài viết này, tác giả một phần sẽ chọn lọc những nội dung phù hợp từ các bài viết của Sunburst Design kèm với luận giải và ví dụ cá nhân để cố gắng làm chúng dễ hiểu hơn. Hy vọng là như vậy!
Trước khi trình bày về nội dung kỹ thuật, xin lưu ý với bạn đọc rằng, mọi chia sẻ được viết ra đều dựa trên việc tự đọc và kiểm chứng của tác giả. Nếu bạn đọc có nghi vấn hoặc bạn là người có nhiều kinh nghiệm hãy góp ý với tác giả để hiệu chỉnh nội dung và mang đến kiên thức đúng nhất cho cộng đồng.
2) Hiểu về mô hình mô phỏng sự kiện
Mô phỏng sự kiện (event simulation) là mô hình mô phỏng dự được thực thi dựa trên các sự kiện rời rạc. Quá trình thực thi mô phỏng sẽ lặp lại liên tục việc sinh ra (initialize), sắp xếp (schedule), thực thi (execute) và xóa bỏ (remove) các sự kiện.
Các trình mô phỏng (simulator) như ModelSim,QuestaSim, VCS, Incisive, Xcelium,... sẽ phải “lập thời khóa biểu” (event scheduler) để thực thi các sự kiện một cách tuần tự, nghĩa là có thứ tự trước sau, chứ không phải song song như mô hình phần cứng thực tế. Để đảm bảo sự tương thích giữa các trình mô phỏng được xây dựng bởi các nhà cung cấp phần mềm khác nhau, SV và Verilog định nghĩa rõ về mô hình mô phỏng sự kiện. Các trình mô phỏng có thể thiết kế với các thuật toán khác nhau nhưng không được phép vi phạm mô hình này.
Trong mô hình mô phỏng sự kiện, thời gian mô phỏng (simulation time) được chia thành các khe thời gian (time slot). Mỗi khe thời gian được chia nhỏ hơn thành các vùng/miền sự kiện (event region). Trong mỗi miền sự kiện, các thành phần code SV như các phát biểu, các task xây dựng sẵn ($display, $strobe, …),... sẽ được sắp xếp và thực thi.
Trong mô hình mô phỏng sự kiện, thời gian mô phỏng (simulation time) được chia thành các khe thời gian (time slot). Mỗi khe thời gian được chia nhỏ hơn thành các vùng/miền sự kiện (event region). Trong mỗi miền sự kiện, các thành phần code SV như các phát biểu, các task xây dựng sẵn ($display, $strobe, …),... sẽ được sắp xếp và thực thi.
 |
| Hình 1: Thời gian mô phỏng (simulation time) trong SV |
Thứ tự thực thi các thành phần code SV trong các miền sự kiện
phải tuân theo chuẩn SV. Nếu chuẩn không quy định thì trình mô phỏng có thể sắp
xếp theo bất kỳ thự tự nào.
Trong mỗi miền sự kiện, trình mô phỏng sẽ xác định thứ tự các
sự kiện và sắp xếp chúng vào “hàng đợi sự kiện” (event queue). Hàng đợi sự kiện
là một khái niệm được sử dụng để dễ hình dung hoạt động của mô hình mô phỏng dựa
trên các sự kiện rời rạc. Hàng đợi sự kiện hoạt động như một FIFO, sự kiện nào
được xếp vào trước sẽ được thực thi trước. Sau khi thực thi xong, sự kiện đó sẽ
bị xóa khỏi hàng đợi. |
| Hình 2: Hàng đợi sự kiện (event queue) |
Quá trình mô phỏng là sự lặp đi lặp lại của hai hoạt động sau:
- Một biến (net hoặc variable) thay đổi trạng thái sẽ khởi động các process, cái “nhạy” với sự thay đổi này, thực thi.
- Các process thực thi sẽ làm thay đổi giá trị các biến.
Trong đó:
- Việc một biến thay đổi trạng thái gọi là sự kiện cập nhật (update event)
- Việc ước lượng thực thi một process gọi là sự kiện ước lượng (evaluation event)
Việc thay đổi trạng thái của biến, sự kiện cập nhật, là khi giá trị của biến thay đổi đến một giá trị khác với giá trị hiện tại, ví dụ chuyển từ 0 sang 1, từ x sang 0, từ 1 sang z, …
Process là một trong các loại phát biểu như initial, always, final, assign, …
 |
| Hình 3: Hoạt động mô phỏng là sự lặp đi lặp lại của việc thực thi các sự kiện cập nhật và sự kiện ước lượng |
Sự kiện ước lượng được hiểu là việc xác định các giá trị, trạng thái ngõ vào (input) của một process trước khi nó được thực thi (execute). Ví dụ, chúng ta có một process như sau:
always @ (posedge clk) y <= a;
Cạnh lên clock xuất hiện, nghĩa là một sự kiện cập nhật làm thay đổi giá trị của biến clk từ 0 sang 1 vừa được thực thi, thì một sự kiện ước lượng sinh ra trên process để xác định giá trị của a (nằm bền phải phép gán). Khi sự kiện ước lượng được thực thi, a đã được xác định một giá trị thì một sự kiện cập nhật giá trị từ a đến y được sinh ra nếu giá trị a khác với giá trị y hiện tại, ví dụ như a bằng 1 nhưng y đang bằng 0. Khi sự kiện cập nhật y được thực thi, y đã được gán giá trị mới từ a, thì một hoặc nhiều sự kiện ước lượng sẽ được sinh ra trên các process nhạy với sự thay đổi của y.
Việc hiểu mô hình mô phỏng này chỉ dành cho những kỹ sư kiểm tra (verifier), các kỹ sư thiết kế (designer) không cần biết điều này? SAI, việc không hiểu mô hình mô phỏng sự kiện sẽ gây ra các vấn đề nghiêm trọng cho cả kỹ sư thiết kế khi mô tả RTL code và kỹ sư kiểm tra khi mô tả testbench.
- Kỹ sư thiết kế có thể tạo ra các RTL code không thể tổng hợp được kết quả đúng như mong muốn.
- Kỹ sư kiểm tra có thể tạo ra một môi trường mô phỏng với kết quả kiểm tra không ổn định và cho kết quả khác nhau khi chạy trên các trình mô phỏng khác nhau.
3) So sánh mô hình mô phỏng sự kiện của Verilog và System Verilog
Trước hết, SV là một ngôn ngữ hợp nhất dành cho cả thiết kế và kiểm tra. SV được xây dựng trên System Verilog3.1a của tổ chức Accellera, SV3.1a được mở rộng từ Verilog HDL. Như vậy, Verilog HDL là một phần của SV và được nhúng trong SV. SV đảm bảo sự tương thích giữa code viết theo Verilog HDL và code viết theo SV.
Đối với mô hình mô phỏng sự kiện cũng không ngoại lệ, tuy số lượng miền sự kiện trong mô hình mô phỏng sự kiện SV nhiều hơn so với số miền sự kiện trong mô hình mô phỏng sự kiện Verilog nhưng SV chỉ mở rộng thêm các miền mới và vẫn giữ nguyên thứ tự, ý nghĩa và chức năng các miền sự kiện cũ từ Verilog.
4 miền sự kiện của Verilog được mang sang SV gồm:
- Active
- Inactive
- NBA
- Postponed
 |
| Hình 4: Các miền sự kiện của mô hình mô phỏng sự kiện trong Verilog |
13 miền sự kiện mới được thêm vào trong SV gồm:
- Preponed
- Pre-Active
- Pre-NBA
- Post-NBA
- Pre-Observed
- Observed
- Post-Observed
- Reactive
- Re-Inactive
- Pre-Re-NBA
- Re-NBA
- Post-Re-NBA
- Pre-Postponed
 |
| Hình 5: Các miền sự kiện trong SV [5] |
Các vùng mới được sinh ra để hỗ trợ việc thực thi các thành phần mới được thêm vào trong SV so với Verilog. Bên cạnh đó, các miền sự kiện mới còn hỗ trợ thực thi các thành phần code giúp tránh điều kiện chạy đua khi sử dụng SV.
Ví dụ, code trong khai báo module/endmodule được sắp xếp thực thi trong tập vùng active (active region set) còn code trong khai báo program/endprogram được sắp xếp thực thi trong tập vùng reactive (reactive region set) với mong muốn tách biệt quá trình thực thi của design (mô tả trong module/endmodule) và quá trình thực thi của testbench (được mô tả trong program/endprogram). Từ đó tránh chạy đua giữa việc thực thi design và testbench. Chú ý, đây chỉ là một ví dụ minh họa sự khác biệt giữa mô hình mô phỏng sự kiện SV và Verilog còn khả năng ứng dụng thực tế cần được nghiên cứu và xem xét kỹ hơn trong từng trường hợp cụ thể. Tác giả nói điều này là vì program/endprogram đang ít được dùng trong các môi trường mô phỏng hiện tại. Việc tránh race condition được áp dụng bằng nhiều biện pháp khác.
4) Vấn đề của mô hình mô phỏng sự kiện
Vần đề chính của mô hình mô phỏng sự kiện chính là do đặc điểm các process có thể được ước lượng theo thứ tự bất kỳ. Đây là nguồn sinh ra hành vi nondeterminism, tạm dịch là hành vi không thể xác định. Hành vi không thể xác định là hành vi làm cho kết quả mô phỏng (simulation) hoặc tổng hợp (synthesis) không cố định.
- Đối với phần mềm tổng hợp, một RTL code rơi vào trường hợp nondeterminism sẽ làm cho chức năng của mạch logic được tổng hợp ra không thể xác định.
- Đối với phần mềm mô phỏng, khi rơi vào trường hợp nondeterminism, cùng một code sẽ cho kết quả mô phỏng khác nhau sau mỗi lần chạy hoặc khác nhau khi thực thi trên các trình mô phỏng khác nhau.
Chú ý, trường hợp này các tool không hoàn toàn tương thích với chuẩn và hoạt động chính xác nhưng kết quả sinh ra sai là do người thiết kế hoặc người kiểm tra viết code không đúng. Xét ví dụ sau:
always @ (posedge clock) begin
a = 0;
a = 1;
end
always @ (posedge clock)
b = a;
Ví dụ trên lấy từ tài liệu tham khảo [6], trong đoạn code trên, tại cạnh lên clock, giá trị của b có thể là 0 hoặc 1. Nếu tổng hợp (synthesis), phần mềm tổng hợp có thể tạo logic gán giá trị 0 hoặc 1 cho b. Rõ ràng, chức năng mạch logic sinh ra là không thể xác định, hoàn toàn tùy phần mềm quyết định.
Nếu mô phỏng, kết quả mô phỏng của giá trị b là không cố định, có thể là 1 hoặc 0 hoặc x, hoàn toàn tùy thuộc vào trình mô phỏng.
Chúng ta cùng phần tích nguồn gốc nguyên nhân của vấn đề này dựa trên mô hình mô phỏng sự kiện. Tại cạnh lên clock, hai process always có thể được thực thi theo bất kỳ thứ tự nào. Ở đây, trong cả hai process always, các phép gán blocking được sử dụng nên tất cả chúng sẽ được xếp vào vùng Active trong cùng một time slot. Theo quy định của chuẩn SV:
- a=0 chắc chắn được thực hiện trước a=1 vì cùng trong một process sử dụng begin-end
- b=a có thể thực hiện trước a=0, sau a=1 hoặc giữa a=0 và a=1
Các tổ hợp khả năng có thể được thực thi bởi trình mô phỏng, tổng hợp như sau:
- a=0 -> a=1 -> b=a
- Kết quả mô phỏng b=1
- Kết quả tổng hợp b=1
- a=0 -> b=a -> a=1
- Kết quả mô phỏng b=0
- Kết quả tổng hợp b=0
- b=a -> a=0 -> a=1
- Kết quả mô phỏng
- b=x nếu a là kiểu dữ liệu 4 trạng thái
- b=0 nếu a là kiểu dữ liệu 2 trạng thái
- Kết quả tổng hợp b=0 hoặc b=1
Ở đây, phần mềm xử lý theo thứ tự nào cũng đều tương thích với chuẩn nhưng kết quả nhận được thì khác nhau. Hiện tượng trong ví dụ này còn được gọi bằng một tên khác là điều kiện chạy đua (race condition).
Một điều kiện chạy đua xuất hiện khi 2 hoặc nhiều phát biểu (statement) được xắp xếp thực thi trong cùng một khe thời gian nhưng cho kết quả khác nhau khi thứ tự thực thi của chúng khác nhau [4]. Trong ví dụ trên đây, các phát biểu (statement) là các phép gán blocking trong các process always. Như vậy, việc tránh điều kiện chạy đua là cực kỳ quan trọng đối với cả kỹ sư thiết kế và kỹ sư kiểm tra khi sử dụng ngôn ngữ lập trình được xử lý theo mô hình mô phỏng sự kiện như SV và Verilog.
Tóm lại, bạn đọc có thể thấy việc hiểu mô hình mô phỏng sự kiện sẽ giúp phát hiện và giải thích hiện tượng nondeterminism và điều kiện chạy đua để áp dụng các phương pháp phòng tránh hiệu quả.
Tài liệu tham khảo:
1) Clifford E. Cummings, Clifford E. Cummings; Correct Methods For Adding Delays To Verilog Behavioral Models; HDLCON, 1999
2) Clifford E. Cummings, Sunburst Design; Inc; Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!; SNUG-2000 (This is the best paper)
3) Clifford E. Cummings, Sunburst Design;Verilog Nonblocking Assignments With Delays, Myths & Mysteries; SNUG-2002 (This is the best paper)
4) Clifford E. Cummings, Sunburst Design; Arturo Salz, Synopsys; SystemVerilog Event Regions, Race Avoidance & Guidelines; SNUG Boston 2006
5) IEEE Standards Association; IEEE Standard for SystemVerilog, Unified Hardware Design, Specification, and Verification Language; 2017
6) IEEE Standards Association; IEEE Standard for Verilog® Register Transfer Level Synthesis; 2002
1) Clifford E. Cummings, Clifford E. Cummings; Correct Methods For Adding Delays To Verilog Behavioral Models; HDLCON, 1999
2) Clifford E. Cummings, Sunburst Design; Inc; Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!; SNUG-2000 (This is the best paper)
3) Clifford E. Cummings, Sunburst Design;Verilog Nonblocking Assignments With Delays, Myths & Mysteries; SNUG-2002 (This is the best paper)
4) Clifford E. Cummings, Sunburst Design; Arturo Salz, Synopsys; SystemVerilog Event Regions, Race Avoidance & Guidelines; SNUG Boston 2006
5) IEEE Standards Association; IEEE Standard for SystemVerilog, Unified Hardware Design, Specification, and Verification Language; 2017
6) IEEE Standards Association; IEEE Standard for Verilog® Register Transfer Level Synthesis; 2002
Lịch sử cập nhật:
1) 2019.10.11 - Tạo lần đầu
1) 2019.10.11 - Tạo lần đầu
0 bình luận:
Đăng nhận xét