sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
sh4rm4 has quit [Ping timeout: 265 seconds]
sh[4]rm4 has joined #m-labs
rjo has quit [Ping timeout: 264 seconds]
rjo has joined #m-labs
sh4rm4 has joined #m-labs
sh[4]rm4 has quit [Ping timeout: 265 seconds]
sh4rm4 has quit [Ping timeout: 265 seconds]
fengling has joined #m-labs
sh4rm4 has joined #m-labs
<rjo>
sb0: the pdq2 sample rate is 50 M/s or 100 M/s if the CRG has been configured to use the doubled clock with Pdq2.cmd("DCM", True)
<rjo>
sb0: at the mediator level the transport.py example is the dominant use case. the mediator should generate rpc-pdq2-programs for that.
<rjo>
but i will make pdq2_client.py do something useful as well. basically what the current pdq2 client from the pdq2 repo does.
<rjo>
sb0: why did we say we wanted duration in samples but the amplitude coefficients in volts?
<rjo>
and what did we want the phase units to be. radians?
<rjo>
the tricky thing is rounding the coefficients. if you round the zeroth-order coefficients, and you wanted to be very accurate, you then want to correct the higher order coefficients for that rounding effect before you round them... and you want to do that sequentially.
<rjo>
_florent_: for litescope, a great way to do out-of-band readout -- without having to shuffle the modules that usually use ethernet/uart/usb -- would be to use jtag ;)
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #m-labs
sh4rm4 has quit [Remote host closed the connection]
sb0 has joined #m-labs
<sb0>
rjo, duration in samples, coefficients in volts, phase in turns
<GitHub77>
artiq/master bd145bb Sebastien Bourdeauducq: use %(default) in argparse
<GitHub77>
artiq/master 768fa21 Sebastien Bourdeauducq: lda_controller: show default product type
sb0 has joined #m-labs
<rjo>
the rounding problem is fundamentally the same as for the voltage coefficients (the thing i described above). It might be worse though.
felix_ has quit [*.net *.split]
felix_ has joined #m-labs
Zougloub has quit [*.net *.split]
Zougloub has joined #m-labs
<rjo>
actually, what you want to do is sample your spline at the already rounded intervals, then round the coefficients that you get in a rather complicated way, on each coefficient correcting for the rounding errors introduced by the earlier roundings...
<rjo>
sb0: you missed this: lHe is on the order of 10$/l
<rjo>
but i am undecided which is the best solution: a) all in digital/cycle/dac units b) the mixture as it is c) all in si units.
<rjo>
the other devices all take si units...
<sb0>
I'm following the logs... :)
<sb0>
rjo, I guess the zero-slack b-spline code could go somewhere in artiq.wavesynth
mumptai has quit [Remote host closed the connection]
sb0 has joined #m-labs
acathla has joined #m-labs
<acathla>
hi
<acathla>
wow, y'a du monde!
<sb0>
rjo, your faq.rst should go into m-labs/artiq/doc imo
<sb0>
(in artiq-notes)
<whitequark>
sb0: i've sent you some mail
<sb0>
on Sat/Sun?
<sb0>
you can go ahead with all the compiler stuff
<sb0>
i'm going to come up with a proof of concept for the migen python simulator. I believe it might not be as slow and unproductive as you think.
<sb0>
jtag yes, the flash proxies are very simple. we have one for the m1 as well (with parallel flash), which works with urjtag
<sb0>
whitequark, is there anything else you need answers for?
<sb0>
we are already flashing with that method. it's not that slow, and it's dominated by flash erase delays...
<whitequark>
ok gotcha
<whitequark>
seems like i'll have to write the parser. i was under impression that python folks had better tooling...
<whitequark>
well, at /least/ they have a sane grammar
<sb0>
I don't think that full Clang-style diagnostics are an absolute requirement, but it's always nice to have good software ;)
<whitequark>
personally I think they are. I mean, I spent two years on a language that statically compiles a dynlang (Ruby)
<whitequark>
er, on a compiler
<whitequark>
given inference--and you basically have inference here--it's really not fun to hunt for the particular subexpression that caused the error
<whitequark>
they're hard enough to diagnose anyway