SpinalHDL / SpinalHDL

I have a StreamMonitor Written by myself,the core function is running this function by fork:

    while (true) {
      log.info(s"bus_valid:${bus.valid.toBoolean}\tbus_ready:${bus.ready.toBoolean}")
      if (busValidPtr.toBoolean/*.manager.getLong(busValidPtr.signal)!=0*/) {
        active.set()
        if (busReadyPtr.toBoolean/*.manager.getLong(busReadyPtr.signal)!=0*/) {
          recv(sample())
        }
      } else {
        active.clear()
      }
      busReadyPtr.manager.setLong(busReadyPtr.signal,(!streamPause() && !full).toInt)
      clockDomain.waitSampling()
    }

In a design of my company, I need two StreamMonitors. When running the case, one of the cases failed. By adding printing, I found that the clockDomain.waitSampling() in the StreamMonitor of an interface missed a sample, which caused the simulation fail.
Since it is the company's code, the complete code cannot be posted here. I tried to test in VCS and Verilator. This case failed due to the same error reason, while other cases were successful.

@Dolu1990

To answer your question directly: maybe, but none that we know of ATM.

One question that I'd have is: what is driving the clock in the CD? Is it driven from forkStimulus?

waitSampling is used in the library verification itself and in many other places, we've yet to see an issue. Without code to reproduce it on a freely available simulator we'll not really be able to help much.
(if you want to compare your implementation to the StreamMonitor in lib:

SpinalHDL/lib/src/main/scala/spinal/lib/sim/Stream.scala

Line 15 in aa2e7d7

class StreamMonitor[T <: Data](stream : Stream[T], clockDomain: ClockDomain){

)

clockDomain.waitSampling() in the StreamMonitor

This is weird, there hasn't been a waitSampling since quite long in the StreamMonitor, which version of SpinalHDL are you using ?

Else, can you send a minimal self contained example for us to reproduce ? (verilator is the reference implementation of SpinalSim)

SpinalHDL Version:1.10.1
Scala:2.11.12
The clockDomain is driven by forkStimulus.
For my design, I have a dozen cases for the same simulation environment, and only one of them has such a problem(either Verilator or VCS), causing the simulation to fail.

I have two stream monitor in my simualtion enviroment,one is ok.
the core base class is this :
https://github.com/xiaochuang-lxc/SpinalHDL-TB/blob/main/src/main/scala/tb/monitor/StreamSink.scala

I would say, would need to first clockDomain.waitSampling() in the loop, then check for the bus status

But overall would need a small fully self contained example of weird behaviour to reproduce.

So, maybe this's the same as my problem in issues 1334?
In my issue, the problem is the clockDomain.onSampling API.

This discussion has been last long, I am trying to find the difference between StreamMonitor and class you describe.

waitSampling is different from the onSampling, it waits specified number of valid samplings. onSampling triggered each valid sampling.
So some user's calling on waitSampling might interference to the one in the Monitor's main loop.
That's why onSampling is now used in the StreamMonitor design.

Another difference is that StreamMonitor is not to create a new process by fork. It uses the same process of simulation by default.

Get Some Error Info:
The Failed Case has a lot of fork thread(dma queue,each queue has a fork thread)，when test 96 fork threads, the case passed.The case failed when fork 100 threads

Again: please post a self contained example that reproduces the issue - if not we can't help you.

Are there some bugs in clockDomain.waitSampling() API?