Force stop simulation
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Lĩnh vực
- testing
Hướng nghiên cứu
Read the issue's example using is_active, lock, and test_runner_cleanup to trace how process synchronization affects simulation shutdown. Check the test runner cleanup and lock handling entry points and their tests; done means a documented or implemented way to stop the simulation despite outstanding locks, with behavior verified by a regression test.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Hi guys, I searched for force stopping the simulation. In my tb I use the following construct for communicating between check and stimuli processes:
wait until is_active(event => start_stimuli);
lock(runner => runner, key => key);
Currently, the stimuli takes longer than the checker to finish which is fine for me as the checker checks only for a small time the output port. However, just calling the test_runner_cleanup procedure doesn't seem to stop the simulation. I'm not sure if it's good practice to use the unlock procedure in different processes (as the call for test_runner_cleanup is done in a separate process).
Is there a way to force stop simulation regardless of any locks?
- Ngôn ngữ chính
- VHDL
- Star
- 850
- Fork
- 305
- Merge trung bình
- 2 ngày 10 giờ
- Pull request đã merge (30 ngày)
- 7
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của VUnit/vunit
-
KeyError in test scheduler when using TestBench.scan_tests_from_file()Có thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
GHDL: generics leak between configurations when `ghdl.sim_flags` is setCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
VUnit/vunit#1223 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 1 ngày
-
AXI slave VCs have identical stalling behaviorCó thể đã có người làm @Lay007 đã nhận 28 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
VUnit/vunit#1219 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug goto-symex
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
Maintainer thường phản hồi trong vòng 1 ngày
-
agent-ui bug p3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
Maintainer thường phản hồi trong vòng 1 ngày
-
nightly-tests
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
BlackBeltTechnology/pi-agent-dashboard#1063 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area:server bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
zcashlabs/thus-spoke-zakura#434 ·
Maintainer thường phản hồi trong vòng 1 ngày