chiselverify / chiselverify Goto Github PK

When running sbt test we get following error:

[error] /Users/martin/source/chisel-uvm/chisel-verify/src/test/scala/coverage/CoverageDB.scala:60:48: value strip is not a member of String
[error]             coverIdPortMap update (dutPortName.strip(), dutPort)
[error]                                                ^
[error] one error found
[error] (Test / compileIncremental) Compilation failed

ChiselVerify is currently dependent on ChiselTest, which is no longer supported in Chisel 6.

Many features from ChiselTest have been integrated into the CIRCT compiler directly, which now has its own simulator arcilator. Using arcilator we can easily reimplement the peek-poke-expect interface that we rely on from ChiselTest. This would allow ChiselVerify to survive past the deprecation of ChiselTest.

Then we would need to find a suitable replacement for ChiselTest's fork and join functionalities and we would have a complete replacement for our uses.

This is a proposal: let us make ChiselVerify a more generic testing tool also for Verilog and VHDL designs. Something like, but better than, cocotb.

One of the tests is aborted. Furthermore, the tests run too long. 23 minutes on my laptop.

We should add support to test ready/valid interfaces, including random pressure. Related to this is the discussion here: ucb-bar/chiseltest#326

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 following assumption is not true:

It would be a legal implementation to map the registers into memory. Which would save resources and also gives a fast context switch. However, it is probably inefficient. If so, I would not put it at address 0.

Is this assumption anywhere considered in the test generation?

The functionality tests for the priority queue have each been failing seemingly at random from one run to the next.
Sometimes MemoryTest fails, sometimes PriorityQueueTest fails, and sometimes they both pass...

This should be really made consistent, as it either shows that the functionality of the PriorityQueue is wrong, or that the test is wrong.

@tjarker Please look into this.

Could you please tell me how to get code coverage? I have read the paper you published and also studied the examples you gave in the source code.

It looks like there is just a picture in the paper, but no specific method is pointed out in the documentation or an example given in the source code?

Hello, I found that in the latest version of chisel verify, you have commented out require in lines 166 and 292 of chiselverify/coverage/CoverReport, but the version you uploaded to the maven online repository has not been updated subsequently.
Could you please update it, thank you~