Running DMA and TTL Edge counters in parallel

han94ros

I am trying to playback a DMA handle and run the TTL edge counter function gate_rising in parallel, and even though the script runs without errors, the red lights on the AD9910 urukul board switches on alongside the existing green lights.
I have looked at the coremgmt log and this is related to the RTIO sequence errors. The sequence errors involve two channels, channel 29 and 0.

One solution is to increase the SED lanes but by how much can I safely increase the SED lanes in sed/core.py given that there is a corresponding increase in the FPGA usage?
`

            
            with parallel:
                     self.ttlcounter_0.gate_rising((self.list_t_duration[i]*0.2) * ns)

                     self.core_dma.playback_handle(self.list_of_pulses_handle[i])

han94ros

The sequence channel errors are on the urukul and zotino SPI channels. I have increased the number of SED lanes to 32 but that has not helped. The issue is that the TTL edge counter blocks one of the lanes until the end of the count period, but there should still be 31 extra lanes. With the edge counter commented out the code runs without sequence errors even with the default 8 SED lanes. Is there any way of checking the SED lane count change in a gateware rebuild?

I have ran the code in this issue https://github.com/m-labs/artiq/issues/1310 with increasing SED lane counts, 8, 16, and 32 but I am still getting sequence error on channel 5. Could you please tell me which other parameters I have to change in sed/core.py

rjo

I can't see the code that demonstrate the problem.
The best posts are those that supply a minimal working example demonstrating the problem. Try to limit your interpretation of the issues and add accurate observations, otherwise it might preclude successful debugging. It's unclear whether fiddling with the SED lane number will help. Do you know how many lanes you need?
Does the dma sequence certainly alone run fine?
Please determine what the channels are from their numbers. I presume 0 is the ttl you want to gate.
A problem could arise because the gate closure event is submitted early leading to lots of time cursor rewinds and blocking efficient lane usage. The typical solution is to manually open the gate (_set_sensitivity), then start the DMA and then submit the gate closure event at the end.

han94ros

rjo This is my code.

  for h in range(self.number_of_repetitions):
        for i in self.list_of_active_stages:
            t0 = now_mu()
            with parallel:
                self.ttlcounter_0.gate_rising((self.list_t_duration[i]*0.5) * ns)
                
                with sequential:
                    self.core_dma.playback_handle(self.list_of_pulses_handle[i])
                    self.sampler0.sample_mu_write(self.list_of_sampler_values[i]

            self.list_of_ttl_rising_edges_0[i] = (self.ttlcounter_0.fetch_count())
            delay((self.list_t_duration[i] * ns) - ((self.core.mu_to_seconds((now_mu()-t0)))))

`
I have made use of a modified sampler function which has been separated into sample_mu_write and sampler_mu_read. The sampler read is called outside of this main loop. Without the addition of the TTL edge counter the code runs without any sequence errors. However after the addition of the TTL edge counter there are errors on channel 29 and 35 which are the urukul and zotino SPI channels. I tried increasing the fifo depth on the SPI channels for these two devices but that did not help. Ultimately I am looking to incorporate 4 TTL edge counter channels. I will try the manual solution you have proposed. Could you please tell me what enable_spread does?

rjo

Also you could try just adding the sensitivity change events to your DMA recording. They are simple output events.

rjo

It controls the internal SED behavior when a SED lane if full. See https://github.com/m-labs/artiq/blob/bdaaf3c1d7fe362b9c741f4e8c13bca1e52d8874/artiq/gateware/rtio/sed/lane_distributor.py#L174

han94ros

rjo I have integrated the TTLInOut counters into the system using the set_sensitivity functions. Thanks for the advice.