01:18 <cr1901> sb0: Ping when you get the chance. I think there's a bug with the migen Simulator (emphasis on THINK). Could you run the testbench for artiq's spi core and open it in gtkwave?

01:20 <cr1901> I think wishbone reads aren't working properly; according to GTKWave, the wishbone read data bus becomes valid immediately after the address lines are loaded with a new address. According to artiq's spi.py, the wishbone read data bus is registered. Therefore this shouldn't be possible. The data should become valid the next cycle.

01:27 <cr1901> sb0: Ignore; rjo updated the wishbone read behavior in artiq, and I was looking at a VCD of an old commit. My mistake.

01:51 <sb0> whitequark, not even the FSM generation part?

01:52 <whitequark> sb0: why bother with that?

02:49 <whitequark> sb0: so I'm porting the OR1K LLVM backend to 3.9, since Rust recently bumped the requirement to that

02:50 <whitequark> I just talked to Chandler and apparently there is a strong interest in LLVM project to see OR1K upstream

02:50 <whitequark> y/n on scheduling time to do that after Rust lands? this should cut down considerably on maintenance

03:42 <stekern> 16/6

03:42 <stekern> oops, wrong window

04:00 <sb0> whitequark, what does post-llvm-3.9 rust bring to the table for our purposes?

04:01 <sb0> and how does upstreaming or1k llvm lower our maintainance work? I would think it does exactly the opposite:

04:01 <sb0> with a fork, we can keep the old version that works as long as there is no new feature we need, whereas if it's upstreamed we always need to keep it up to dat

04:01 <sb0> is there a clear indication that someone else is going to take care of the or1k port, and do quality work that won't mess things up?

04:02 <sb0> my first assumption about open CPUs is it is a wasteland of broken code where very few people can really help, and publicizing/upstreaming isn't always the best way forward. look at riscv: highly fashionable, but no usable fpga implementation and didn't you say its llvm backend was messed up?

04:05 <cr1901> sb0: Re: FPGA impl, I'm under the impression that RISC-V community is thumbing their noses at FPGAs and only wants ASICs.

04:05 <sb0> I'm also skeptical of their ASIC plans

04:06 <cr1901> How so? I'm not in a position to make a judgment other than ASICs are still a bit outside hobbyist/enthusiast realm.

04:06 <sb0> also, what I said doesn't apply to open CPU environments only, see x86, ACPI, etc.

04:08 <whitequark> sb0: re post-llvm-3.9 rust: bugfixes that just happen to pull in 3.9 requirement

04:08 <whitequark> re upstreaming or1k: the vast majority of changes to the LLVM backends is pure churn

04:09 <whitequark> I don't expect anyone to mess or1k up simply because no one is going to modify it in interesting ways

04:09 <whitequark> upstreaming it is letting the person who desires the churn to do it in the or1k backend.

04:13 <whitequark> also, I know nothing about the risc-v LLVM backend. I can say it will be good once it's upstreamed since the LLVM project has rather strict requirements on that

04:13 <whitequark> the backend that was awful was the LM32 one

05:04 <whitequark> sb0: I just discovered the OR1K backend already has FPU instructions

05:04 <whitequark> not sure how I haven't noticed them before

15:26 <sb0> rjo, the photo p. 17 http://www.nat.vu.nl/~koel/131023_IonTech2_Koelemeij.pdf of the 2nd NIST Al+ trap seems to show the TSP filament right in front of the ion pump

15:26 <sb0> is there not a risk of shorting the ion pump with the deposited titanium film?

15:29 <sb0> also, if I want to oxidize steel to make it less permeable to H2, do I need any special precaution or just stick the vacuum components into the oven for a while?

15:30 <sb0> why are vacuum components not pre-oxidized?

15:35 <sb0> http://www.rbdinstruments.com/blog/titanium-sublimation-pump-operation/ says "The titanium film also helps to replenish the ion pump elements". I'm a lot less optimistic.

15:49 <rjo> sb0: the tsp start with a pretty long connector section after the feedthrough and then there are the Ti wires.

15:50 <rjo> sb0: i the Ti wires are far enough to the right of the pump that there is no path to any insulator inside the pump.

15:51 <rjo> sb0: yes that steel oxidization is done in air. just make sure that you are not burning/heating something else in the oven at the same time (silicone or any oil etc)

15:51 <rjo> if it smells, it's bad.

15:52 <rjo> the oxidization is a contentious issue. many (me included) think that it is not really helpful.

15:52 <sb0> I have the impression that many vacuum-related topics are contentious issues...

15:53 <rjo> yes.

15:56 <sb0> ok, I'll have a close look at my ion pump to check if there's a risk of spraying insulators. the high voltage feedthrough is on the inlet, which can make it more problematic than on that pump at NIST

15:56 <rjo> sb0: http://cas.web.cern.ch/cas/spain-2006/pdfs/chiggiato-1.pdf and http://cas.web.cern.ch/cas/Spain-2006/PDFs/Chiggiato-2.pdf

15:57 <rjo> that guy is really cool. in the second slide deck p35 he talks about air bake.

15:59 <rjo> it also depends on exactly where your Ti wire starts in the TSP. but the good thing is that it only goes ballistic. if you can't see insulators from where the wire is, you are ok.

16:21 <key2> sb0: what is NextValue() used for in an FSM

16:21 <key2> i don't get whats teh diff between foo.eq(1) and NextValue(foo, 1)

16:25 <sb0> foo.eq(1) is equivalent to comb += If(fsm_in_that_state, foo.eq(1)) (modulo any conditions you add on foo.eq(1))

16:25 <sb0> NextValue is equivalent to the same thing with sync +=

16:35 <key2> thx

16:36 <larsc> does simulation support generating vcd files?

16:36 <sb0> yes

16:37 <larsc> thanks, just found it in the examples

16:38 <key2> when simulating a CSRStorage, I have to yield yield mystorage.re.eq(1) ?

16:38 <key2> there is something to write in CSR from simulation

17:02 <sb0> there's something to make transactions on the CSR bus, for something that drives the CSRs directly, pull requests accepted

17:10 <key2> what you mean pull request acceptes ? the .ack ?

17:15 <sb0> means you should write that code yourself and it is something that can be merged upstream

17:20 <key2> my python skills are not good enough to do quality code that would go into upstream yet :)

17:23 <key2> right now I am training on migen/misoc to be able to do somethig fancy.. So far I am doing a sdcard core

17:38 <larsc> how do they say, aim for the moon, even if you miss you'll end up in the endless, dark and empty vacuum of space

23:21 <GitHub161> [llvm-or1k] whitequark created artiq-3.9 (+9151 new commits): https://github.com/m-labs/llvm-or1k/compare/a07c74ea610d^...1d64a9551d37

23:21 <GitHub161> llvm-or1k/artiq-3.9 a07c74e Hans Wennborg: Update version to 3.9....

23:21 <GitHub161> llvm-or1k/artiq-3.9 92df174 Sanjay Patel: don't repeat names in comments ; NFC...

23:21 <GitHub161> llvm-or1k/artiq-3.9 67e14a3 Dimitry Andric: Avoid undefined behavior in LinkAllPasses.h...

23:31 <GitHub148> [conda-recipes] whitequark pushed 1 new commit to master: https://github.com/m-labs/conda-recipes/commit/73ead27ec12253720038d6fc89b16fcefa535889

23:31 <GitHub148> conda-recipes/master 73ead27 whitequark: llvm-or1k: update to 3.9.1.

23:32 <whitequark> bb-m-labs: force build --props=package=llvm-or1k conda-all

23:32 <bb-m-labs> build #67 forced

23:32 <bb-m-labs> I'll give a shout when the build finishes