• Joined on 2020-07-18
dpn commented on issue M-Labs/artiq#1647 2026-01-18 19:05:36 +08:00
Firmware panic in network code

How do I do this?

artiq_coremgmt log set_level and then also artiq_coremgmt log set_uart_level if monitoring via UART (which I tend to do, and is probably a good idea when debugging…

dpn commented on issue M-Labs/artiq#1647 2026-01-18 19:05:36 +08:00
Firmware panic in network code

Hmm, could this point to a hardware issue (e.g. power supply stability)? Or maybe the crash is related to the RTIO analyzer, if you have that enabled? (which would cause changes to the network…

dpn commented on issue M-Labs/artiq#1647 2026-01-18 19:05:35 +08:00
Firmware panic in network code

Could you post the code/related snippets for everything involving the handling of rtios? There are some related bugs where the compiler accepts invalid code (see #1394 and related). I've seen…

dpn commented on issue M-Labs/artiq#1642 2026-01-18 19:05:30 +08:00
Urukuls in 1-EEM and 2-EEM modes cannot be used together

It may be worth to document the slightly neater workaround (make a trivial subclass of AD9910 that's used for one variant, so the compiler doesn't attempt to unify them) and add it to the…

dpn commented on issue M-Labs/artiq#1639 2026-01-18 19:05:27 +08:00
Restore Urukul Switch TTL MonInj

+1 for bringing back the RF switch override, most people here would find this very useful, especially in the early days of setting up an experiment. In fact, the absence of a "force-off" override…

dpn commented on issue M-Labs/artiq#1629 2026-01-18 19:05:21 +08:00
Dashboard target name error

Yes, this was a somewhat unfortuate consequence of the renaming in 92eb3947a40c7b2bd3c31a649e3ad1c95667c5fd – unfortunate, as it more tighly coupled master and dashboard versions than usually…

dpn commented on issue M-Labs/artiq#1629 2026-01-18 19:05:21 +08:00
Dashboard target name error

We need to be able to make breaking changes to the code in order to move forward.

Oh, yes, definitely, and I wouldn't want to suggest otherwise (especially with my ARTIQ contributor hat on);…

dpn commented on issue M-Labs/artiq#1624 2026-01-18 19:05:16 +08:00
dashboard/master: Calling setattr_argument() for the same key but different type raises a TypeError on the master

The second call to self.setattr_argument(key,...) should internally update the type of the argument.

I think as a user I'd prefer getting a clear error message on the experiment side…

dpn commented on issue M-Labs/artiq#1610 2026-01-18 19:05:06 +08:00
Impossibility of using spare Urukul alongside with SUServo

To work around this, you can make a subclass of CPLD (empty body) that is used in the device db for the suservo Urukuls. This is what we do in Oxford internally.

Of course, we should…

dpn commented on issue M-Labs/artiq#1599 2026-01-18 19:04:55 +08:00
Dashboard does not close on Windows

This is a qasync bug, see 5f6580ee3b. It should go away with qasync 0.25 or 0.26. They have just managed to…

dpn commented on issue M-Labs/artiq#1596 2026-01-18 19:04:54 +08:00
Get rid of kasli.py

We are still using the base classes (MasterBase, etc.) for custom gateware internally that is not exposed via the JSON interface here, so "getting rid of kasli" should only involve the default…

dpn commented on issue M-Labs/artiq#1582 2026-01-18 19:04:45 +08:00
artiq_ddb_template.py does not add leds to most variants

ps7 is the processing system, i.e. the ARM cores. Some pins can only be accessed through the CPU.

dpn commented on issue M-Labs/artiq#1580 2026-01-18 19:04:41 +08:00
external clock stopping not reported by core devices

Agreed that loss of reference clock or any other PLL issues should have very obvious consequences. This would likely involve polling the Si5324 and generating a panic (or at least some kind of…

dpn commented on issue M-Labs/artiq#1574 2026-01-18 19:04:36 +08:00
compiler: arguments with default value not working in delay_mu

We should just strip out any remaining special handling of delays from the compiler; this has long been unused. delay_mu should just be handled the same as any other runtime intrinsic.

dpn commented on issue M-Labs/artiq#1572 2026-01-18 19:04:35 +08:00
compiler: int64 indexing of ndarray typechecks but crashes artiq_ir_generator

Just to be clear, the question here is just how to resolve the original issue, where the problem is that the multi-dimensional indexing code (sensibly) ends up working with TInt32 internally, but…

dpn commented on issue M-Labs/artiq#1572 2026-01-18 19:04:35 +08:00
compiler: int64 indexing of ndarray typechecks but crashes artiq_ir_generator

Not sure what the consequences of that should be. Do we want to support arrays > 2^31 elements in ARTIQ Python on those targets? Even if so, this still is largely orthogonal to the question of…

dpn commented on issue M-Labs/artiq#1572 2026-01-18 19:04:34 +08:00
compiler: int64 indexing of ndarray typechecks but crashes artiq_ir_generator

@sbourdeauducq (and @thomasfire / @SquidDev): Any thoughts on requiring TInt32 (assuming 32 bit targets) for array indexing?

The alternative would be to consistently cast the TInt32 to…

dpn commented on issue M-Labs/artiq#1572 2026-01-18 19:04:34 +08:00
compiler: int64 indexing of ndarray typechecks but crashes artiq_ir_generator

It seems like we are currently just silently accepting (and truncating?) TInt64 indices in other places. I wonder whether this is worth preserving, or whether it would be fine just to strictly…

dpn commented on issue M-Labs/artiq#1572 2026-01-18 19:04:34 +08:00
compiler: int64 indexing of ndarray typechecks but crashes artiq_ir_generator

Any idea why we are not requiring TInt32 (or, more generally, ssize_t) for array indexing in general? a2fbcb8bfd/artiq/compiler

dpn opened issue M-Labs/artiq#1572 2026-01-18 19:04:34 +08:00
compiler: int64 indexing of ndarray typechecks but crashes artiq_ir_generator