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
sturmflut-work has quit [Ping timeout: 272 seconds]
sturmflut-work has joined #m-labs
FabM has joined #m-labs
<sb0> I have time/voltage points, I want lines and their coefficients
<sb0> should I do a polynomial fit? how?
<sb0> or should I have some predefined polynomial interpolation between consecutive points in the array?
FabM has quit [Remote host closed the connection]
FabM has joined #m-labs
travis-ci has joined #m-labs
<travis-ci> fallen/artiq#51 (controller_cleanups - 0e15db9 : Yann Sionneau): The build passed.
travis-ci has left #m-labs [#m-labs]
sb0 has quit [Quit: Leaving]
travis-ci has joined #m-labs
<travis-ci> fallen/artiq#52 (controller_cleanups - 1637d1d : Yann Sionneau): The build passed.
travis-ci has left #m-labs [#m-labs]
travis-ci has joined #m-labs
<travis-ci> fallen/artiq#53 (influxdb_bridge - 6717552 : Yann Sionneau): The build was broken.
travis-ci has left #m-labs [#m-labs]
travis-ci has joined #m-labs
<travis-ci> fallen/artiq#54 (influxdb_bridge - b6dd91d : Yann Sionneau): The build was fixed.
travis-ci has left #m-labs [#m-labs]
fengling has quit [Quit: WeeChat 1.0]
rjo has quit [Ping timeout: 264 seconds]
rjo has joined #m-labs
nicksydney has quit [Ping timeout: 244 seconds]
nicksydney has joined #m-labs
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 272 seconds]
<mog> did you guys see news today about lattice bitstream format being reverese engineered
nicksydney has joined #m-labs
nicksydney_ has quit [Read error: Connection reset by peer]
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 272 seconds]
nicksydney has joined #m-labs
nicksydney_ has quit [Ping timeout: 272 seconds]
nicksydney has quit [Quit: No Ping reply in 180 seconds.]
nicksydney has joined #m-labs
mumptai has joined #m-labs
sh4rm4 has joined #m-labs
<larsc> for latice?
<larsc> in case somebody didn't see it http://www.clifford.at/icestorm/
aeris_ has quit [Quit: en a pas]
aeris_ has joined #m-labs
nicksydney has quit [Ping timeout: 272 seconds]
nicksydney has joined #m-labs
<mog> ya
<mog> fpgatools got an update 8 days ago too for the first time in a year
<whitequark> whoa
<mog> ya i was surprised to
<mog> the last time i tried it didnt work on my chip
<mog> but i didnt have bga style like he was using
aeris_ has quit [Ping timeout: 246 seconds]
sb0 has joined #m-labs
aeris_ has joined #m-labs
<GitHub102> [artiq] sbourdeauducq pushed 2 new commits to master: http://git.io/hFaX
<GitHub102> artiq/master 2651050 Yann Sionneau: Controller cleanups
<GitHub102> artiq/master 91336f9 Yann Sionneau: lda_controller: replace serial argument with device one
sh[4]rm4 has joined #m-labs
sh4rm4 has quit [Ping timeout: 265 seconds]
sb0 has quit [Quit: Leaving]
nicksydney_ has joined #m-labs
nicksydney has quit [Ping timeout: 245 seconds]
nicksydney has joined #m-labs
nicksydney_ has quit [Ping timeout: 245 seconds]
<rjo> sb0: re units. yes. but why did we not say seconds for the duration if we say volts for the coefficients (or the other way around)?
<rjo> sb0: the spline the zero-slack b-spline. the pdq2 repo has the code.
<rjo> sb0: but since i will be writing the pdq2_client that will also use this code, it can be reused.
<rjo> i think i can implement that code this afternoon and make it reusable both in the cli client and the mediator.
sb0 has joined #m-labs
<sb0> rjo, how would we handle the divider then? and wouldn't scaling the coefficients to match the sample rate introduce significant rounding errors?
<sb0> rjo, btw - how much is one liter of liquid helium?
sb0 has quit [Quit: Leaving]
<rjo> on the order of 10$/l
<GitHub77> [artiq] sbourdeauducq pushed 3 new commits to master: http://git.io/hNqu
<GitHub77> artiq/master b597483 Sebastien Bourdeauducq: thorlabs_tcube: spelling, fix ping
<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
<rjo> sb0: yes.
travis-ci has joined #m-labs
<travis-ci> m-labs/artiq#66 (master - 768fa21 : Sebastien Bourdeauducq): The build passed.
travis-ci has left #m-labs [#m-labs]
sb0 has quit [Quit: Leaving]
aeris has quit [Quit: en a pas]
aeris has joined #m-labs
nicksydney has quit [Ping timeout: 245 seconds]
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