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.

[stv0g]

I find the name "DCGenerator" pretty confusing. Isnt it just a constant value? Can we call it "Constant"?

@m-mirz Whats your opinion on this?

[m-mirz]

Yes, constant is better. Generator is already used for the equipment type.

[n-eiling]

I think not naming it Generator would be quite confusing, because all other classes used for generating the signal of a voltage source are called generator. Constant is also a bad name, because the value generated is not constant at all. Also ConstantGenerator is a pretty weird name.
I'm open to another name if you can think of a good one.

[stv0g]

Constant is also a bad name, because the value generated is not constant at all.

Can you elaborate? I thought the purpose is to produce a constant (non oscillating) signal?
Maybe we can simply get rid of it and just use a Sine wave generator using a frequency of 0?

[n-eiling]

The sine wave generator is too slow.

[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