Timeout Error #299
Comments
|
Regarding the extra tests. Sure they are not commented out but still in the file? As I said on Gitter we did not ignore commented out tests in SystemVerilog before, I fixed that in 2.4.0 but you need to update VUnit. |
|
Also sure there is no duplicate modules named vunit_test_tb? It should be warning when you add duplicates to run.py. |
|
Could I have such module in another file, but not included in the python script? |
|
I have updated VUnit version. Now I have two tests. It solved, thank you @kraigher. |
|
I still have a problem with a timeout. |
The timeout says 1.000 ns? Is that 1000 ns or 1 ns? |
|
The display statement in the TEST_SUITE_SETUP is reached but it contains a wait for 10 ns. |
|
I have set WATCHDOG(1us) - should be one microsecond. |
|
Yes I see that but maybe there is a bug in the watchdog. |
|
This is how it looks like. `define WATCHDOG(runtime) \
initial begin \
__runner__.watchdog(runtime); \
end
task automatic watchdog(realtime timeout);
fork : wait_or_timeout
begin
#timeout;
$error("Timeout waiting finish after %.3f ns", timeout / 1ns);
disable wait_or_timeout;
end
begin
@(posedge exit_without_errors);
disable wait_or_timeout;
end
join
endtask;
|
|
I guess |
|
I can suggest something like this one: fork
begin
//test
end
begin
while ($time < TIMEOUT) begin
@(posedge clk);
end
$error("Timeout over");
end
join_any
disable fork |
|
I do not like your suggestion since it depends on a signal named clk. Surely there must be a way in SystemVerilog to wait for a fixed time without knowing the timescale. |
|
Yes, it should be a synchronous process and better to know time scale. |
|
If you need asynchronous process: fork
begin
//test
end
begin
#TIMEOUT;
$error("Timeout over");
end
join_any
disable fork |
|
To make the watchdog code async and independent of timescale - use explicit time unit in the wait statement. Below is a piece of code that we've in Go2OVM lib doing similar thing - in this case it waits for a signal or a predefined time and exits You may want to try that. Then user can supply arg in multiples of NS. `define GO2OVM_WAIT(END_SIG, WDOG_VAL = GO2OVM_WDOG_DEL_IN_NS) \
fork \
begin \
string msg; \
wait (END_SIG); \
msg = $sformatf ("Wait seen in condition: %s ", `GO2OVM_DISP_ARG(END_SIG) ); \
`g2o_display (msg); \
end \
begin \
string msg; \
#(WDOG_VAL * 1ns); \
msg = $sformatf ("WDOG expired after waiting for: %0d %s %s", WDOG_VAL, "ns Wait condition: ", `GO2OVM_DISP_ARG(END_SIG) ); \
`g2o_error (msg); \
end \
join_any \
disable fork;
|
|
@alinaivanovaoff @svenka3 I pushed a fix for this to master now. See the referenced commit. |
|
@kraigher Is it now timeout time is "real", not "realtime"? If, yes, it is not suitable for my our coding style. It's not a problem, but I will not use `WATCHDOG. |
|
Ok what is the problem with real? When I divided the value by 1 ns it became a ratio and not an absolute time so I thought real was more appropriate. |
|
Should I set in real or in realtime? According to our coding style, we set timeout in terms of realtime. It's more readable and there is information about timescale. |
|
The macro argument is still semantically realtime. Inside the macro the realtime is divided with 1ns to get a ration which is real. Thus you should use a realtime such as "1us" as the argument before. The macro interface has not changed only the implementation to fix the bug that you discovered when the timescale of the test bench differed from the timescale used in vunit_pkg. In verilog it seems realtime such as 1ns is just a number relative the timescale. Thus if I passed 1ns realtime from testbench to vunit_pkg it caused a different delay if different timescales are used in the files. Strange semantics of verilog that a literal such as 1ns is not an absolute time. |
|
@kraigher - nice fix. Few small notes/clarifications (for other readers perhaps): Your fix is correct in my understanding.
I beg to differ - it is absolute, but when used in a # context - it gets evaluated with the timescale in effect. To clarify - in your new fix, you have: time_val / 1ns --> That's absolute 1ns In @alinaivanovaoff original use case - she/he has: That 1us is absolute - and gets scaled to a time unit when used with a # I have seen few more complications with class and this 1ns code - lucky you don't see it for now! Regards |
I am not convinced. To me it seems a time literal such as 1us is never stored as an absolute time but is directly converted to a relative numeric value based on the local timescale. Thus if I pass a literal 1us to a package function and the package does not have the same timescale it cannot know the absolute time intended by the caller. It seems this can only be solved using a macro in Verilog where the time is normalized locally in the file before making a call. Vice versa this would mean that a time constant defined in a package would not be directly usable in other code that has a different timescale. I think this is less than optimal language semantics. I guess the lesson to learn is to avoid setting local timescale in Verilog. Consider the following experiment as proof: `timescale 1 ns / 1ps
module my_module;
import my_pkg::*;
initial begin
realtime timeval = 1us;
$display("my_module:timeval = %t", timeval);
pkg_display(timeval);
end;
endmodule;File pkg.sv package my_pkg;
function automatic pkg_display(realtime timeval);
if (timeval == 1us)
$display("my_pkg:timeval == 1us");
else
$display("my_pkg:timeval != 1us");
$display("my_pkg:timeval = %t, 1us = %t", timeval, 1us);
endfunction
endpackageoutput |
|
If I want to add separate timeouts to each test case, what I should do? |
|
For example, each test case is test class: `TEST_SUITE begin
`TEST_CASE("Test_pass") begin
Test1 = new(usys, udata);
Test1.pre_test();
fork
Test1.run();
Test1.test_timeout(usys.clk, test_fail);
join_any
@(posedge usys.clk);
disable fork;
`CHECK_EQUAL(test_fail, 0);
end
`TEST_CASE("Test_pass") begin
Test2 = new(usys, udata);
Test2.pre_test();
fork
Test2.run();
Test2.test_timeout(usys.clk, test_fail);
join_any
@(posedge usys.clk);
disable fork;
`CHECK_EQUAL(test_fail, 0);
end
end;It this example I use my timout task. |
|
It is nothing in VUnit stopping you from using your own timeout task. The watchdog is optional. Maybe we could add a timeout that can be forked off from the main process. |
|
The WATCHDOG bugfix is available in release 2.4.1 |
Hi,
My testbench is:
My Python script is:
I got a timeout error:
As I understand ``WATCHDOG(1us);` is set timeout, but why I get an error, I have a stop on 36 line?
My next question: Why does summary show five tests instead of two?
Could you help me, please?
The text was updated successfully, but these errors were encountered: