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
cr1901 has joined #m-labs
sb0 has joined #m-labs
<sb0> 5 iirc
fengling has joined #m-labs
<whitequark> sb0: re qt: i suggest learning why the pimpl pattern exists before ranting about it
<whitequark> re #318: yes, I'll finish it soon
<whitequark> re Aleksey: he never figured out how to run the GUI on Windows. some problem with the simulator.
<sb0> whitequark, you should fix more of the qt problems.
<sb0> what simulator?
<sb0> and i have read the pimpl arguments, and I disagree
<whitequark> what do you disagree with? that maintaining a stable ABI is valuable?
<whitequark> the simulated core device
<whitequark> I never really figured out what the problem was, we went back and forth a few times...
<sb0> it is valuable, but qt is such a mess that you need to hack things up all the time
<sb0> I was able to fix the problem this time because the model stuff has so many bells and whistles, but I may not always be so lucky
<sb0> you don't need the simulated core device to run the GUI
<whitequark> the dashboard tries to connect to localhost:3251...
<sb0> huh that's not the simulated core device, that's the master
<whitequark> sure
<whitequark> you need a simulated core device to run the master, right?
<sb0> no
<sb0> the master doesn't care what you run on it
<whitequark> oh
<sb0> it works this way: the master spawns a worker process, and the worker process creates all the device drivers based on information he gets from the master via IPC pipes
<sb0> the workers don't even need a core device at all
<sb0> the core device is only accessed when the experiment does get_device/setattr_device("core")
<sb0> plus, the GUI can run without the master creating any workers
<whitequark> I see
<whitequark> annotations done
<GitHub37> [artiq] whitequark pushed 1 new commit to master: https://git.io/v6sEe
<GitHub37> artiq/master 5a2306a whitequark: compiler.embedding: implement type annotations for function arguments....
FelixVi has quit [Quit: Leaving]
<bb-m-labs> build #585 of artiq-kc705-nist_clock is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-kc705-nist_clock/builds/585
<bb-m-labs> build #298 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/298
<bb-m-labs> build #860 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/860
<GitHub163> [artiq] whitequark pushed 1 new commit to master: https://git.io/v6suX
<GitHub163> artiq/master 1a518ea whitequark: compiler.embedding: implement string concatenation....
sb0 has quit [Quit: Leaving]
fengling has quit [Ping timeout: 240 seconds]
<bb-m-labs> build #586 of artiq-kc705-nist_clock is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-kc705-nist_clock/builds/586
<bb-m-labs> build #299 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/299
fengling has joined #m-labs
<bb-m-labs> build #861 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/861
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
fengling has joined #m-labs
sb0 has joined #m-labs
<sb0> whitequark, thanks. can you mention them in the docs?
<sb0> rjo, what is the typical pressure you get from water desorption in a unbaked vacuum system after a few days?
<sb0> stainless steel
<sb0> and titanium of the ion pump
<sb0> and I mean after a few days of non-pumping
sandeepkr has quit [Ping timeout: 258 seconds]
<sb0> with the all-metal valve shut
<sb0> and initially pumped down to 10^-7 with the ion pump for a couple hours
sandeepkr has joined #m-labs
sandeepkr has quit [Read error: No route to host]
FabM has joined #m-labs
sb0 has quit [Quit: Leaving]
key2 has joined #m-labs
<key2> hi
sandeepkr has joined #m-labs
sb0 has joined #m-labs
<key2> sb0: I got the csr working with wishbon.
<key2> sb0: when I have a module that has some csr, and I add it as a submodules of a topmodule. does the self.get_csrs() get the csr of the submodules as well ?
<sb0> yes
<sb0> or more exactly - attributes
<key2> mmh
<key2> so am doing something wrong
<key2> I have a class foo(Module, AutoCSR) which has 4 CSRStorage()
<key2> when I add it to another module, and from this one I do csrs = self.get_csrs() it doesnt get the csrs of foo
<key2> I have to do csrs = inst_of_foo.get_csrs() to get them
<key2> so after I did inst_of_foo = foo() then self.submodules += inst_of_foo
<key2> I should do something to add to self the csrs of inst_of_foo ?
<sb0> well, read the misoc source. it's not very complicated...
<key2> also is it possible to generate a file that tells you what CSR has been mapped where ?
<key2> in the code, that's how you do it:
<key2> self.submodules.timer_kernel = timer.Timer() self.register_kernel_cpu_csrdevice("timer_kernel")
fengling has quit [Ping timeout: 240 seconds]
<key2> so each register like that would create a new wishbone bus if I get it correctly
<sb0> yes, misoc has an option to export the map to csv
<key2> but how would I get all the CSR of all submodules on the same wishbone bus ?
<key2> and then a map (why not in csv) of all of them on that bus created
<key2> rather than one slave wishbone bus per CSRBank
<rjo> sb0: for that system after you pump it cold, close the valve, keep pumping, get to 1e-7, turn of the pump, wait for a few days, i would guess anywhere between 1e-4 and 1e-6. but how are you measuring? using the pump?
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
<sb0> yes
<sb0> so there can be "burping" problems too
<sb0> there is also a titanium flake problem that destroyed two DMMs I used to measure the current when first turning on the pump... but this has gotten better now
<sb0> but those pressure values are consistent with those I got when I had an ion gauge instead of the window. but I was suspecting the ion gauge feedthrough
<sb0> would you think there is no leak problem and I should just bake it out?
<sb0> I do get between 1e-4 and 1e-6 doing exactly what you say
<rjo> the pump as a gauge is tricky. i'd be surprise if you can measure below ~1e-7 at all. and if you turn on the pump to measure you should quickly get back to maybe 3e-7 within maybe minute or less.
<sb0> yes, the current does drop in a few mins
<sb0> right now I cannot get below 1e-7 at all, even after more than a day of pumping (valve shut + ion pump on)
<sb0> measured by ion gauge
<sb0> could it be just the wet HK air that deposits a thick layer of water, or is there more likely a leak?
<rjo> and measuring the ion current should be done with lots of protection/bypass or directly using the power supply.
<rjo> could be a leak, could be dirt.
<sb0> http://www.nat.vu.nl/~koel/131023_IonTech2_Koelemeij.pdf says 1e-7 is what you are supposed to get before bakeout
<rjo> whether the water layer is just a monolayer or a several HK monolayers does not matter much.
<rjo> depends on a lot of factors.
<rjo> sure. go ahead. there is nothing particularly dangerous when baking, even with a leak.
<sb0> if the vacuum window breaks (or a large leak otherwise develops), can it damage the ion pump?
<rjo> if you want to get some experience with this you can do a small bake to e.g. 60 or 80 C for a few hours and back down.
<rjo> depends on how quickly the inrush is. if it is really fast, the ion pump will just get to the high pressure side quickly and just do nothing. if it is a medium leak then your power supply should trip at maybe ~7 mA or better yet just go constant current and down with the voltage and you are good.
<rjo> and the rest of the damage is oxidization of the inside of your system (which is usually actually beneficial).
<sb0> well, I just hacked up a power supply with microwave oven parts, variac and light bulb
<sb0> with the light bulb the max current is a dozen mA, but it doesn't trip
cr1901 has quit [Ping timeout: 240 seconds]
<rjo> the damage that i see is a glow discharge that heats up and erodes the electrodes. but i have little experience with things going that wrong during a bake.
<rjo> what voltage are you running it at?
<sb0> 3.5kV
cr1901 has joined #m-labs
<rjo> iirc we usually run them at 7kV when current is < 2mA
<sb0> hm
<sb0> what voltage can "2100VAC" microwave oven caps take?
<sb0> I don't understand the "AC" voltage rating of capacitors...
<sb0> the power supply can go to 7kV with the variac at max, if the caps don't blow up. they'd get 3.5kV each
<sb0> microwave oven caps from china are amazingly cheap. less than 50 USD cent a piece
<sb0> 1uF 2100V "AC"
<sb0> hmm, according to http://www.stevehv.4hv.org/MOCs.htm they could take some serious abuse
<cr1901> sb0: What's wrong with guessing 2100 Volts, Alternating Current? :P
rohitksingh_work has quit [Read error: Connection reset by peer]
<sb0> rms or peak?
<cr1901> sb0: I imagine it's RMS; that from my experience is "industry standard"
<cr1901> So multiply by 1.4 to get the peak and call it a day
<larsc> usually it is RMS
<cr1901> (pedantic: If you're using a square wave, it's not multiply by 1.4... I don't remember what to do in that situation)
<larsc> if it is centered around zero it is just the voltage itself
<larsc> but anybody who says VAC probably means sine wave
<sb0> ok, so they should take 3kVDC
<sb0> why do people have capacitors spec'd in VAC?
<cr1901> sb0: I would not put constant 3kVDC across them. Wouldn't "peak" be a short term voltage that they could handle?
<sb0> well according to the 4hv page some blow up at >10kV
<larsc> well, what could go wrong
<cr1901> larsc: Famous last words :)
<cr1901> Also doesn't help that I associate that phrase with a terrible video game mascot
<whitequark> sb0: electrolitics differ in construction for VDC and VAC
<sb0> they are oil capacitors
<whitequark> oh. no idea then
<key2> Is there somewhere a simulation of a module that has a Record () basically I want to know how to drive it from the tb
<sb0> you just drive it like other signals. yield record.field.eq(xxx)
<key2> thx
<key2> sb0: I'm doing my crc for the sdcard module I am writing, is it a bad design to use crc tables ?
<key2> sb0: that is my crc7 calculation, http://pastebin.com/B8CkmThW It works, but I am learning so far, so any comment would be welcome
<larsc> depends on the size of your crc, but HDL is typically a place where actually calculating the crc is faster than using a table
<larsc> compared to software where the alternative is true
<key2> mmh
<key2> ic
<key2> thanks
<key2> but in my case, in 1 clock per byte I calculate the crc
<key2> if I had to calculate it, it would take 1 clock per bit
<key2> as crc requires shifting at each bit
<larsc> you can do it in parallel
<larsc> even more than 8 bits at once
<key2> ah
<key2> interesting
<larsc> maybe the tools are smart enough to reduce your table to the equivalent logic of a native implementation
<key2> right now the generated code does not
<larsc> with your current implementation each output bit depends on each input bit
<larsc> whereas with a crc usually that is not the case
<larsc> most output bits only depend on a single input bit and a few depend on 2 or 3 input bits
<larsc> which is much smaller logic
<larsc> e.g. you can fit two bits into a single LUT6
<larsc> whereas with your current implementation you need two LUT6s per bit
<key2> ic
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 244 seconds]
rohitksingh has joined #m-labs
<sb0> larsc, have you looked at the 8b10b code?
<larsc> shortly
<larsc> the good thing about 8b10b is since it is composed of 3b4b and 5b6b you can put it into a single LUT per bit
<larsc> or even a single LUT per 2 bits probably
<larsc> so in that case the table approach is just as efficient
<larsc> at least for encoding
<larsc> hm, you still need the disparity for encoding, so 1LUT per bit for the 5b6b part
<larsc> or why were you asking?
<sb0> someone bickering about a lack of documentation of this code. wondering if it's *that* hard to understand...
<larsc> oh no, the log is down
<larsc> I don't have the link anymore
<sb0> link to? the code?
<larsc> well the Encoder and Decoder are nice and simple
<larsc> do you get a carry chain for disp_out?
<sb0> I hadn't thought of that. good idea, it would be nice to get it to map there
key2 has quit [Ping timeout: 250 seconds]
acathla` has joined #m-labs
acathla has quit [*.net *.split]
jaeckel has quit [*.net *.split]
<larsc> I was just wondering if the tools are smart enough to do that by themselves somehow
<larsc> it should map
<larsc> disp_inter might be a problm
jaeckel has joined #m-labs
Gurty has quit [Quit: Kooll ~o~ datalove <3³\infty]
sb0 has quit [Ping timeout: 276 seconds]
<larsc> no, it maps quit well
rohitksingh has quit [Quit: Leaving.]
Gurty has joined #m-labs
<larsc> sb0: I think you can simplify disp_out to just disp_in ^ code4_balanced ^ code6_balanced
<larsc> alt7 does not affect the disparity of the symbol
<larsc> just the order of the bits
<larsc> so in that case it really is just a half-adder
<larsc> k28.7 creates the wrong disparity
<larsc> can be fixed by the same change though
acathla` is now known as acathla
cr1901 has quit [Ping timeout: 250 seconds]