<GitHub199>
[artiq] sbourdeauducq closed issue #640: experiments submitted with Flush=True cannot interrupt other experiments https://github.com/m-labs/artiq/issues/640
<GitHub102>
[artiq] sbourdeauducq commented on issue #640: This is not a bug, "flushed" previously meant "nothing else ahead of us", which is a perfectly valid definition. It now means "nothing else ahead of us at our and higher priority levels".... https://github.com/m-labs/artiq/issues/640#issuecomment-303065887
<rjo>
sb0: yes. kasli gets ethernet on sfp.
<rjo>
hartytp: back from vacation. that's one reason i'd like to keep the backplane for kasli in mind. depending on the pin numbers you can run additional EEMs from there.
<rjo>
hartytp: re #191 and your Ca+Sr setup. do you plan to _just_ use two saymas plus sevaral kaslis? we haven't planned for that. we'd usually expect to have one Metlino as well. you'd get 3 SFP from metlino and 2 SFP from each sayma. (DRTIO switch support is a requirement then).
hartytp has joined #m-labs
<hartytp>
rjo: at the moment we don't have a fixed plan, we're just trying to figure out our options.
<rjo>
hartytp: the AD9912 don't have ASF functionality.
<sb0>
hartytp, doesn't ad9910 have this silicon bug that causes output glitches on io_update?
<hartytp>
would need to recheck that.
<hartytp>
Or, rather, need to check more carefully what circumstances that occurs under
<sb0>
hartytp, have you used the 9914 at all?
<hartytp>
Nope. But, I'd guess it has similar bugs. and, I'd like to avoid it due to power dissipation/cost
<hartytp>
My guess is that the AD9910 glitches don't occur when the reset phase on IO_UPDATE mode is not enabled. If so, it's not a problem for the use cases we have planned. I can check this later today if we need to
<hartytp>
But, maybe rjo needs the 48-bit FTW of the AD9912?
<rjo>
hartytp: for opticlock we could even just regulate slowly via the laser currents. or coarse via the attenuator.
<hartytp>
rjo: other than requiring more gateware (DRTIO switch) is there a major disadvantage to using Kasli as the core device?
<rjo>
hartytp: how dependent are you on 1 GHz DDS clock? do you guys tend to have lots of >200 MHz AOMs?
<hartytp>
200MHz is our highest centre frequency IIRC. So, we'd like to go to at least 300MHz but ideally 400MHz
<rjo>
hartytp: no SAWG, no fast ADCs, no fast DACs.
<rjo>
hartytp: i thought so.
<hartytp>
Well, one can get a small number of them via DRTIO though, right?
<rjo>
hartytp: there is no gateware for that and the gateware might not fit the Kasli FPGA.
<rjo>
hartytp: but in principle you are correct.
<hartytp>
what gateware is needed exactly?
<rjo>
to drive fast DACs in a sensible way? something like SAWG.
<rjo>
to handle fast ADCs? depends on the application. PID loops should be doable. but most likely not 60 of them.
<hartytp>
Maybe I've misunderstood, but I though the SAWG only has to go on the Sayma FPGA, not on the core device?
<rjo>
hartytp: correct. SAWG would be where the fast DACs are.
<rjo>
but that also applies to kasli if it were to drive fast DACs.
<hartytp>
I'm assuming that the Kasli core device never drives fast DACs/ADCs directly, but only via DRTIO links (e.g. to a Sayma)
<hartytp>
In fact, that no Kasli ever drives a fast DAC/ADC directly.
<hartytp>
e.g. for the intensity stabilisation loop I have in mind, we'd have a dedicated Kasli DRTIO slave device that controlled ~10 DDSs, with MSPS ADCs for a servo loop
<hartytp>
that needs pretty minimal resources, right?
<rjo>
for those 10 PID loops in gateware?
<hartytp>
yes
<hartytp>
Can't remember what our current 8CH MSPS noise eater uses, but I don't think it was at all big
<rjo>
the control (rtio clock domain), the SPI command generator, and the arbitration with the other DDS commands on the SPI bus may be the biggest resource user here.
<rjo>
and it is decidedly single-purpose. would be hard to generalize it to other DDS and other bus architectures, command formats...
<hartytp>
ACK. Do you think that will be a problem for Kasli's FPGA? If so, should we consider something a bit bigger?
<hartytp>
True, there will have to be some special purpose stuff in there, but that's usually the case. And, it's mainly pretty trivial AFAICT
<hartytp>
I'm open to other suggestions of how to do this, but I'd ideally like to have an option that doesn't involve Sayma if we can
<rjo>
hartytp: could you spell out the specifications for that (artiq or sinara wiki page)? loop bandwidth, which IIR functions (p,i,i,d), integrator-hold, limiter, re-lock, modulation, demodulation, number of loops, how you expect to use the SPI bus while the loop is running, etc, etc
<hartytp>
The majority of what we do is apply a switched CW, fixed-frequency to an AOM with a basic PI servo. For that Sayma is vast overkill
<hartytp>
Drawbacks of Sayma include: cost; lead-time; power consumption etc etc
<hartytp>
Having an option based on cheap few-layer boards such as Urukul that we can solder up ourselves and hack trivial gateware is very appealing
<rjo>
hartytp: agreed. bus "basic PI" (integ-hold is not basic PI IMHO) and "fixed-frequency" (i.e. SPI arbitration) is what we need to think about.
<rjo>
hartytp: absolutely agree on the general idea.
<hartytp>
okay, I'll jot something down after lunch.
<rjo>
the implicit cast is not technically useful?
<whitequark>
no, what I'm saying right now is not useful in fixing the bug
<whitequark>
sb0: yes. add a valid_form for int(x:bool)->numpy.int? and add builtins.is_bool to the condition
<whitequark>
and a check to the lit test that handles int(1.0) and such
<whitequark>
the precise argument/result type for casts is erased in the IR hence no changes there are neede
<rjo>
so is_numeric(TBool) should still be false?
<whitequark>
yes
<whitequark>
well
<whitequark>
>>> list(range(False, True))
<whitequark>
[0]
<whitequark>
hrm
<whitequark>
what a ridiculous design for booleans
<rjo>
they always felt numeric to me...
<whitequark>
booleans are a `type bool = True | False` and treating them any other way leads to unnecessary logic errors
<whitequark>
python manages to add even more unnecessary logic errors with the implicit conversion into boolean by `if`
<whitequark>
all of that should have never been done or at least ripped away in py3 but we're stuck with it i guess
<whitequark>
well
<whitequark>
to think a bit more about it, is_numeric is for int|float
<whitequark>
and python doesn't treat booleans as numerics, it treats them as int(width=1) essentially
<larsc>
you are thinking about this too academic. Strict typing is not programmer friendly
<whitequark>
larsc: you have stockholm syndrome from writing too much c, sorry. i know it is painful but unlearning this habit will improve your code.
<larsc>
The problem is it does not sell
<whitequark>
i'm also generally not interested in discussing this because weak typing will disappear the way the `goto` statement did in not so much time
<whitequark>
that's untrue even if you were talking about the ridiculous "static vs dynamic typing" discussion, but for weak typing it is untrue in the most obvious way
<larsc>
I'm on your side, I think a good type system is essential. But there are a lot of people who would say it is a hassle
<larsc>
bad engineering can easily be offset by faster technology
<whitequark>
i do not feel a need to argue in favor of the statements above because nearly every improvement in the field of languages validates what i say
<whitequark>
it's just boring
<whitequark>
rjo: more on topic. it's possible to treat booleans as int(width=1). but it will break some assumptions in artiq code itself (those are few and they will be easily fixed), on the other hand it will significantly reduce ergonomics
<whitequark>
well, you could have an int(width=?) literal unified with True
<whitequark>
i think it's actually better to provide special forms of primitives (which we mostly do) and coercions (which I think we already cover all) for the same effect
<whitequark>
do we really not handle that? i'm surprised
<whitequark>
sec
<rjo>
i can just add it there.
<whitequark>
i want to see why it breaks, because i think we may miss some other cases
<whitequark>
doing it now.
<whitequark>
rjo: yes. we do miss them. we do not handle bool->int coercions in almost all cases
<rjo>
yes. certainly not the implicit ones (True << 1).
<whitequark>
rjo: on reflection, bool should be a numeric type.
<whitequark>
let me try to see if this will cause any major fallout.
<rjo>
whitequark: ;)
<whitequark>
well.
<rjo>
whitequark: alternatively, sketch the solution here and i'll do my best implementing it.
<whitequark>
there's a proper solution but it's really tedious.
<whitequark>
we need a new category for "int or bool", and we need to accept it almost everywhere is_int is currently used. but not everywhere as this will cause codegen issues, potentially
<whitequark>
this is the place where i grumble to larsc about python lacking 'strict typing' (really, ADTs), making it impossible to safely refactor such things *even with 100% test coverage*, but without a fuzzer or something.
<whitequark>
so i think for now is_numeric will suffice
<whitequark>
rjo: okay, so, let me sketch it.
<whitequark>
add bool to is_numeric (obviously). grep for every use of is_numeric in the compiler (there are only 12, thankfully). write a lit test for every code path inside those branches, and verify that it matches host python
<whitequark>
that's what i do for every coercion when i write it myself
<whitequark>
rjo: then... look at all uses of is_int (but without a specific width) and consider whether they should also explicitly accept is_bool
<whitequark>
if you have an is_int32, probably not. if you have an is_int that unifies the width parameter with something else, probably not
<whitequark>
of primitives, only min, max and range should be changed
<whitequark>
of coercions, the question is more complicated
<whitequark>
looks like [] * True/False needs to be handled, bitwise ops will need to be handled (on both rhs and lhs)
<whitequark>
and I think that's it. less than what I expected.
<whitequark>
there are _coerce_numeric and _coerce_binop in inferencer.py that need updating, analogously to code paths for is_int
<whitequark>
and the second-to-last branch in process_Coerce in llvm_ir_generator.py should be generalized to treat booleans as integers as width 1, since that's what llvm does anyway
<whitequark>
for arithmetics the existing code paths look like they will handle booleans correctly already
<whitequark>
rjo: ah one more thing
<whitequark>
bool binop bool requires a widening numeric coercion, that will need special handling. so True:bool + True:bool = 2:np.int32
<whitequark>
I don't think we have any mandatory widening numeric coercions yet, np.int1 + np.int1 would wrap using existing logic.
<whitequark>
soooo, _coerce_numeric should have a branch where it checks for both lhs and rhs being bool, and widening.
<whitequark>
(just return it through assigning to `typ`. _coerce_numeric should probably be called _widen_numeric, that's all it does)
<whitequark>
rjo: i foresee a lot of tests here. and sb0 was asking why it took so long to write the new compiler back then...
<rjo>
ouch. i got thoroghly stuck with writing the lit tests already... will need to defer that project and work around it for now.
<whitequark>
what's the problem with lit tests?
<whitequark>
they're not super ergonomic but they're the best i got; using python unittest was far worse.
<whitequark>
gnerally cargo culting an existing similar test is the right direction
<rjo>
whitequark: i need to read up to the syntax, functionality etc.
<whitequark>
ah. yeah.
<whitequark>
unfortunately while lit is the right lit (llvm's) OutputCheck in pip is not
<whitequark>
someone decided to 'improve' it, unnecessarily breaking all syntax and removing like the third of useful functionality
<whitequark>
i'm quite sad about the whole thing
<whitequark>
in all honesty, i should have just ported my mini-lit extracted from llvm to python (it was in ocaml but a rewrite would be an almost mechanical task)
<whitequark>
*mini-outputcheck
<whitequark>
unfortunately i decided to save a day or two 1.5 years ago and now we have a hundred tests written with the broken one.
<hartytp>
rho: let me know what you think about all that (Kasli as master + Urukul servo)
<hartytp>
in particular, whether we can get ~1MSPS update rate.
<hartytp>
(for the servo). Doing this without 1 IDC per DDS requires some kind of SPI multiplexing (e.g. DDR).
<hartytp>
AFAICT, this would require a (small) upgrade to the SPI core, which is something we could probably fund
<hartytp>
We'd also need to upgrade Novogorny to run at 1MSPS per channel (again, this will probably require some SPI multiplexing to keep the IDC count reasonable).
<hartytp>
If we are going to go down that path, I'd like to let greg know asap to avoid wasting time testing the old version