JTAG VPI Simulation gets blocked by IO

[rpls]

I recently switched my VexRiscv simulation to the official RISC-V JTAG and JTAG VPI as a network interface and was wondering why the simulation suddenly is excruciatingly slow. Turns out, that the JTAG VPI implementation has a blocking IO call in its main loop. Line 81, i.e., the readFully call is blocking. Since it's executed in a SimThread the simulation gets blocked. In practice, its not fully blocked, since a connected OpenOCD on the VPI port will send regular packages, so the simulation just becomes really slow.

SpinalHDL/lib/src/main/scala/spinal/lib/com/jtag/sim/JtagVpi.scala

Lines 79 to 83 in 7c6b137

	while (this.synchronized(connection) != null) {
	try {
	inputStream.readFully(buffer)
	val vpiCmd = deserializeVpiCmd(buffer)

A trivial fix would be to do a while loop that waits until enough bytes are present in the input buffer, the more elegant fix would probably to do some proper asynchronous IO (e.g., incremental non-blocking reading of VpiCmd packages).

[Dolu1990]

Hi ^^

For the PR; let's me know when you think it isn't draft :)

Note, i also recently added https://github.com/SpinalHDL/SpinalHDL/blob/composable-exp/lib/src/main/scala/spinal/lib/com/jtag/sim/JtagRemote.scala#L23
Which is in regular openocd

[rpls]

For the PR; let's me know when you think it isn't draft :)

I wanted to run some more tests. Played around with a network-thread (Proper thread, not SimThread), that does all the networking, parsing etc. and just passes the VpiCmds.... turns out to be a lot slower. But I'm no Java/Scala Networking Programmer, so I might just have messed it up. Anyway, let's leave it as-is.

Note, i also recently added https://github.com/SpinalHDL/SpinalHDL/blob/composable-exp/lib/src/main/scala/spinal/lib/com/jtag/sim/JtagRemote.scala#L23
Which is in regular openocd

Also a nice option! I'll test which is faster for my use-case.