"Urukul AD9910 AUX_DAC mismatch"

max

As also discussed in https://github.com/m-labs/artiq/issues/940, when ungracefully killing a kernel, it can sometimes lead to the error from the title.

In the github issue, a workaround is mentioned, but not explicitly shown, as far as I can see.

Is it possible to handle this error without doing a hard reset of the whole system?

Thanks!
Max

sb10q

This is a feature of the AD9910 chip - an interrupted SPI transfer results in the chip locking up until it is power cycled.

It should be possible to make the error not occur most of the time by adding a special RTIO PHY that blocks incomplete SPI transfers and modifying the Urukul driver accordingly, but this is not simple or cheap.

sb10q

sb10q It should be possible to make the error not occur most of the time by adding a special RTIO PHY that blocks incomplete SPI transfers and modifying the Urukul driver accordingly

This does not require any hardware changes.

max

Ah, I understand. Is there any way to trigger a power cycle of the AD9910 on the Urukul board (or the whole system, for that matter) without actually having to physically unplug the PSU?

sb10q

No. The consensus was that the added complexity of the built-in power-cycler was not worth it because a number of applications cannot deal with interrupted RF anyway. The better solution would be a gateware/software workaround that prevents most lockups in the first place, but it is not currently clear how it would get funded.

max

I see.
I would argue, that an internal power-cycler, which allows for rebooting without physically touching the device would be of great value.
Would it be possible in principle to implement this doing gateware changes only, or are actual hardware changes required for that?

max

sb10q sb10q It should be possible to make the error not occur most of the time by adding a special RTIO PHY that blocks incomplete SPI transfers and modifying the Urukul driver accordingly

This does not require any hardware changes.

Right, but adding the special PHY you are talking about seems to be a pretty elaborate solution of one, very specific issue.

I was more thinking along the lines of a way to power-cycling the whole System remotely.
This would provide a clean way to always return to a well-defined state after somethings unexpected happens, be it a bug or some kind of user error.
This would then not be limited to this specific behaviour of Urukul/the AD9910.

Of course, the goal should always be, that this is not necessary, but because in reality, sometimes things just go wrong, remote power cycling would be a nice "last resort".

So, would the implementation of remote power-cycling of the whole system be doable in gateware only?

If yes, it might be something worthwhile to discuss further.
If no, we probably have to live with the status quo.