Synchronous Slow DAC

[tknopp]

I am splitting this off from #12 which is for the slow ADC.

I have tested the "synchronous" slow DAC code (https://github.com/tknopp/RedPitayaDAQServer/blob/master/src/server/daq_server_scpi.c#L413) and it works more or less. Sometimes everything is fine but sometimes the thread is not fast enough. This happens in particular if data is collected from the host. In that case 3 threads are active (acquisition thread, slowDAC thread and main thread) and this leads to unpredicted timings (The rp has only two cores). I have played around with real-time scheduling but have not reached a satisfying result.

Proposal:

I think we should try moving the slow DAC thread on the FPGA. I will specify it in a way that its not MPI specific:

• The fast ADC and DAC are synchronized on the FPGA using an external trigger. When this trigger happens I hope that there is a way to get a counter i that is basically the 125MHz clock.
• Now we use a LUT called slowDACLUT Lets say it has N entries. We further upload some delay cycle L.
• Then the slow DAC should be updated every L frames whereas the values are taken from the LUT. After one sweep through the N entries again the first entry is taken

Questions: Is this design feasible? Is uploading the LUT feasible? We would need to have it dynamically. So maybe we would need to allocate a larger buffer (i.e. 2000 entries) and only use the first N entries of that. This is how the RP image applies an "arbitrary waveform".

[jonschumacher]

Well, this could work. The best way would be to use a LUT in RAM which is accessed from the FPGA via DMA, but this is (quite likely) more work than your proposal. The problem which might arise with your proposal is, that with the current imlementation for getting stuff from the memory via GP bus a value is read every cycle. Therefore the whole sub-LUT has to be loaded at once, which might be too much for the bus.

[tknopp]

this is basically implemented now.