Implementation of the "extended interface" - to make use of the extended features of IPbus, E2bus or CBM DCA - how to implement RMW?

[wzab]

Implementation of the RMW functionality seems to be somehow difficult, if we want fully utilize caching.
The calling syntax on the bus interface level is:

rmw(self,address,mask,value,now=true) - schedules the read-modify-write
       operation defined as follows
       X:= (X and ~mask) | (value and mask)
       If "now" is true, the new value should be scheduled
       for writing.
       If "now" is false, the new value should be calculated
       and stored internally by the bus interface.
       The last call to rmw on the particular register should
       have "now" set to "true".

The idea is that we do not write the modified value immediately.
So a few operations may be concatenated, and only the final result may be written.
However the things are getting more complex if we realize that the read of the register value may return only the "future" that will be filled with real value only after dispatch.
It means, that the bus interface must accumulate the operations without knowing the initial value of the register...

[wzab]

The first implementation is in 0203d2c .
It combines the RMW operations, and then performs them in the aggregated form.
The problem however is, that when we want to schedule write in the finalize method of the RMW_cache class, the initial value of the register may be not available yet (the dispatch is not called yet).
If we try to access its value, we trigger dispatch :

agwb/targets/python/agwb/agwb.py

Line 334 in 0203d2c

dval = self.df.val | self.mask

So it means, that the finalize operation should be scheduled as a closure, with reference to the future, providing the initial value of the register.
It can be easily done in my DemoIface. But it may be non-trivial if we would like to use a real hardware interface (like IPbus or E2bus).
I'm afraid that it may mean that finally the optimized bitfield writing may be limited to consecutive accesses to the same address.
Then it may be translated into a single RMW command.

[wzab]

I have implemented a version that schedules finalization of the RMW command as a closure, containing the "future" object nested in the RMW cache object.
It is done in commit 92ce27e .

[wzab]

The current implementation in commit 92ce27e is tagged as ext_py_int_1_0.

Please note, that the template DemoIface now combines both: the gateway functionality and the HW backend
(the IPbus or E3bus controller in the FPGA).
It is the user's responsibility, how to split those functionalities and keep the number of high latency transactions (e.g.
via Ethernet or RPC) at minimum.

Another possible implementation does not use such caching at all, it simply accumulates consecutive RMWs, and
schedules the final, resulting one.