You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ChiselVerify currently lacks users, as many of its features are now part of the core Chisel language, and the parts that aren't perform very poorly (because of its implementation purely as a Scala library). Additionally, the library is very poorly tested, which limits the trust people can have in it. Certain aspects such as the approximate design error metrics are still quite useful, but we simply lack wide-scale adoption.
What should the future of ChiselVerify look like? Should it pivot towards more custom instrumentation passes in CIRCT to improve the performance? Should we pivot towards being a Chisel generation framework to avoid slow implementations for things supported in the core language?
I'm honestly not sure, which is why I want to open this up to discussion to see what is worth doing with this library?
The text was updated successfully, but these errors were encountered:
Thanks for raising this question. I honestly don't feel qualified to say much here, though, since I haven't been following the development of Chisel and CIRCT as closely for the last two years as I did before then.
Good to start a discussion here. I think it should evolve to provide a compatibility layer for ChiselTest API on top of the new Chisel simulation framework. Then it should evolve towards UVM like features and be a better solution than cocotb and PyUVM for Chisel, but also general Verilog designs.
Good to start a discussion here. I think it should evolve to provide a compatibility layer for ChiselTest API on top of the new Chisel simulation framework. Then it should evolve towards UVM like features and be a better solution than cocotb and PyUVM for Chisel, but also general Verilog designs.
Interesting take @schoeberl , I agree that this would be a good route to take to improve the attractiveness of the library. I can start by taking a look internally with the arcilator people to see if/how we can gain access to a peek-poke-step style interface again, then it would be a question of how and if we would want to hook into verilator. I'll keep this issue up-to-date with what I find!
ChiselVerify currently lacks users, as many of its features are now part of the core Chisel language, and the parts that aren't perform very poorly (because of its implementation purely as a Scala library). Additionally, the library is very poorly tested, which limits the trust people can have in it. Certain aspects such as the approximate design error metrics are still quite useful, but we simply lack wide-scale adoption.
What should the future of ChiselVerify look like? Should it pivot towards more custom instrumentation passes in CIRCT to improve the performance? Should we pivot towards being a Chisel generation framework to avoid slow implementations for things supported in the core language?
I'm honestly not sure, which is why I want to open this up to discussion to see what is worth doing with this library?
The text was updated successfully, but these errors were encountered: