Open davidmlw opened 4 years ago
I think this is how stop works. Stop has a return code. Zero is considered success any other value is considered a failure diagnostic code. I think the problem is that the stop result is not exposed by the unit test frameworks. That should not be hard to fix if that is the problem
What is the current verilog emission result? I just have a look. It seems stop
is translated to "$fatal" and returns no code. Maybe it needs a Chisel3, Firrtl, Treadle synergy to have a standard spec for stop
and finish
.
According to https://www.eg.bucknell.edu/~csci320/2016-fall/wp-content/uploads/2015/08/verilog-std-1364-2005.pdf, Page 302. Verilog $finish
is not used to return status code to system. Acctually Verilog (2005) standard has no primitives to return a code outside.
In SystemVerilog (2017), http://ecee.colorado.edu/~mathys/ecen2350/IntelSoftware/pdf/IEEE_Std1800-2017_8299595.pdf Page 606, it provide $fatal
. While the return code of $fatal
is limited to 0, 1, 2 as same as $finish
.
It is very interesting that (System)Verilog had chosen not to provide a code-returning scheme.
So this recommendation need further considerations:
stop
and finish
. I would propose yes.exit (Int): Unit
and exit (UInt): Unit
can be used.Maybe the ultimate way to this is trying to add DPI
calling to chisel?
stop(code: UInt): Unit
. I am not sure whether it is possible. It could be more useful ifstop
can pass the internal circuit state outside.finish()
, finish has different meanings other than stop. A user-intended finish is very useful for simulation control.https://github.com/freechipsproject/chisel3/blob/473a13877c60ba9fb13de47542a8397412c2b967/core/src/main/scala/chisel3/Assert.scala#L80-L92