New queueless VILLAS interface / improve real-time performance

[n-eiling]

villas interface: improve real-time capability

The original villas interface was not real-time capable because of the queue it uses. This commit creates an interface for villas interfaces, moves the old implementation to InterfaceQueued and adds a new queueless, threadless implementation InterfaceQueueless.

models: Add DC voltage source

The DP_Ph1_VoltageSource always calculates a sinusoidal signal, even if we only want to set a DC value. This commit adds a DC generator for the model so it can be significantly faster if we do not need the sinusoidal signal.

FpgaExample: use new villas interface and make logging optional.

[m-mirz]

@n-eiling this reduces the latency by removing the intermediate queue, hoping that the sync call to villas returns very quickly and does not block dpsim for too long?
Do I remember correctly that villas also has internal queues for some node types to avoid blocking?

It seems like a good idea if you do not only care about real-time in the simulation but also across the interface.

[stv0g]

Do I remember correctly that villas also has internal queues for some node types to avoid blocking?

Yes there are some, but not for the reason you are thinking. Some nodes have internal queues as the underlying libraries have callback based APIs or work in a background thread which require a queue to exchange samples with the main VILLASnode thread.

@n-eiling this reduces the latency by removing the intermediate queue, hoping that the sync call to villas returns very quickly and does not block dpsim for too long?

I agree here. I think both use cases are valid. But most people probably will use DPsim with the non hard real-time VILLASndoe node-types which use syscalls / network I/O anyway. In that cases, I would still recommend to use the queue-based interface

@n-eiling Does your new interface also support non-blocking operation?

[stv0g]

I did a first pass of review. But I think also @m-mirz or @dinkelbachjan should have a closer look.

[n-eiling]

@n-eiling this reduces the latency by removing the intermediate queue, hoping that the sync call to villas returns very quickly and does not block dpsim for too long? Do I remember correctly that villas also has internal queues for some node types to avoid blocking?

It seems like a good idea if you do not only care about real-time in the simulation but also across the interface.

The FpgaExample uses no queue, no VILLAS path and consequently is purely single-threaded. To achieve time steps in the microsecond range, even simple synchronization primitives create too much delay - even polling would create jitter.
In the example the simulation is hardware synchronized - so the time step is created on the FPGA, making it more accurate. This is achieved by disabling real-time in DPsim and having the VILLASnode read call block until the next time step starts. The FPGA also creates a sequence number that makes it possible for the VILLAS interface to detect time step overruns.
With some quite heavy OS optimizations (e.g., PREEMPT_RT, isolcpu, ...) and custom compiler flags for VILLAS and DPsim (-flto -Ofast), I was able to achieve time steps around 10 us.

[n-eiling]

I changed the clang format file so it enforces @stv0g comment style. If this does not work for you I would prefer that we fix the clang format file in a separate PR, because this gets really messy here.

[sonarcloud]

Quality Gate passed

Issues
79 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
5.0% Duplication on New Code

See analysis details on SonarCloud

[n-eiling]

I don't think the CI errors are caused by this PR. The tests are missing docker-compose. The tests also fail on master

[m-mirz]

@stv0g I think that the critical points are taken care of. Would you agree to merge?

[sonarcloud]

Quality Gate passed

Issues
73 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
5.0% Duplication on New Code

See analysis details on SonarCloud

[n-eiling]

@stv0g ping :)

[n-eiling]

@stv0g ping!

[n-eiling]

@stv0g pong!

[n-eiling]

@m-mirz can you just merge it without steffens approval? I addressed the most important points of his review and the remaining points are not really critical.

I have quite a bit of changes depending on this that have been waiting for this PR for months now.

I think the important issues are addressed and we should move forward with this.