Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] What is the future of ChiselVerify? #52

Open
dobios opened this issue May 3, 2024 · 3 comments
Open

[Discussion] What is the future of ChiselVerify? #52

dobios opened this issue May 3, 2024 · 3 comments
Assignees
Labels
help wanted Extra attention is needed question Further information is requested

Comments

@dobios
Copy link
Member

dobios commented May 3, 2024

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?

@dobios dobios added help wanted Extra attention is needed question Further information is requested labels May 3, 2024
@hansemandse
Copy link
Member

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.

What would you suggest, @schoeberl?

@schoeberl
Copy link
Member

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.

@dobios
Copy link
Member Author

dobios commented May 7, 2024

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants