<sb0>
"we were using a licensed design with which we were not certain how much influence at that time we could still have on the supplier selection."
<sb0>
yeah, right. mystery solved.
<sb0>
"The biggest step we’re making this year in our strategy to create a fairer supply chain is to design our own phone."
<sb0>
*popcorn*
sturmflut-work has joined #m-labs
<ccube>
whats the equivalent to VHDLs processs with a sensitivity list in migen?
<larsc>
none, everything is synchronous
<mithro>
I'm just trying to setup migen / misoc from scratch - should I log issues I have with the instructions on the github repos?
<sb0>
better, send a patch :)
<mithro>
sb0: I like to log an issue before creating a patch because I often don't get around to the patch part and at least you knew that I attempted something
<sb0>
ok...
<mithro>
sb0: you guys use the mailing list for patches right?
<sb0>
yes
<sb0>
you can open the issue on github
<sb0>
github is fine for a lot of things, but I don't like its pull requests
<mithro>
sb0: already doing, feel free to comment
<mithro>
sb0: do you guys have a style guide?
<sb0>
we've been talking for a while about switching to PEP8
<sb0>
artiq and new migen/misoc modules use PEP8
<sb0>
we still have to convert the existing code...
sh[4]rm4 is now known as sh4rm4
FabM has joined #m-labs
<mithro>
sb0: yeah, github pull requests suck - I still use them for my projects because it's the lowest barrier to entry for newbies.
<whitequark>
the scroll pump will expel the condensate by itself but by using gas ballast that happens quicker
<sb0>
ok
<sb0>
so this chinese thing looks rather good...
<whitequark>
I don't like how heavy it is, but otherwise, yeah
<sb0>
this + a turbo would make a very nice UHV system
<sb0>
without any oil vapor contamination
<sb0>
and it sounds relatively easy to freeze-dry stuff with it, too ;)
<whitequark>
yeah there it has an advantage over oily pumps
<whitequark>
I contaminated my one exactly by freeze-drying
<sb0>
don't you get oil backstreaming anyway?
<sb0>
you can even smell it
<whitequark>
well, you can use a turbo to avoid that
<whitequark>
it's sort of overkill, but works
<sb0>
yeah, but when you switch it off, won't oil go into the turbo and your vacuum chamber and mess things up
<sb0>
?
<whitequark>
you need to vent quickly after turning off
<whitequark>
quickly=minutes
<sb0>
I've seen diagrams of old UHV systems that used a oily mech pump + a diffusion pump, and they had to use liquid nitrogen cooled baffles to prevent oil from going into the chamber
<sb0>
don't know if that's overkill or not
<whitequark>
diffusion is different
<whitequark>
for diffusion it is critical to use a good trap, since it's much dirtier
<sb0>
yes. the baffles could be simply for the diffusion one...
<whitequark>
you could use that with a turbo with the added benefit that any water vapor will condense
<whitequark>
in fact I want to use this setup
<whitequark>
well... maybe not LN2 actually, more like dry ice+acetone
<sb0>
why is water vapor so much of a problem?
<sb0>
for the oily mech pump?
<whitequark>
yeah, it will rust
<whitequark>
the turbo doesn't care thankfully
<sb0>
sounds complicated. makes that chinese scroll pump look more interesting :)
<whitequark>
my oily pump is ~2kg for 1/3 of pumping speed
<whitequark>
yours is 30kg
<whitequark>
I can't even lift that
<whitequark>
much less take with me over the air or something
<whitequark>
also you're gonna have a lot of fun delivering that, 30kg is around the upper limit in airmail
<sb0>
seems to be not a problem for mainland -> HK
<sb0>
I've had a much bulkier spot welder delivered already, for less money than fedex charges for a letter
<whitequark>
you bought a spot welder?
<sb0>
yes
<whitequark>
how much did you pay?
<sb0>
something like 200E including shipping
<whitequark>
I find commercial spot welders outrageously overpriced and underperforming
<sb0>
it's a pretty rough one
<whitequark>
a good one is a bunch of IGBTs and an ultracapacitor
<whitequark>
like... 20F or something
<whitequark>
and a micro that controls the energy deposited
<sb0>
it's transformer based, without automatic control
<whitequark>
gross
<sb0>
yes :)
<whitequark>
reminds me, I accidentally made a welder for ants using my resonant LC converter
<sb0>
adding automatic control with a triac and avr should be doable I think
<whitequark>
50W. it can melt uhhh, up to d=0.5mm of copper wire
<whitequark>
your transformer can only deliver a fraction of power that an ultracapacitor can
<sb0>
that thing claims to have a 7kW transformer
<sb0>
well kVA
<whitequark>
*still* a fraction, and you don't need that much continuous power anyway
<whitequark>
it's a really inefficient way to put copper to use, basically
<sb0>
I wonder why that pump is so heavy anyway
<whitequark>
let's see, the time constant for a 3000F/0.29mOhm ultracap is 1s, and it houses 11kJ
<GitHub32>
[misoc] enjoy-digital pushed 8 new commits to master: http://git.io/vv3ZH
FabM has quit [Quit: ChatZilla 0.9.91.1 [Firefox 37.0.1/20150402191859]]
mindrunner is now known as mindrunner_off
nicksydney has quit [Quit: No Ping reply in 180 seconds.]
nicksydney has joined #m-labs
<rjo>
sb0: re ConvOutput: no problem.
<rjo>
ysionneau: katie should be contacting you re testing pxi/6733
<rjo>
sb0: with rtio-everything, are you referring to dds-data rtio?
<sb0>
yes
<sb0>
i'm changing the rtio core right now so you can plug arbitrary modules after the fifos
<rjo>
ack. also for rtio2wb, i presume.
<sb0>
yes, I imagine that would sit between the rtio core and the phys
_florent_ has joined #m-labs
<rjo>
basically the dds-data wishbone slave could be the first use case for rtio2wb.
<sb0>
I'm not sure if "rtio2wb" is such a good idea
<rjo>
ack. i am still a bit unclear about that PHY concept. to me the "PHY" is everything downstream of the fifo (in output direction).
<sb0>
the debug part would basically be a stripped-down "rtio core" that doesn't do timing
<sb0>
the rtio core/phy interface doesn't map nicely to wishbone, e.g. for inputs, you are pushing data, whereas wishbone pulls data when reading
<sb0>
(for ttl inputs)
<rjo>
hmm. i read through our chat log from a few weeks ago and had the impression, that rtio2wb would still be useful because the required effort to make dds-data rtio would be zero then.
<rjo>
yes. i think we agree that outputs (wb writes) map nicely and easily.
antgreen has joined #m-labs
<rjo>
for inputs (wb reads), you would just push stuff into your input fifo once the cycle is complete.
<sb0>
the ad9858 core still has some rough edges. for example it doesn't work reliably on the kc705 due to timing issues...
<rjo>
how would you do dds-data reads on rtio otherwise?
<sb0>
yes, it will push the read data into the input fifo
<rjo>
the wb ad9858 core has timing issues on the fpga? or on the adapter board?
<sb0>
on the adapter board
<sb0>
I guess because of the higher 125MHz system clock frequency
<rjo>
i would think a sufficiently large read latency would solve that.
<rjo>
with rtio reading from devices we need to split the request and the response in any case. whether with rtio2wb or directly with a ad9858 rtio core. the api on the cpu side would be the same in both cases.
<sb0>
it seemed writes were not reliable either, but it could have been a combination of poor contacts in the scsi cables with those annoying sdram/flash bugs we had
<rjo>
throw a logic analyzer at it.
<rjo>
but the fact that the timing is wrong or the adapterboard bad is orthogonal to rtio2wb.
<_florent_>
I'm also going to convert migen to pep8... sb0 are you touching it for your rtio stuff?
antgreen has quit [Ping timeout: 252 seconds]
<rjo>
_florent_: there is autopep8 which works reasonably well (if you have not heard about it already).
<_florent_>
ah thanks going to try that... (I was using pep8.py to check my manual changes...)
<rjo>
sb0: the troublesome timing path in rtio on ppro/pipistrello is around the output fifo read side ack (dout_ack). what i don't understand is that while i see at least one register stage in that loop (bram-to-bram) the timing path according to xilinx does not have any. how is that possible? even with all the register balancing, how can there ever be fewer clock cycles in a closed loop than what your design says?
<rjo>
_florent_: and good editors -- vim is the only good editor that i am aware of ;) -- have good support for highlightling non-pep8-isms and doing autopep8 for you ;)
<rjo>
the problem with migen syntax is that it does not look good in strict pep8. i would switch of a few things there e.g. the alignment things
<rjo>
it is not even very readable with strict pep8.
<ysionneau>
19:33 < rjo> ysionneau: katie should be contacting you re testing pxi/6733 < great :) thanks!
<GitHub186>
[migen] enjoy-digital pushed 1 new commit to master: http://git.io/vvZPY
<GitHub186>
migen/master 3f15699 Florent Kermarrec: revert fhdl/verilog: avoid reg initialization in printheader when reset is not an int. (sorry merge issue)
<rjo>
whitequark: you seem to have experience with redis. is it nicely self contained and portable? could we embed/couple it into artiq?
<rjo>
the bokeh guys use it extensively and it seemed like a nice fit for our pdb, ddb, rdb and sdb databases.
<rjo>
it would also do pub-sub, req-resp and persistence for us.
<rjo>
sb0: ^
<rjo>
but if it is yet another hairy piece to wrangle into shape so that it easily bundles/starts with artiq...