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
xcombell1 has joined #m-labs
xcombelle has quit [Ping timeout: 258 seconds]
cr1901 has joined #m-labs
sb0 has joined #m-labs
<sb0>
no, it's not different
fengling has joined #m-labs
<cr1901>
sb0: What do you mean it's not different? If you generate verilog or do a simulation, migen will add the missing clock domains unconditionally.
<cr1901>
If you are synthesizing, migen will add a default clock domain if you don't do "anything fancy", and you must otherwise instantiate the domains.
FabM has quit [Ping timeout: 240 seconds]
FabM has joined #m-labs
<sb0>
ah, you're talking about that. yes.
FabM has quit [Ping timeout: 244 seconds]
<cr1901>
The "anything fancy" of course is exaggerating; I just don't remember the exact conditions (creating a clock domain? assigning to a sync statement where the clock domain is specified?) that migen will no longer add domains for you during synthesis
FabM has joined #m-labs
<sb0>
creating a clock domain.
<sb0>
the logic is if you start creating clock domains, then you are responsible for clocking
<sb0>
if you reference a non-existing clock domain in sync statements or elsewhere it will error out
sb0 has left #m-labs ["Leaving"]
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 264 seconds]
sb0 has joined #m-labs
rohitksingh_work has joined #m-labs
rohitksingh_wor1 has quit [Ping timeout: 258 seconds]
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
rohitksingh_work has quit [Quit: Leaving.]
rohitksingh_work has joined #m-labs
sb0 has quit [Ping timeout: 250 seconds]
sb0 has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 276 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
sandeepkr has joined #m-labs
sandeepkr has quit [Max SendQ exceeded]
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]
<whitequark>
sb0: btw, is there any use for running the coredevice firmware as a hosted application?
<whitequark>
well, clearly there is, like debugging. the real question is how interested in that you are
<whitequark>
the threading library at least will work on linux (pretty much any unix), and will not work on windows
<whitequark>
I think running the entire thing in linux userspace could well help with e.g. lwip bugs
<sb0>
is that easy to do?
<sb0>
afaict there is definitely no need to run that on windows
<sb0>
interfacing with a virtual ethernet on windows will probably be hell anyway, while linux supports this easily
<whitequark>
there's a windows tun/tap driver
<whitequark>
it is not generally hard, except for the driver signing fuckery, which makes it a total madness
<sb0>
yeah. so it's a total madness in the end :)
<whitequark>
well, you could just add a switch enabling test mode in your windows
<sb0>
what would the point of running on windows be?
<whitequark>
dunno
<whitequark>
i'm just saying that it definitely won't, because you cannot swap stacks on windows without twiddling at least three undocumented fields in the thread information block
<sb0>
if it's for tracking ethernet bugs that happen when talking to windows, you could bridge a windows VM interface to the linux tun/tap
sandeepkr has joined #m-labs
sandeepkr has quit [Quit: Leaving]
sandeepkr has joined #m-labs
sandeepkr has quit [Max SendQ exceeded]
xcombell1 is now known as xcombelle
sandeepkr has joined #m-labs
sandeepkr has quit [Ping timeout: 264 seconds]
key2 has joined #m-labs
<key2>
hi
<sb0>
hi
<key2>
sb0: Is it possible in a simulation to do something like self.comb += clk_out.eq(self.cd_sys.clk) ?
<key2>
as anytime you yield it generates a rising edge and falling edge as well
<sb0>
no, clocks signal values are not handled in simulation. it's not an event driven simulator like verilog.
<sb0>
whooohooo! 6e-9 mbar
<sb0>
seems there was no leak after all
<sb0>
rjo, see, the chinese vacuum ware isn't that bad!
<sb0>
2e-9 ...
<sb0>
in hindsight, i should really have just used KF flanges before the all-metal valve. the ion pump sees the higher pressures during bakeout anyway, and correctly baking out with the turbopump connected is just too much of a pain
<sb0>
the ion pump is rated for up to 1e-3 mbar, and it didn't get anywhere near that anyway
<GitHub100>
[artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/v64Xm
<bb-m-labs>
I'll give a shout when the build finishes
cr1901 has joined #m-labs
<rjo>
sb0: 6e-9 is something you can very well get without baking and just cleanliness. for the ratio of surface and pumping you have ;)
<rjo>
sb0: i'd usually do the bake into just the ion pump if the expected lifetime works out fine. just because it reacts nicely to poweroutages.
<sb0>
well, that quick bake made a nice difference from the 1e-7 i had before...
<sb0>
maybe there was just some dirt somewhere that had to be boiled off
<rjo>
sb0: i have a commit or two still pending for 1.3.
<rjo>
i'll push them.
<rjo>
dirt tends to not boil off.
<rjo>
what was the T?
<sb0>
140C
<GitHub96>
[artiq] jordens pushed 1 new commit to release-1: https://git.io/v64Hn
<GitHub96>
artiq/release-1 46cae14 Robert Jordens: lda: fix windows path
<sb0>
for a few hours
<sb0>
and I don't get this nasty pressure rise when I turn off the ion pump anymore
<sb0>
doesn't look like there's a leak imho
<GitHub129>
[artiq] jordens pushed 1 new commit to release-1: https://git.io/v64Qe
<GitHub129>
artiq/release-1 92d5491 Robert Jordens: gui: cleanup compact_exponential, 15 digits
<GitHub100>
[artiq] jordens pushed 2 new commits to master: https://git.io/v64Qf
<GitHub100>
artiq/master 586f071 Robert Jordens: lda: fix windows path
<GitHub100>
artiq/master 1c8202e Robert Jordens: gui: cleanup compact_exponential, 15 digits
sb0 has quit [Quit: Leaving]
<rjo>
you don't have the data nor instruments to say that. but it doesn't look like there is a "big" leak.
<rjo>
bb-m-labs, force build --branch=release-1 artiq
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<rjo>
bb-m-labs, force build --branch=release-1 artiq-kc705-nist_qc1
<rjo>
bb-m-labs, force build --branch=release-1 artiq-kc705-nist_qc2
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<rjo>
bb-m-labs, force build --branch=release-1 artiq-kc705-pipistrello-nist_qc1
<bb-m-labs>
no such builder 'artiq-kc705-pipistrello-nist_qc1'
<rjo>
bb-m-labs, force build --branch=release-1 artiq-pipistrello-nist_qc1
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<rjo>
sb0: a datapoint: if you buy a new ion pump like yours, it comes under vacuum with an appendage not much bigger than your system after a bake having sat there "not pumping" for months and they spec current-inferred pressures better than 1e-9.
<GitHub89>
artiq/master 6fe23b8 Robert Jordens: gui: new ScientificSpinBox (from 09f9293) closes #460
<GitHub89>
artiq/master 9775faa Robert Jordens: gui: use ScientificSpinBox for NoScan and NumberValue (#460)
<GitHub89>
artiq/master 941f6fc Robert Jordens: gui: auto-set ScientificSpinBox relative_step and precision in ScanWidget
<rjo>
sb0: did you not bake the pump?
<sb0>
I did
<sb0>
what is 09f9293?
<rjo>
the commit in my local scientific spinbox testing repo
<rjo>
sb0: yes. above an unbaked ion pump you get a similar value once it has been running for a while. this is just determined by leaks and titanium pumping.
<sb0>
well, I tried pumping on that system for about a day, and it stayed at 1e-7
<rjo>
yep. that can take years without baking. the rule of thumb (a.k.a. legend) is one order of magnitude in pressure (and thus pump speed, pump time etc as well) for every 30 C.
<sb0>
why are ion pump controllers capable of delivering so much current? I never went above a dozen mA
<rjo>
which controller is capable? IME the maximum safe/usable current is roughly 0.5 mA/l
<rjo>
the standard varian controllers for 20 l/s pumps only do 7mA IIRC.
<rjo>
we had a fat and dangerous one for a 1000 l/s pump that did 500 mA.
fengling has quit [Ping timeout: 240 seconds]
<sb0>
many seem to be in the 100mA range. but yeah, I just found some smaller ones
<rjo>
sb0: oh by the way: basing on QAbstractSpinBox would have resulted in *much* more code: lots of very important API from QAbstractSpinBoxPrivate only gets exposed in QDoubleSpinBox...
<sb0>
where does one get high voltage high temperature cable?
<sb0>
regular silicone high voltage cable is rated to 150C and I'm unsure if this is a sufficient bakeout temperature
FabM has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
<key2>
sb0: what is the way to make migen generate the csv for the csr ?
<sb0>
"Vibraflame® cables are fire resistant wires and composite cables designed to withstand extreme temperatures ranging from -196°C to + 1565°C. This is an ideal solution for applications in steel and aluminium plants, oil refineries, glass factories, offshore rigs and in military equipment."
<sb0>
now that sounds fun
<sb0>
key2, migen knows nothing about csrs. it's in misoc
<key2>
which is a simple CSRBank <> wishbone bridge
<key2>
do I have a way to know what i mapped where ?
<sb0>
have you read the source of cpu_interface.get_csr_csv?
<cr1901>
sb0: "migen knows nothing about csrs. it's in misoc" In key2's defense, that wasn't always true :P
<cr1901>
sb0: It's on my TODO list, either in the form of a tutorial or documentation but I think CSR should be documented better, and that it relies on introspection of classes to work properly
<key2>
no but it inherit from SoCCore
<key2>
which means i am forced to use a soc in order to get it generate
<sb0>
no, it doesn't
<sb0>
all you need is iterate on the list of csrs and do the same math that get_csr_csv is doing
<key2>
yeab but get_csr_regions return self._csr_regions
<key2>
which is from a SocMore
fengling has joined #m-labs
fengling has quit [Ping timeout: 240 seconds]
<sb0>
well, read the SoCCore source then, there's nothing magical in there, just some list operations
<sb0>
rjo, mouse wheel to zoom on the scan widget has stopped working here, both in master and release-1
<sb0>
could be a random qt/gnome/xorg/whatever bug, or a artiq regression... does it still work for you?
sb0 has quit [Quit: Leaving]
<key2>
what happen in a fsm state is sync, right ?
<larsc>
hm, how is rust able to build a statemachine from this at compile time given that future is a type(?) and the value can depend on runtime data
<larsc>
is it able to unroll everything and then move statements that affect the value of the future into the statemachine?
mumptai has joined #m-labs
<key2>
what is NextValue's purpose in a FSM ?
sandeepkr has quit [Quit: Leaving]
<mumptai>
my vague memory: registered outputs
sandeepkr has joined #m-labs
sandeepkr has quit [Max SendQ exceeded]
kuldeep has quit [Read error: Connection timed out]
kuldeep has joined #m-labs
<rjo>
sb0: yes i am done with 1.3. i'll release it so the americans can make their physics great again.
<rjo>
sb0: wheel does scrolling the argeditor pane, shift-wheel does zoom, ctrl-wheel changes npoints. there are a few things like these that we should put into a short section on the GUI....
<GitHub124>
[artiq] jordens pushed 1 new commit to release-1: https://git.io/v6BdE
<GitHub124>
artiq/release-1 929ded3 Robert Jordens: RELEASE_NOTES: 1.3
<rjo>
bb-m-labs, force build --branch=release-1 artiq
<bb-m-labs>
build forced [ETA 29m08s]
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
bb-m-labs, force build --branch=release-1 artiq-kc705-nist_qc1
<rjo>
bb-m-labs, force build --branch=release-1 artiq-kc705-nist_qc2
<bb-m-labs>
build forced [ETA 10m43s]
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
bb-m-labs, force build --branch=release-1 artiq-pipistrello-nist_qc1
<bb-m-labs>
The build has been queued, I'll give a shout when it starts
<bb-m-labs>
The build has been queued, I'll give a shout when it starts